From liquorke02@roughcountry.com Sat Aug 1 01: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 DEA033A6452 for ; Sat, 1 Aug 2009 01:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.321 X-Spam-Level: X-Spam-Status: No, score=-86.321 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OIMO=2.152, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_COLLEGE_SCAM=3.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 AzDoIgcqbnLB for ; Sat, 1 Aug 2009 01:06:42 -0700 (PDT) Received: from ppp-199-31.98-62.inwind.it (ppp-199-31.98-62.inwind.it [62.98.31.199]) by core3.amsl.com (Postfix) with ESMTP id 2C4903A67EC for ; Sat, 1 Aug 2009 01:06:41 -0700 (PDT) Received: from [89.24.163.92] (account liquorke02@roughcountry.com HELO zakfmykqytvsvko.adqejzyglpcb.info) by ppp-199-31.98-62.inwind.it (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 992473471 for dnsext-archive@lists.ietf.org; Sat, 1 Aug 2009 09:06:43 +0100 From: "Prof. Stefan I. Sauceda"@core3.amsl.com, gdnsext-archive@lists.ietf.org To: Subject: FWD : Degree Date: Sat, 1 Aug 2009 09:06:43 +0100 Message-ID: <5687003235.856W3KA1433606@jtrmekxjva.slfpswosrgkkxs.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3338.1 Importance: Normal Hey We have a program that will help you obtain a fully verifiable University Degree based on your professional experience. Bachelors, Masters or Ph.D Ring us right now 1.305 460.5721 Leave your msg including your name and phone number. From owner-namedroppers@ops.ietf.org Sat Aug 1 02: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 93D063A67A6; Sat, 1 Aug 2009 02:16:09 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGMBzgTAEYn3; Sat, 1 Aug 2009 02:16:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D8383A67EC; Sat, 1 Aug 2009 02:16:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXAXY-0003Jp-Qp for namedroppers-data0@psg.com; Sat, 01 Aug 2009 09:06:08 +0000 Received: from [2607:f010:3fe:302:1013:72ff:fe5b:6032] (helo=out-31.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXAXS-0003JG-Gm for namedroppers@ops.ietf.org; Sat, 01 Aug 2009 09:06:06 +0000 Received: from smtp-6.smtp.ucla.edu (smtp-6.smtp.ucla.edu [169.232.48.241]) by out-31.smtp.ucla.edu with ESMTP id n7195V7H019914; Sat, 01 Aug 2009 02:05:32 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-6.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7195V7H019914; Sat, 1 Aug 2009 02:05:31 -0700 Received: from host-78-64-88-32.homerun.telia.com (host-78-64-88-32.homerun.telia.com [78.64.88.32]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7195Sg1030284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Aug 2009 02:05:29 -0700 Cc: Paul Vixie , "namedroppers@ops.ietf.org" Message-Id: <5398D93F-437F-41FF-BAB7-1AFA8235FC4C@CS.UCLA.EDU> From: Eric Osterweil To: Michael Graff In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-227388275" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Sat, 1 Aug 2009 11:05:27 +0200 References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.241 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4-227388275 Content-Type: multipart/alternative; boundary=Apple-Mail-3-227388243 --Apple-Mail-3-227388243 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 31, 2009, at 8:24 PM, Michael Graff wrote: > On Jul 30, 2009, at 21:29, Paul Vixie wrote: >>> >> what would it take to convince you? > > I would like to see someonefind out two things. > > One, if the bottleneck and fear of something that gas been around > for many years (DNS over tcp) ... but with smaller packet sizes (i.e. those w/o crypto), this problem was not apparent. Message sizes (apparently) did not exacerbate path limitations. Advertising a 4096B buffer for a 600B response would not get you into trouble. However, advertising a 4096B buffer for a response that could vary between 2K and 4K could bring us to where we are today. > is on the equipment, os, or DNS server code. The evidence has been presented in a few venues (including IETF 75). In addition to that presentation you can look at the more detailed material presented at RIPE 58: http://secspider.cs.ucla.edu/docs.html or any of the other relevant published work listed on that page. You can even download dnsfunnel and look for yourself http://www.vantage-points.org/download.html I think, perhaps, the latter might be the best way to assess the problem, as the tool will allow you to see it for yourself. > > > Two, how is this not a ddos vector waiting to happen today? > > > That is, provisioning against stress and planning on ddos, how would > an admin react differently in server and network capacity planning? It's no more or less of a DDoS vector than before, but now the servers are forced to deal w/ a higher sustained load (of legitimate traffic) than before. A higher load that seems (based on the evidence) to include unnecessary TCP traffic in many cases. > > > In short, why is the increase if tcp in real queries a real problem > when in a properly chosen algorithm and with reasonable ttl values, > it can be minimized? This is not entirely clear. What is a "properly chosen" algorithm when the resolver behavior varies based solely on _where the resolver_ is querying from? Consider what we are seeing: a name server serves keys and some resolvers can retrieve them over UDP w/o a problem. While, at the same time, others resort to TCP. It isn't the name server that has done anything differently. otoh, if a resolver can't get the message simply because it is prompting the name server to send messages with authority and additional data, and it could avoid this by specifying a smaller buffer size (not 512, but something more likely to work), then it seems hard to claim that this fault exists in either "equipment, [or] os." All of that said, if I read your comment correctly, I do completely agree with you that one thing operators of name servers could try to do is avoid some of this by taking steps to minimize the sizes of the sets in its zone (when this is possible). Smaller keys should fit better, but I don't think this frees the resolvers from the responsibility of being smarter. Eric --Apple-Mail-3-227388243 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 31, 2009, = at 8:24 PM, Michael Graff wrote:

On = Jul 30, 2009, at 21:29, Paul Vixie <vixie@isc.org> wrote:

what= would it take to convince you?

I would like to see = someonefind out two things.

One, if the bottleneck and fear of = something that gas been around for many years (DNS over = tcp)

... but with smaller packet = sizes (i.e. those w/o crypto), this problem was not apparent. =  Message sizes (apparently) did not exacerbate path limitations. =  Advertising a 4096B buffer for a 600B response would not get you = into trouble.  However, advertising a 4096B buffer for a response = that could vary between 2K and 4K could bring us to where we are = today.

is on the equipment, os, = or DNS server code.

The evidence = has been presented in a few venues (including IETF 75).  In = addition to that presentation you can look at the more detailed = material presented at RIPE 58:
or= any of the other relevant published work listed on that page.  You = can even download dnsfunnel and look for yourself

I think, perhaps, = the latter might be the best way to assess the problem, as the tool will = allow you to see it for yourself.



Two, how is this not a ddos vector waiting to = happen today?


That is, provisioning against stress and = planning on ddos, how would an admin react differently in server and = network capacity planning?

It's no = more or less of a DDoS vector than before, but now the servers are = forced to deal w/ a higher sustained load (of legitimate traffic) than = before.  A higher load that seems (based on the evidence) to = include unnecessary TCP traffic in many cases.



In short, why is the increase if tcp in real = queries a real problem when in a properly chosen algorithm and with = reasonable ttl values, it can be = minimized?

This is not entirely = clear.  What is a "properly chosen" algorithm when the resolver = behavior varies based solely on _where the resolver_ is querying from? =  Consider what we are seeing: a name server serves keys and some = resolvers can retrieve them over UDP w/o a problem.  While, at the = same time, others resort to TCP.  It isn't the name server that has = done anything differently.  otoh, if a resolver can't get the = message simply because it is prompting the name server to send messages = with authority and additional data, and it could avoid this by = specifying a smaller buffer size (not 512, but something more likely to = work), then it seems hard to claim that this fault exists in either = "equipment, [or] os."

All of that said, if I = read your comment correctly, I do completely agree with you that one = thing operators of name servers could try to do is avoid some of this by = taking steps to minimize the sizes of the sets in its zone (when this is = possible).  Smaller keys should fit better, but I don't think this = frees the resolvers from the responsibility of being = smarter.

Eric
= --Apple-Mail-3-227388243-- --Apple-Mail-4-227388275 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 v2.0.9 (Darwin) iEYEARECAAYFAkp0BVcACgkQK/tq6CJjZQINXgCfViZZiO1Ry/XNBOg54HozAXd+ utQAn1ikEa2+J56N49p/u3NWorh88q1H =fOaY -----END PGP SIGNATURE----- --Apple-Mail-4-227388275-- -- to unsubscribe send a message to namedroppers-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 Aug 1 16: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 7A9553A6BAB; Sat, 1 Aug 2009 16:18: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 NaUxVqA1i3LI; Sat, 1 Aug 2009 16:18:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B4C03A6B97; Sat, 1 Aug 2009 16:18:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXNco-0001Jm-9y for namedroppers-data0@psg.com; Sat, 01 Aug 2009 23:04:26 +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 1MXNcj-0001Is-5G for namedroppers@ops.ietf.org; Sat, 01 Aug 2009 23:04:23 +0000 Received: by an-out-0708.google.com with SMTP id c3so1408133ana.26 for ; Sat, 01 Aug 2009 16:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YygfK3PXenY6mV9aTqElIcm32MUUuwORkvKrBjAiEqc=; b=sbUZSGalNLi4wx2V74vPw0ZkHJH02fnGyYsiMLbKEmNbnf760I+QOKnozfRUvVX0EK 2acBejvekqeJIZZUhwtaKCtMjDfES9CalpQg/uPAp0i5OxoCWHGwMw6N3OwiKAcHRcvv eFpRnSTiCEXXFaxaqyvPE9t7tgG/wDCqarSW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=PGT6XGmFMNOUbodUx6QyPil+mZUXkT3aRgl9GI1wtmo4pbdYFxPAxoZdUTwqWMQOlQ pxZHtdU6gh09VR5uLDgzr563ET5+FQNLMeeXCW+YGgxR7moa5Kc9cwqR3B42AwM1FN1M VnHqkL+VIC7NFNqVtPK7fniFl9eIRIP8Ic2QY= Received: by 10.100.41.18 with SMTP id o18mr4625370ano.195.1249167859978; Sat, 01 Aug 2009 16:04:19 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id c29sm737945anc.10.2009.08.01.16.04.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Aug 2009 16:04:18 -0700 (PDT) Message-ID: <4A74C9F0.8070809@gmail.com> Date: Sat, 01 Aug 2009 19:04:16 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A737CC7.4060902@gmail.com> <20090731234524.GL14838@shinkuro.com> In-Reply-To: <20090731234524.GL14838@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: > On Fri, Jul 31, 2009 at 07:22:47PM -0400, William Allen Simpson wrote: >> Aim for retiring SHA-1 by April 1st. > > One is tempted to read that suggestion as significant. > The dates were chosen to end on that date for the humor effect. ;-) My guess is after aiming for 2 interoperable implementations, the timing might slip. But April 1st has the advantage in the northern hemisphere that it's at least a few weeks before most schools empty for the summer, and before most companies have many vacations, meaning we'd get better feedback and bang for the buck. By contrast, the previously suggested December 31st is a terrible time to do a rollover.... -- to unsubscribe send a message to namedroppers-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 Aug 1 17:56: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 DAA5F3A68C4; Sat, 1 Aug 2009 17:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.975, 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 3Rj82O7tyT1M; Sat, 1 Aug 2009 17:56:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABFAD3A6819; Sat, 1 Aug 2009 17:56:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXPF3-000Bax-VD for namedroppers-data0@psg.com; Sun, 02 Aug 2009 00:48:01 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXPEy-000BZX-DS for namedroppers@ops.ietf.org; Sun, 02 Aug 2009 00:47:59 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=NNuS62hmM1xDroF5lAxmgKwsbae/Fa8+faFZopd4rQb6X3lhN3GzfOYL3wM/eVcj; 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.98.73] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MXPEw-00082d-IV; Sat, 01 Aug 2009 20:47:55 -0400 Message-ID: <4A74E234.66DB978E@ix.netcom.com> Date: Sat, 01 Aug 2009 17:47:48 -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: William Allen Simpson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A737CC7.4060902@gmail.com> <20090731234524.GL14838@shinkuro.com> <4A74C9F0.8070809@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688bd91d368277cf2ac3749ad0f47f6e9a0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.98.73 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Will and all, I agree, December is a terrible month to do anything or any real significance... Same is true of November, BTW... William Allen Simpson wrote: > Andrew Sullivan wrote: > > On Fri, Jul 31, 2009 at 07:22:47PM -0400, William Allen Simpson wrote: > >> Aim for retiring SHA-1 by April 1st. > > > > One is tempted to read that suggestion as significant. > > > The dates were chosen to end on that date for the humor effect. ;-) > > My guess is after aiming for 2 interoperable implementations, the timing > might slip. But April 1st has the advantage in the northern hemisphere > that it's at least a few weeks before most schools empty for the summer, > and before most companies have many vacations, meaning we'd get better > feedback and bang for the buck. > > By contrast, the previously suggested December 31st is a terrible time to > do a rollover.... > > -- > to 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 Aug 2 02:24: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 CFB563A6B4C; Sun, 2 Aug 2009 02:24: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 gNY8eZdtdwde; Sun, 2 Aug 2009 02:24:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 478CF3A6B0A; Sun, 2 Aug 2009 02:23:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXX4W-0007gX-G1 for namedroppers-data0@psg.com; Sun, 02 Aug 2009 09:09:40 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXX4Q-0007fv-TC for namedroppers@ops.ietf.org; Sun, 02 Aug 2009 09:09:37 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B2E9EC2DA7; Sun, 2 Aug 2009 10:09:31 +0100 (BST) Date: Sun, 02 Aug 2009 10:09:50 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Jeffrey A. Williams" , William Allen Simpson cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: In-Reply-To: <4A74E234.66DB978E@ix.netcom.com> References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A737CC7.4060902@gmail.com> <20090731234524.GL14838@shinkuro.com> <4A74C9F0.8070809@gmail.com> <4A74E234.66DB978E@ix.netcom.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 1 August 2009 17:47:48 -0700 "Jeffrey A. Williams" wrote: > I agree, December is a terrible month to do anything or any real > significance... Same is true of November, BTW... I find the same applies with January to October inclusive... -- 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 picketingr24@roux.com Sun Aug 2 14:52: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 882E23A68C3 for ; Sun, 2 Aug 2009 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.662 X-Spam-Level: X-Spam-Status: No, score=-9.662 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, FORGED_MUA_OUTLOOK=3.116, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, 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 gLSEx-UoljKW for ; Sun, 2 Aug 2009 14:52:33 -0700 (PDT) Received: from 93-45-112-217.ip102.fastwebnet.it (93-45-112-217.ip102.fastwebnet.it [93.45.112.217]) by core3.amsl.com (Postfix) with ESMTP id C212F3A67E4 for ; Sun, 2 Aug 2009 14:52:32 -0700 (PDT) Received: from [180.18.79.126] (helo=wkknjh.rkgglf.com) by 93-45-112-217.ip102.fastwebnet.it with esmtpa (Exim 4.69) (envelope-from ) id 1MM784-3568es-WF for dnsext-archive@lists.ietf.org; Sun, 2 Aug 2009 13:52:34 -0800 From: "Steve Siebert"@core3.amsl.com, hdnsext-archive@lists.ietf.org To: Subject: Cloths Slim Date: Sun, 2 Aug 2009 13:52:34 -0800 Message-ID: <5709911515.095XP4V8231185@iebzpo.lxujetekse.va> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: Normal http://simpleadd.com/ From owner-namedroppers@ops.ietf.org Sun Aug 2 17: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 D49E93A6C7D; Sun, 2 Aug 2009 17:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=1.204, BAYES_20=-0.74, 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 ACElQlpCHdUS; Sun, 2 Aug 2009 17:29:54 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 201773A6CAD; Sun, 2 Aug 2009 17:29:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXlEa-000NwA-9Q for namedroppers-data0@psg.com; Mon, 03 Aug 2009 00:17:00 +0000 Received: from [209.86.89.66] (helo=elasmtp-spurfowl.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXlEU-000Nvk-LI for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 00:16:56 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=KiUucrLHLCf4so/myOKxoxfLGyrIsDDPyD/qePZlbDcP7LKewR2gpAsam0svxVPf; 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.214] (helo=ix.netcom.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MXlER-0003PJ-4j; Sun, 02 Aug 2009 20:16:51 -0400 Message-ID: <4A762C6B.5D53A13@ix.netcom.com> Date: Sun, 02 Aug 2009 17:16:43 -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: Alex Bligh CC: William Allen Simpson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A737CC7.4060902@gmail.com> <20090731234524.GL14838@shinkuro.com> <4A74C9F0.8070809@gmail.com> <4A74E234.66DB978E@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606888fd6e63594313ce7a6f860ec3469d687350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.214 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex and all, January yeah, I am not sure about October though... Alex Bligh wrote: > --On 1 August 2009 17:47:48 -0700 "Jeffrey A. Williams" > wrote: > > > I agree, December is a terrible month to do anything or any real > > significance... Same is true of November, BTW... > > I find the same applies with January to October inclusive... > > -- > Alex Bligh 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 Aug 2 17:29: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 397A83A6CAB; Sun, 2 Aug 2009 17:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-2.971, 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 Z66nD-r4GK8c; Sun, 2 Aug 2009 17:29:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D29C3A6CAD; Sun, 2 Aug 2009 17:29:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXlJn-000OT5-KZ for namedroppers-data0@psg.com; Mon, 03 Aug 2009 00:22: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 1MXlJj-000OSp-Rf for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 00:22:21 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n730MHJl014663 for ; Sun, 2 Aug 2009 20:22:17 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n730MHBu014662 for namedroppers@ops.ietf.org; Sun, 2 Aug 2009 20:22:17 -0400 (EDT) (envelope-from namedroppers) 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 1MXk0f-000FM7-8y for namedroppers@ops.ietf.org; Sun, 02 Aug 2009 22:58:34 +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 570BA398CD; Sun, 2 Aug 2009 22:58:32 +0000 (UTC) (envelope-from mayer@ntp.org) Received: from cust-63-209-233-54.bos-dynamic.gis.net ([63.209.233.54] helo=[10.10.10.101]) by firewall.antoniuk.lan with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MXk0T-0005Ru-0L; Sun, 02 Aug 2009 18:58:21 -0400 Message-ID: <4A7619FD.1080902@ntp.org> Date: Sun, 02 Aug 2009 18:58:05 -0400 From: Danny Mayer Reply-To: mayer@ntp.org Organization: NTP User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Matthew Dempsky Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> In-Reply-To: X-Enigmail-Version: 0.96.0 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@ntp.org 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. ] Matthew Dempsky wrote: > On Wed, Jul 29, 2009 at 1:53 PM, Samuel Weiler wrote: >> Similarly, I hope that we will see several early KSK rollovers, perhaps once >> a year for the first 3-5 years of having a signed root, just to give >> resolver operators an opportunity to develop and test their KSK rollover >> procedures. > > If the goal is to give them operational practice, wouldn't it make > sense to instead roll keys once or twice a week during a test period > lasting a few months or something? Or better, to setup some dummy > keys/servers that continue to cycle once a week indefinitely so a > company starting out a few years from now will be able to still test > that key rollover works fine for them. > > Once a year doesn't seem much better than once every N years for the > purpose of letting people test their software/configurations/etc. I > fear it'll end up like NTP's leap second support: there's protocol > support and the code's there, but there was still a surprising number > of problem reports on the technical mailing lists / blogs that I was > reading when the last one occurred. > > In the NTP leap second case, computers are out of sync by about a > second. In the DNS case, host name resolution breaks. You cannot really compare the two. It's very hard to reset your clock to test NTP's leap second code. Try setting up an isolated network for testing this and finding that your clock got reset before you had a chance to test the leap second part of the code. It's relatively easy to set up your own copy of the root domain so you can test rollovers. 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 Sun Aug 2 17: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 B6BE23A6B0D; Sun, 2 Aug 2009 17:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=-0.263, 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 iOzAUTmgl1Z6; Sun, 2 Aug 2009 17:59:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7383A3A6934; Sun, 2 Aug 2009 17:58:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXlky-0001qs-JN for namedroppers-data0@psg.com; Mon, 03 Aug 2009 00:50:28 +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 1MXlku-0001qX-Qe for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 00:50:26 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n730n2sU025606; Mon, 3 Aug 2009 00:49:02 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n730n1iD025605; Mon, 3 Aug 2009 00:49:01 GMT Date: Mon, 3 Aug 2009 00:49:01 +0000 From: bmanning@vacation.karoshi.com To: "Jeffrey A. Williams" Cc: Alex Bligh , William Allen Simpson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090803004901.GA25060@vacation.karoshi.com.> References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A737CC7.4060902@gmail.com> <20090731234524.GL14838@shinkuro.com> <4A74C9F0.8070809@gmail.com> <4A74E234.66DB978E@ix.netcom.com> <4A762C6B.5D53A13@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A762C6B.5D53A13@ix.netcom.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: so, why don't you poll your 284,000 members/stakeholders and come back with a date thats good for you and i'm sure that the rest of the 1,000,000,000 folks on the Internet will be able to come to some agreement on the date/time that does not otherwise conflict with vacations, holidays, religious observence, sleep cycles, education, family demands, or other critical events in our lives. i promise that i won't be washing the cat or plucking my eyebrows then... --bill (who is fine w/ 25dec, 31dec, 01jan, the friday before a five day weekend... pretty much any time is good, AS LONG AS IT IS ANNOUNCED WITH SOME LEADTIME, SAY AT LEAST A MONTH...) On Sun, Aug 02, 2009 at 05:16:43PM -0700, Jeffrey A. Williams wrote: > Alex and all, > > January yeah, I am not sure about October though... > > Alex Bligh wrote: > > > --On 1 August 2009 17:47:48 -0700 "Jeffrey A. Williams" > > wrote: > > > > > I agree, December is a terrible month to do anything or any real > > > significance... Same is true of November, BTW... > > > > I find the same applies with January to October inclusive... > > > > -- > > 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 Aug 3 02: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 4913D3A6D59; Mon, 3 Aug 2009 02:30:50 -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 O1vRquRp+aCm; Mon, 3 Aug 2009 02:30:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 400183A6AFC; Mon, 3 Aug 2009 02:30:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXtfX-000Mlc-M8 for namedroppers-data0@psg.com; Mon, 03 Aug 2009 09:17:23 +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 1MXtfO-000MkO-L1 for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 09:17:20 +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 n739H8Xp001906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 11:17:09 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A76AB14.3000002@nlnetlabs.nl> Date: Mon, 03 Aug 2009 11:17:08 +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: David Blacka , "namedroppers@ops.ietf.org" Subject: [dnsext] dnssec-bis updates: key use 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, 03 Aug 2009 11:17:09 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, About dnssec-bis updates. Specifically about the 'MUST try all keys'. a) I disagree. Are there people that agree with this point of view? A more specific key is simply more specific and thus trumps a less specific one. People should have proper automated key update mechanisms so the only way for the key to not work is if there is an attack. So, the text must be: MUST try all keys that are specific for the query. So, if you add 5 keys for example.com they should all be tried. b) In case I lose the argument I want the text amended: MUST try all keys, but a chain of trust from a higher up key MUST result in a secure state for the name of the closest key. So, that if 'example.com' does not work, and you use the root key, then insecure com delegations do not downgrade security. The higher key MUST then build a chain of trust to the lower name. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp2qxQACgkQkDLqNwOhpPi/pACfTgpj2VM9/EvbKsG7adQA6RuY HRcAoJBZ+k9Rq5nBjEsvClaboJCuQjdW =Qfi/ -----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 Aug 3 09:50: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 265203A691F; Mon, 3 Aug 2009 09:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 X360JrappU8J; Mon, 3 Aug 2009 09:50:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27FA73A6D1F; Mon, 3 Aug 2009 09:50:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY0YN-000ANu-Mf for namedroppers-data0@psg.com; Mon, 03 Aug 2009 16:38:27 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:918c] (helo=out-66.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY0YJ-000ANU-0F for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 16:38:25 +0000 Received: from smtp-13.smtp.ucla.edu (smtp-13.smtp.ucla.edu [169.232.46.240]) by out-66.smtp.ucla.edu with ESMTP id n73GbgDZ017821; Mon, 03 Aug 2009 09:37:42 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-13.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n73GbgDZ017821; Mon, 3 Aug 2009 09:37:42 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n73Gbd3j019605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Aug 2009 09:37:41 -0700 Cc: "namedroppers@ops.ietf.org WG" Message-Id: <3F64D9EB-1ECD-43AB-87C1-B14F75316FBF@cs.ucla.edu> From: Eric Osterweil To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <583565A9-886F-41FB-92EA-B9F3E6741A7C@cisco.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] draft-crocker-dnssec-algo-signal-03 -- more time please! Date: Mon, 3 Aug 2009 10:37:35 -0600 References: <583565A9-886F-41FB-92EA-B9F3E6741A7C@cisco.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 30, 2009, at 1:54 AM, Patrik F=E4ltstr=F6m wrote: > A status report... > > People are still reaching out to me, and it is pretty clear to me =20 > that many people have problems answering yes or no to the question, =20= > and that seems to be similar reasons as both yes and no people want =20= > to talk so much about the issue. > > I will next week summarize in a bit more detail, but it seems people =20= > have the feeling that as the overall goal for standards in the IETF =20= > is interoperability, and the question is really what impact multiple =20= > algorithms have on real life interoperability. How are the =20 > algorithms selected? What if everyone "just pick" a favorite? If we =20= > are going to have preferred algorithms, how do we shift in and shift =20= > out algorithms in that pool (that might have only one entry)? How do =20= > we roll over algorithms? Etc... > > Everyone (almost) I have talked with think that if we only talked =20 > about the real problem, then most certainly one of the things that =20 > will be needed is some kind of signalling, for example in the =20 > transition from one algorithm to another, but at this point in time =20= > -- that is impossible to say. > > So at the moment, I see the consensus in the wg is "not yet, we need =20= > to work on other documents first, or at least in parallell". > > But, I at the same time think I have been contacted by "no" sayers =20 > more than "yes" sayers, so I ask the wg chairs for another week of =20 > work on what my findings on what the consensus of the wg is. I don't know if this response comes too late in the process, but I'd =20 like to express my support for this document and the ideas in it. I'm =20= happy to provide more specific reasons for why I feel this is a really =20= good idea, and why I think we should pursue it if I am, indeed, not =20 too late here. Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkp3ElMACgkQK/tq6CJjZQID0ACaA6gpTxK+sLCf0G8j1rgCMg2u fiQAnAldz5JV/HqwbJuojkyNp/mOexaB =3DTj50 -----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 Aug 3 10:23: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 4852228C1AF; Mon, 3 Aug 2009 10:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xwFrP-fUYOS; Mon, 3 Aug 2009 10:23:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF1E128C1BF; Mon, 3 Aug 2009 10:23:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY19N-000F31-Qy for namedroppers-data0@psg.com; Mon, 03 Aug 2009 17:16:41 +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 1MY19J-000F1G-4R for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 17:16:39 +0000 Received: from [10.31.200.165] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n73HGTIb022024; Mon, 3 Aug 2009 13:16:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 3 Aug 2009 13:09:18 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Trying to reading RFC 4035 as a requirements document Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-962802706==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-962802706==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I am trying to boil this document into a list of requirements and have run across a "MUST NOT" that I can't parse. "and MUST NOT perform any of the additional processing described below." The "additional processing described below" seems to be missing or has been altered in someway to make me wonder what is to be skipped - coming from the perspective of already understanding the protocol. Following the "offending" use of requirement language (in the same paragraph) is a comment that DS's "always require" special processing, which is a contradiction with the previous MUST NOT. The next point is about handling queries that are ambiguous, specifically the QNAME, CLASS, NSEC for names owning an NS set. This situation applies DNSSEC or not. Then there is talk about handling the CD and AD bits in situations they are to be ignored. (Does this mean that without the DNSSEC indication in the query, we have to look at these bits? - the old double negative conundrum.) Finally the comment about CNAME synthesis and "server... SHOULD NOT generate signatures". Ignoring a negative requirement - a little hard to test. I have no fix in mind because I'm puzzled about the intent of the offending requirement fragment. Perhaps it should be omitted? The text for convenience. "^^^^" underlines the problem. # 3. Serving # # ... # # A security-aware name server that receives a DNS query that does not # include the EDNS OPT pseudo-RR or that has the DO bit clear MUST # treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and # MUST NOT perform any of the additional processing described below. ---------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # Because the DS RR type has the peculiar property of only existing in # the parent zone at delegation points, DS RRs always require some # special processing, as described in Section 3.1.4.1. # # Security aware name servers that receive explicit queries for # security RR types that match the content of more than one zone that # it serves (for example, NSEC and RRSIG RRs above and below a # delegation point where the server is authoritative for both zones) # should behave self-consistently. As long as the response is always # consistent for each query to the name server, the name server MAY # return one of the following: # # o The above-delegation RRsets. # o The below-delegation RRsets. # o Both above and below-delegation RRsets. # o Empty answer section (no records). # o Some other response. # o An error. # # DNSSEC allocates two new bits in the DNS message header: the CD # (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit # is controlled by resolvers; a security-aware name server MUST copy # the CD bit from a query into the corresponding response. The AD bit # is controlled by name servers; a security-aware name server MUST # ignore the setting of the AD bit in queries. See Sections 3.1.6, # 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. # # A security aware name server that synthesizes CNAME RRs from DNAME # RRs as described in [RFC2672] SHOULD NOT generate signatures for the # synthesized CNAME RRs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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. --============_-962802706==_ma============ Content-Type: text/html; charset="us-ascii" Trying to reading RFC 4035 as a requirements document
I am trying to boil this document into a list of requirements and have run across a "MUST NOT" that I can't parse.

"and MUST NOT perform any of the additional processing described below."

The "additional processing described below" seems to be missing or has been altered in someway to make me wonder what is to be skipped - coming from the perspective of already understanding the protocol.

Following the "offending" use of requirement language (in the same paragraph) is a comment that DS's "always require" special processing, which is a contradiction with the previous MUST NOT.

The next point is about handling queries that are ambiguous, specifically the QNAME, CLASS, NSEC for names owning an NS set.  This situation applies DNSSEC or not.

Then there is talk about handling the CD and AD bits in situations they are to be ignored.  (Does this mean that without the DNSSEC indication in the query, we have to look at these bits? - the old double negative conundrum.)

Finally the comment about CNAME synthesis and "server... SHOULD NOT generate signatures".  Ignoring a negative requirement - a little hard to test.

I have no fix in mind because I'm puzzled about the intent of the offending requirement fragment.  Perhaps it should be omitted?

The text for convenience.  "^^^^" underlines the problem.

# 3.  Serving
#
#    ...
#
#    A security-aware name server that receives a DNS query that does not
#    include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
#    treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
#    MUST NOT perform any of the additional processing described below.
---------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#    Because the DS RR type has the peculiar property of only existing in
#    the parent zone at delegation points, DS RRs always require some
#    special processing, as described in Section 3.1.4.1.
#
#    Security aware name servers that receive explicit queries for
#    security RR types that match the content of more than one zone that
#    it serves (for example, NSEC and RRSIG RRs above and below a
#    delegation point where the server is authoritative for both zones)
#    should behave self-consistently.  As long as the response is always
#    consistent for each query to the name server, the name server MAY
#    return one of the following:
#
#    o  The above-delegation RRsets.
#    o  The below-delegation RRsets.
#    o  Both above and below-delegation RRsets.
#    o  Empty answer section (no records).
#    o  Some other response.
#    o  An error.
#
#    DNSSEC allocates two new bits in the DNS message header: the CD
#    (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
#    is controlled by resolvers; a security-aware name server MUST copy
#    the CD bit from a query into the corresponding response.  The AD bit
#    is controlled by name servers; a security-aware name server MUST
#    ignore the setting of the AD bit in queries.  See Sections 3.1.6,
#    3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
#
#    A security aware name server that synthesizes CNAME RRs from DNAME
#    RRs as described in [RFC2672] SHOULD NOT generate signatures for the
#    synthesized CNAME RRs.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
--============_-962802706==_ma============-- -- to unsubscribe send a message to namedroppers-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 Aug 3 11:34: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 EE0343A6A2D; Mon, 3 Aug 2009 11:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.978 X-Spam-Level: X-Spam-Status: No, score=-4.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX5YwnkQfWt4; Mon, 3 Aug 2009 11:34:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D3B83A677C; Mon, 3 Aug 2009 11:34:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY2EY-00021m-4s for namedroppers-data0@psg.com; Mon, 03 Aug 2009 18:26:06 +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 1MY2EU-00021C-Mm for namedroppers@ops.ietf.org; Mon, 03 Aug 2009 18:26:04 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 2C0E2A94442; Mon, 3 Aug 2009 18:26:02 +0000 (UTC) Message-ID: <4A772BB9.6040707@mail-abuse.org> Date: Mon, 03 Aug 2009 11:26:01 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Michael Graff CC: Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7/31/09 11:24 AM, Michael Graff wrote: > I would like to see someone find out two things. > > One, if the bottleneck and fear of something that has been around for > many years (DNS over TCP) is on the equipment, OS, or DNS server code. UDP fragmentation can overwhelm reassembly resources. Fallback to TCP is not as robust against attack compared to SCTP. For example, SCTP allows initial state to be held in initialization cookies, and not by servers. Persistent SCTP connections offer roughly the same performance obtained by UDP, and with better control over congestion, while encouraging use of IPv6. > Two, how is this not a DDoS vector waiting to happen today? It is a question of the resources needed to either defend against: a) highly amplified UDP reflected attacks b) TCP resource exhaustion In either scenario, _substantial_ increases in resources is necessitated. SCTP should reduce resource consumption, retain low latency, and protect from reflected and cache poisoning attacks. SCTP could be adopted by a relatively few ISPs as an assured transport (a safe harbor) during periods of abuse to limit the level of disruption that attacks might cause. > In short, why is the increase if TCP in real queries a real problem when > in a properly chosen algorithm and with reasonable TTL values, it can be > minimized? DNS attacks can request non-existent resources. Non-existent resource requests can represent a poisoning vector, while also necessitating unique responses not mitigated by TTL values. When responses leads to TCP fallback, more resources are consumed, latency and amplification is increased. -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 Aug 3 23: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 151D53A69B5; Mon, 3 Aug 2009 23:15:29 -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 4LoYg1x3WN4B; Mon, 3 Aug 2009 23:15:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CB7D3A6863; Mon, 3 Aug 2009 23:15:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYD7j-000N9n-4b for namedroppers-data0@psg.com; Tue, 04 Aug 2009 06:03: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 1MYD7c-000N8G-6J for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 06:03:43 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EECE7E608C; Tue, 4 Aug 2009 06:03:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7463RuT021268; Tue, 4 Aug 2009 16:03:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908040603.n7463RuT021268@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: Subject: Re: [dnsext] Trying to reading RFC 4035 as a requirements document In-reply-to: Your message of "Mon, 03 Aug 2009 13:09:18 -0400." Date: Tue, 04 Aug 2009 16:03:27 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Edward Lewis writes: > I am trying to boil this document into a list of requirements and > have run across a "MUST NOT" that I can't parse. > > "and MUST NOT perform any of the additional processing described below." Below is all the extra DNSSEC specific processing. e.g. adding RRSIG's to prove the answer or adding NSEC records to prove non-existance. Note for George. RRSIG, DNSKEY, and NSEC RRs are expected to be returned with DO being clear. ANY similarly returns them with DO being clear and is entirely consistant with them being returned with explict queries. qmail is just broken. > The "additional processing described below" seems to be missing or > has been altered in someway to make me wonder what is to be skipped - > coming from the perspective of already understanding the protocol. > > Following the "offending" use of requirement language (in the same > paragraph) is a comment that DS's "always require" special > processing, which is a contradiction with the previous MUST NOT. Which is a comment about how to locate the DS records to be returned. You still don't add RRSIGs / NSEC records. > The next point is about handling queries that are ambiguous, > specifically the QNAME, CLASS, NSEC for names owning an NS set. This > situation applies DNSSEC or not. No it doesn't. Prior to DNSSEC answers come from the child zone. Referrals come from the parent zone. There is no ambiguity just mis-implemenations. With DNSSEC you have RRsets (NSEC and RRSIG) which exist in both the child and parent zones which are different. KEY (not DNSKEY) can also exist in both the parent and child zone at a zone cut. > Then there is talk about handling the CD and AD bits in situations > they are to be ignored. (Does this mean that without the DNSSEC > indication in the query, we have to look at these bits? - the old > double negative conundrum.) > > Finally the comment about CNAME synthesis and "server... SHOULD NOT > generate signatures". Ignoring a negative requirement - a little > hard to test. Is this better? A security aware name server that synthesizes CNAME RRs from DNAME RRs, as described in [RFC2672], SHOULD NOT generate signatures for the synthesized CNAME RRs despite that being recommended in [RFC2672]. I can't see how this is hard to test. > I have no fix in mind because I'm puzzled about the intent of the > offending requirement fragment. Perhaps it should be omitted? > > The text for convenience. "^^^^" underlines the problem. > > # 3. Serving > # > # ... > # > # A security-aware name server that receives a DNS query that does not > # include the EDNS OPT pseudo-RR or that has the DO bit clear MUST > # treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and > # MUST NOT perform any of the additional processing described below. > ---------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > # Because the DS RR type has the peculiar property of only existing in > # the parent zone at delegation points, DS RRs always require some > # special processing, as described in Section 3.1.4.1. > # > # Security aware name servers that receive explicit queries for > # security RR types that match the content of more than one zone that > # it serves (for example, NSEC and RRSIG RRs above and below a > # delegation point where the server is authoritative for both zones) > # should behave self-consistently. As long as the response is always > # consistent for each query to the name server, the name server MAY > # return one of the following: > # > # o The above-delegation RRsets. > # o The below-delegation RRsets. > # o Both above and below-delegation RRsets. > # o Empty answer section (no records). > # o Some other response. > # o An error. > # > # DNSSEC allocates two new bits in the DNS message header: the CD > # (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit > # is controlled by resolvers; a security-aware name server MUST copy > # the CD bit from a query into the corresponding response. The AD bit > # is controlled by name servers; a security-aware name server MUST > # ignore the setting of the AD bit in queries. See Sections 3.1.6, > # 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. > # > # A security aware name server that synthesizes CNAME RRs from DNAME > # RRs as described in [RFC2672] SHOULD NOT generate signatures for the > # synthesized CNAME RRs. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. -- 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 Aug 4 07:14: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 37D2D3A6832; Tue, 4 Aug 2009 07:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.443 X-Spam-Level: X-Spam-Status: No, score=-7.443 tagged_above=-999 required=5 tests=[AWL=0.994, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 2KEnlToIv5UP; Tue, 4 Aug 2009 07:14:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AE413A6FED; Tue, 4 Aug 2009 07:13:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYKW2-000FlO-66 for namedroppers-data0@psg.com; Tue, 04 Aug 2009 13:57:22 +0000 Received: from [193.0.19.66] (helo=postgirl.ripe.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYKVq-000Fi8-Re for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 13:57:12 +0000 Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MYKVh-0005qv-Mu; Tue, 04 Aug 2009 15:57:07 +0200 Received: from [193.0.21.248] (anandb.vpn.ripe.net [193.0.21.248]) by herring.ripe.net (Postfix) with ESMTP id A75B32F595; Tue, 4 Aug 2009 15:57:01 +0200 (CEST) Message-ID: <4A783E2D.6080109@ripe.net> Date: Tue, 04 Aug 2009 15:57:01 +0200 From: Anand Buddhdev User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Michael Graff Cc: "namedroppers@ops.ietf.org" Subject: [dnsext] Re: comments on draft-crocker-dnssec-algo-signal-03 References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 55cb38632435e2bda366ab4462548c1f29c9bcb49e0abc912171cc0781bff660 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 31/7/09 20:24, Michael Graff wrote: > I would like to see someonefind out two things. > > One, if the bottleneck and fear of something that gas been around for > many years (DNS over tcp) is on the equipment, os, or DNS server code. > > Two, how is this not a ddos vector waiting to happen today? > > That is, provisioning against stress and planning on ddos, how would an > admin react differently in server and network capacity planning? > > In short, why is the increase if tcp in real queries a real problem when > in a properly chosen algorithm and with reasonable ttl values, it can be > minimized? Michael, I'm speaking here as an operator of an anycast network of DNS servers. I am concerned that TCP is not suited to anycast. Current TCP levels are low enough that any problems, if they exist, are too small to be noticeable. If more DNS traffic were to be transported over TCP, then there would be more broken TCP connections caused by "POP switching". DNS anycast has been a big success because both UDP and anycast are stateless. Throw in TCP, and it's not so simple any more. Regards, Anand Buddhdev DNS Services Manager, RIPE NCC -- to unsubscribe send a message to namedroppers-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 Aug 4 09:06: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 D9CB628C46C; Tue, 4 Aug 2009 09:06:29 -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 jaDjaavTeFvD; Tue, 4 Aug 2009 09:06:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE98B28C486; Tue, 4 Aug 2009 09:04:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYMPB-000AkS-EL for namedroppers-data0@psg.com; Tue, 04 Aug 2009 15:58:25 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYMP7-000Ajz-Gm for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 15:58:23 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSnhalnd8IW9JGlGF05lIPPCseD6XFqEU@postini.com; Tue, 04 Aug 2009 08:58:21 PDT Received: from webmail.nominum.com (exchange-10.nominum.com [64.89.228.57]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "exchange-10.win.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9CF921B82C6; Tue, 4 Aug 2009 08:58:24 -0700 (PDT) Received: from exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) by exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) with mapi; Tue, 4 Aug 2009 08:58:13 -0700 From: Bob Halley To: Michael Graff , Paul Vixie CC: "namedroppers@ops.ietf.org" Date: Tue, 4 Aug 2009 08:58:11 -0700 Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Thread-Topic: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Thread-Index: AcoSDmtZ0Akg4IsCTFe+QH+4A/xdRADDfJsM Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 31/07/2009 19:24, "Michael Graff" wrote: > On Jul 30, 2009, at 21:29, Paul Vixie wrote: >>>=20 >> what would it take to convince you? >=20 > I would like to see someonefind out two things. Me too. I also do not understand why there seems to be such concern about TCP use i= n forgery resilience. Nominum has used TCP as part of the forgery resilience strategy in our caching nameserver products for some time now. In our testing, and in real-world usage statistics, TCP has been a completely insignificant contributor to total DNS traffic. (These are also very short-lived connections, and wouldn't be a cause for anycast concern either.) Also, if there were TCP-related DoS issues with part of the DNS infrastructure, it seems like that would be a problem whether TCP was used in forgery resilience or not. /Bob -- to unsubscribe send a message to namedroppers-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 Aug 4 09:38: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 7C64B3A682D; Tue, 4 Aug 2009 09:38:09 -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=-0.730, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDbjRypxGWaI; Tue, 4 Aug 2009 09:38:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9955E3A67F4; Tue, 4 Aug 2009 09:38:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYMvV-000FOc-PF for namedroppers-data0@psg.com; Tue, 04 Aug 2009 16:31: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 1MYMvP-000FNH-W4 for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 16:31: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 n74GVew2032594 for ; Tue, 4 Aug 2009 12:31: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 n74GVev8032593 for namedroppers@ops.ietf.org; Tue, 4 Aug 2009 12:31:40 -0400 (EDT) (envelope-from namedroppers) Received: from [67.23.6.41] (helo=relay.sandelman.ca) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYLx5-0006F1-Ja for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 15:29:25 +0000 Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 5B2F234335; Tue, 4 Aug 2009 15:29:20 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4424B3EC5; Tue, 4 Aug 2009 11:29:19 -0400 (EDT) From: Michael Richardson To: Joe Abley cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 04 Aug 2009 11:29:19 -0400 Message-ID: <13612.1249399759@marajade.sandelman.ca> 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. ] >>>>> "Joe" =3D=3D Joe Abley writes: Joe> On 31-Jul-2009, at 10:42, Michael Richardson wrote: >> but having two signatures for any length of time on things like >> ".com IN NS" may be a concern. Joe> Note that delegation NS RRSets in the root zone (and glue A and Joe> AAAA RRSets) will not be signed. Those sets get signed in the Joe> zones which are authoritative for them. Good point. I had done a dig on .com NS and some other ccTLDs to see how frequently they had added more NS records until they hit the reply size limit.=20 --=20 ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy")= ; [ -- to unsubscribe send a message to namedroppers-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 Aug 4 10: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 9361C28C3E7; Tue, 4 Aug 2009 10:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XXKn6QDiMRf8; Tue, 4 Aug 2009 10:39:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4AE7D28C355; Tue, 4 Aug 2009 10:39:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYNtH-000OhT-Md for namedroppers-data0@psg.com; Tue, 04 Aug 2009 17:33:35 +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 1MYNtE-000Ogj-66 for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 17:33:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id ADB40AB9D5 for ; Tue, 4 Aug 2009 17:33:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: Your message of "Tue, 04 Aug 2009 08:58:11 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 04 Aug 2009 17:33:31 +0000 Message-ID: <99253.1249407211@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Bob Halley > Date: Tue, 4 Aug 2009 08:58:11 -0700 > > I also do not understand why there seems to be such concern about TCP use > in forgery resilience. > > Nominum has used TCP as part of the forgery resilience strategy in our > caching nameserver products for some time now. In our testing, and in > real-world usage statistics, TCP has been a completely insignificant > contributor to total DNS traffic. > > (These are also very short-lived connections, and wouldn't be a cause for > anycast concern either.) > > Also, if there were TCP-related DoS issues with part of the DNS > infrastructure, it seems like that would be a problem whether TCP was > used in forgery resilience or not. people don't ddos tcp/53 because nobody's depending on it, not because any fool with a one line perl script couldn't knock it down and pin it. a wise (younger) man once told me that if i had an idea that worked on a whiteboard and in a lab, i should multiply all constants by six million and see if things still looked 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 Tue Aug 4 10:57: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 6522728C44C; Tue, 4 Aug 2009 10:57:56 -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 uz25-W7ZIeEt; Tue, 4 Aug 2009 10:57:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3DA873A7077; Tue, 4 Aug 2009 10:57:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYOBO-0001HF-TA for namedroppers-data0@psg.com; Tue, 04 Aug 2009 17:52:18 +0000 Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYOBK-0001FS-W2 for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 17:52:17 +0000 Received: by ewy28 with SMTP id 28so400416ewy.41 for ; Tue, 04 Aug 2009 10:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=33jOJOdCsQtM6HclA/7hvGRsYpix01UAW4EhfBnMjRM=; b=QTUMYc7s0ab9iSKFh1r2E/pG0tSxXKCopLtbMpIx58OT4QI7yw9ay3KzIs5ctb+Wd9 nB8fXVkui2KsjqfwXtMYRJrHhC9ErfZdjUWgnvCQovgaKRZ4+2315OOKnxN+sR2oWJzp 4X8Nn25nULUeOyOGHOK/yAKZaLf4D5NgAcjKE= 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=DGZCrA4QXFDTw7rO7wghIucDNEFaUR1d1XuFZirtyLzlCEqaAZHxqEJfjGILRq+wXK LeQbZt/5JwOCN5j4FFnXUxaU+MsWAhlee4e56HWWDFDeVK/H0+sYC2Fp2uJdYsAdeZkv hM+txvb4LRDENCsiIZxgEyx6FOfE4HOVKVKcI= MIME-Version: 1.0 Received: by 10.210.44.12 with SMTP id r12mr9209038ebr.24.1249408333183; Tue, 04 Aug 2009 10:52:13 -0700 (PDT) In-Reply-To: <99253.1249407211@nsa.vix.com> References: <99253.1249407211@nsa.vix.com> From: bert hubert Date: Tue, 4 Aug 2009 19:51:53 +0200 Message-ID: <3efd34cc0908041051i66382f5fj51887c6c1f5ebad1@mail.gmail.com> Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 To: Paul Vixie 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, Aug 4, 2009 at 7:33 PM, Paul Vixie wrote: > a wise (younger) man once told me that if i had an idea that worked on a > whiteboard and in a lab, i should multiply all constants by six million > and see if things still looked good. Wow, DNS over UDP with 16 bit id field seems really dumb that way! 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 Aug 4 11:35: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 DF26F3A6895; Tue, 4 Aug 2009 11:35:33 -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 2Z9RRYifH6DL; Tue, 4 Aug 2009 11:35:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F9273A68C9; Tue, 4 Aug 2009 11:35:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYOhY-0005jV-RH for namedroppers-data0@psg.com; Tue, 04 Aug 2009 18:25: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 1MYOgx-0005Be-Hm for namedroppers@ops.ietf.org; Tue, 04 Aug 2009 18:25:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0504DAB9DA for ; Tue, 4 Aug 2009 18:21:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: Your message of "Tue, 04 Aug 2009 19:51:53 +0200." <3efd34cc0908041051i66382f5fj51887c6c1f5ebad1@mail.gmail.com> References: <99253.1249407211@nsa.vix.com> <3efd34cc0908041051i66382f5fj51887c6c1f5ebad1@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 04 Aug 2009 18:21:31 +0000 Message-ID: <1316.1249410091@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: bert hubert > Date: Tue, 4 Aug 2009 19:51:53 +0200 > > > a wise (younger) man once told me that if i had an idea that worked on a > > whiteboard and in a lab, i should multiply all constants by six million > > and see if things still looked good. > > Wow, DNS over UDP with 16 bit id field seems really dumb that way! oh yeah, very much so. but recall that transport security was an afterthought not only in DNS but in IP (see source address repudiability and random IP ID) and TCP (see random initial sequence numbers) and SMTP (see unwanted traffic). in DNS the TXID was only meant to help align incoming responses with outstanding requests, not to prevent spoofing. in that narrow sense, 16 bits was fine, since 65535 outstanding requests ought to have been enough for any requestor-responder pair. -- to unsubscribe send a message to namedroppers-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 Aug 4 17:18: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 4FF683A6A88; Tue, 4 Aug 2009 17:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_15=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 WKCeb6mAuQBy; Tue, 4 Aug 2009 17:18:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DE7B3A6985; Tue, 4 Aug 2009 17:18:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYU6M-0007ab-Vl for namedroppers-data0@psg.com; Wed, 05 Aug 2009 00:11: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 1MYU6E-0007Wc-0N for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 00:11: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 CF677E601C; Wed, 5 Aug 2009 00:11: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 n750BDtN034508; Wed, 5 Aug 2009 10:11:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908050011.n750BDtN034508@drugs.dv.isc.org> To: Michael Richardson Cc: Joe Abley , namedroppers@ops.ietf.org From: Mark Andrews References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> <13612.1249399759@marajade.sandelman.ca> Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-reply-to: Your message of "Tue, 04 Aug 2009 11:29:19 -0400." <13612.1249399759@marajade.sandelman.ca> Date: Wed, 05 Aug 2009 10:11:13 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <13612.1249399759@marajade.sandelman.ca>, Michael Richardson 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. ] > > > >>>>> "Joe" =3D=3D Joe Abley writes: > Joe> On 31-Jul-2009, at 10:42, Michael Richardson wrote: > > >> but having two signatures for any length of time on things like > >> ".com IN NS" may be a concern. > > Joe> Note that delegation NS RRSets in the root zone (and glue A and > Joe> AAAA RRSets) will not be signed. Those sets get signed in the > Joe> zones which are authoritative for them. > > Good point. > I had done a dig on .com NS and some other ccTLDs to see how > frequently they had added more NS records until they hit the reply size > limit.=20 Referrals are not and will not be the issue. Referrals usually have 1 (2 with NSEC3) RRSIG set. NXDOMAIN is the expensive response with 3 (4 with NSEC3) RRSIG sets. Mark > --=20 > ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= > lls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= > ect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= > ver[ > ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy")= > ; [ > > > -- > to 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 Aug 5 00:40: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 4175028C50D; Wed, 5 Aug 2009 00:40:39 -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 aOCgjEVdr6F4; Wed, 5 Aug 2009 00:40:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51A5828C393; Wed, 5 Aug 2009 00:40:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYawD-000IC1-Jx for namedroppers-data0@psg.com; Wed, 05 Aug 2009 07:29:29 +0000 Received: from [83.145.227.89] (helo=gusev.araneus.fi) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaw7-000I9e-0f for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 07:29:26 +0000 Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 1BCC8928B4; Wed, 5 Aug 2009 10:29:51 +0300 (EEST) Received: by guava.gson.org (Postfix, from userid 101) id 5B2387606A; Wed, 5 Aug 2009 10:29:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19065.13519.721.206474@guava.gson.org> Date: Wed, 5 Aug 2009 10:29:18 +0300 To: Paul Vixie Cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: <99253.1249407211@nsa.vix.com> References: <99253.1249407211@nsa.vix.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > > Also, if there were TCP-related DoS issues with part of the DNS > > infrastructure, it seems like that would be a problem whether TCP was > > used in forgery resilience or not. > > people don't ddos tcp/53 because nobody's depending on it, not because > any fool with a one line perl script couldn't knock it down and pin it. Perhaps not many depend on TCP now, but as DNSSEC gets more widely deployed, more and more people will depend on it, especially when resolvers fall back to advertizing small EDNS0 receive buffer sizes to deal with networks that don't handle fragmented UDP. If the TCP side of the DNS infrastructure can in fact be trivially DoSed, that's a real problem that needs to be solved. -- 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 Aug 5 04: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 5245E3A68E3; Wed, 5 Aug 2009 04:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.759 X-Spam-Level: X-Spam-Status: No, score=0.759 tagged_above=-999 required=5 tests=[AWL=-1.888, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OklU4z1jeJ51; Wed, 5 Aug 2009 04:22:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FCBA3A6BAC; Wed, 5 Aug 2009 04:22:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYeSm-000NWa-Au for namedroppers-data0@psg.com; Wed, 05 Aug 2009 11:15:20 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYeSh-000NVl-Mu for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 11:15:17 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id AEDCB3EC50; Wed, 5 Aug 2009 15:15:12 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mKTxy6reAe1q; Wed, 5 Aug 2009 15:15:12 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 44B233EC49 for ; Wed, 5 Aug 2009 15:15:12 +0400 (MSD) Message-ID: <4A7969C0.9070808@cryptocom.ru> Date: Wed, 05 Aug 2009 15:15:12 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] [Fwd: I-D Action:draft-dolmatov-dnsext-dnssec-gost-01.txt] Content-Type: multipart/mixed; boundary="------------000601080000080001050905" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------000601080000080001050905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit New version of draft devoted to GOST implementation in DNSSec hes been posted. Changes include: elimination of referencies to NSEC3 (leaving that to the next step), some typo and format corrections. Commants are appreciated. dol@ --------------000601080000080001050905 Content-Type: message/rfc822; name="I-D Action:draft-dolmatov-dnsext-dnssec-gost-01.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D Action:draft-dolmatov-dnsext-dnssec-gost-01.txt.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb3 (2006-10-05) on mx.cryptocom.ru X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.7-deb3 X-Original-To: dol@cryptocom.ru Delivered-To: dol@cryptocom.ru Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id DF9223EC50; Wed, 5 Aug 2009 15:01:02 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WvINyzPbd7lf; Wed, 5 Aug 2009 15:01:02 +0400 (MSD) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.cryptocom.ru (Postfix) with ESMTP id 3C13A3EC49 for ; Wed, 5 Aug 2009 15:01:02 +0400 (MSD) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1285F3A71CC; Wed, 5 Aug 2009 04:00:03 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7A5343A71C7; Wed, 5 Aug 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-dolmatov-dnsext-dnssec-gost-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090805110001.7A5343A71C7@core3.amsl.com> Date: Wed, 5 Aug 2009 04:00:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : V. Dolmatov, et al. Filename : draft-dolmatov-dnsext-dnssec-gost-01.txt Pages : 6 Date : 2009-08-05 This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). V.Dolmatov Expires February 05, 2010 [page 1] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolmatov-dnsext-dnssec-gost-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-dolmatov-dnsext-dnssec-gost-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-05035046.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------000601080000080001050905-- -- to unsubscribe send a message to namedroppers-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 Aug 5 04: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 26A8228C568; Wed, 5 Aug 2009 04:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.231 X-Spam-Level: * X-Spam-Status: No, score=1.231 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LExaP1woSSHF; Wed, 5 Aug 2009 04:25:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 800A03A6B5C; Wed, 5 Aug 2009 04:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYeXw-000OVh-0X for namedroppers-data0@psg.com; Wed, 05 Aug 2009 11:20:40 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYeXk-000OP6-Ga for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 11:20:37 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id AC6FC3EC50; Wed, 5 Aug 2009 15:20:27 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RbAyZa6Vof89; Wed, 5 Aug 2009 15:20:27 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 163DA3EC49; Wed, 5 Aug 2009 15:20:27 +0400 (MSD) Message-ID: <4A796AFB.2070905@cryptocom.ru> Date: Wed, 05 Aug 2009 15:20:27 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: namedroppers@ops.ietf.org, cfrg@irtf.org, saag@ietf.org Subject: [dnsext] [Fwd: I-D Action:draft-dolmatov-cryptocom-gost2814789-01.txt] Content-Type: multipart/mixed; boundary="------------010904070109070104010906" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------010904070109070104010906 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit New I-D has been posted, which is a translation to English of text of Russian GOST standard (GOST 28147-89) for block ciphering. This publication being combined with the drafts draft-dolmatov-cryptocom-gost34102001-02 draft-dolmatov-cryptocom-gost341194-01 forms a complete set of Russian cryptographic GOST standards in English. dol@ --------------010904070109070104010906 Content-Type: message/rfc822; name="I-D Action:draft-dolmatov-cryptocom-gost2814789-01.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D Action:draft-dolmatov-cryptocom-gost2814789-01.txt.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb3 (2006-10-05) on mx.cryptocom.ru X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.7-deb3 X-Original-To: dol@cryptocom.ru Delivered-To: dol@cryptocom.ru Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id D044F3EC4D; Wed, 5 Aug 2009 14:45:49 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bGUw-6pusTUw; Wed, 5 Aug 2009 14:45:49 +0400 (MSD) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.cryptocom.ru (Postfix) with ESMTP id 2CA2E3EC49 for ; Wed, 5 Aug 2009 14:45:49 +0400 (MSD) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD8528C553; Wed, 5 Aug 2009 03:45:03 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 88B6528C4F3; Wed, 5 Aug 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-dolmatov-cryptocom-gost2814789-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090805104501.88B6528C4F3@core3.amsl.com> Date: Wed, 5 Aug 2009 03:45:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GOST 28147-89 encryption, decryption and MAC algorithms Author(s) : V. Dolmatov, et al. Filename : draft-dolmatov-cryptocom-gost2814789-01.txt Pages : 14 Date : 2009-08-05 This document is intended to be a source of information about the Russian Federal standard for for electronic encryption, decryption and MAC algorithms (GOST 28147-89) [GOST28147], which is one of the official standards in the Russian cryptography, used in Russian algorithms (GOST algorithms). Recently, the Russian cryptography started to be used in different applications intended to work with the OpenSSL cryptographic library. Thus, this document has been created for the informational purposes for users of Russian cryptography. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost2814789-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-dolmatov-cryptocom-gost2814789-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-05033956.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------010904070109070104010906-- -- to unsubscribe send a message to namedroppers-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 Aug 5 07:30: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 85D7928C45A; Wed, 5 Aug 2009 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 jQF9kxbs8XoF; Wed, 5 Aug 2009 07:30:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97C2A28C598; Wed, 5 Aug 2009 07:30:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYhMc-000Orn-Ss for namedroppers-data0@psg.com; Wed, 05 Aug 2009 14:21:10 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febe:116e] (helo=out-61.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYhMQ-000OqJ-Le for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 14:21:00 +0000 Received: from smtp-12.smtp.ucla.edu (smtp-12.smtp.ucla.edu [169.232.46.248]) by out-61.smtp.ucla.edu with ESMTP id n75EKlYK013243; Wed, 05 Aug 2009 07:20:48 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.150]) by smtp-12.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n75EKlYK013243; Wed, 5 Aug 2009 07:20:47 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n75EKiT0012894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2009 07:20:45 -0700 Cc: Paul Vixie , "namedroppers@ops.ietf.org" Message-Id: <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> From: Eric Osterweil To: Andreas Gustafsson In-Reply-To: <19065.13519.721.206474@guava.gson.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Wed, 5 Aug 2009 08:20:38 -0600 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.248 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2009, at 1:29 AM, Andreas Gustafsson wrote: > Paul Vixie wrote: >>> Also, if there were TCP-related DoS issues with part of the DNS >>> infrastructure, it seems like that would be a problem whether TCP =20= >>> was >>> used in forgery resilience or not. >> >> people don't ddos tcp/53 because nobody's depending on it, not =20 >> because >> any fool with a one line perl script couldn't knock it down and pin =20= >> it. > > Perhaps not many depend on TCP now, but as DNSSEC gets more widely > deployed, more and more people will depend on it, especially when > resolvers fall back to advertizing small EDNS0 receive buffer sizes to > deal with networks that don't handle fragmented UDP. If the TCP side > of the DNS infrastructure can in fact be trivially DoSed, that's a > real problem that needs to be solved. Alternately, resolvers could avoid naively falling back to TCP when a =20= more appropriate buffer size would work. When TCP is needed (because =20= messages just won't fit over the path between a resolver and a name =20 server), that is the end of the story and TCP should be used. =20 However, TCP shouldn't be overused just because resolvers don't try =20 more sane values between 4096 and 512. A miscreant can, of course, still bomb port 53 w/ TCP, but keeping =20 legitimate queries on UDP where possible spares name servers =20 unnecessary load. Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkp5lToACgkQK/tq6CJjZQKAygCfYtPsPJ+gJTNvotVeGnqdZVLh 8hAAnA3pPIDyByPRuqzhziDf+LG18h8K =3DfIHv -----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 Aug 5 07:31: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 2B1F328C571; Wed, 5 Aug 2009 07:31: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 0FibwvUhbYDg; Wed, 5 Aug 2009 07:31:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E79C28C56E; Wed, 5 Aug 2009 07:31:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYhTH-000Pnu-OZ for namedroppers-data0@psg.com; Wed, 05 Aug 2009 14:28:03 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYhSv-000Pjf-RS for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 14:27:44 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7585AABB6D; Wed, 5 Aug 2009 14:27:41 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Andreas Gustafsson cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: Your message of "Wed, 05 Aug 2009 10:29:18 +0300." <19065.13519.721.206474@guava.gson.org> References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 05 Aug 2009 14:27:41 +0000 Message-ID: <48838.1249482461@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Wed, 5 Aug 2009 10:29:18 +0300 > From: Andreas Gustafsson > > ... If the TCP side of the DNS infrastructure can in fact be trivially > DoSed, ... yes. > ... that's a real problem that needs to be solved. one of the reasons i've been ignoring the current round of discussion about whether tcp is evil or not, is that i'd rather work on a 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 owner-namedroppers@ops.ietf.org Wed Aug 5 08:05: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 36AA828C45B; Wed, 5 Aug 2009 08:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ASL7I6BJtjWb; Wed, 5 Aug 2009 08:05:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92D0428C5BA; Wed, 5 Aug 2009 08:04:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYhwH-0005L3-7B for namedroppers-data0@psg.com; Wed, 05 Aug 2009 14:58: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 1MYhw7-0005IT-9V for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 14:57:56 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E0608ABB7B for ; Wed, 5 Aug 2009 14:57:50 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: Your message of "Wed, 05 Aug 2009 08:20:38 CST." <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 05 Aug 2009 14:57:50 +0000 Message-ID: <50179.1249484270@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Eric Osterweil > Date: Wed, 5 Aug 2009 08:20:38 -0600 > > ... However, TCP shouldn't be overused just because resolvers don't try > more sane values between 4096 and 512. is this input for EDNS0-bis, specifically, new fallback advice? if so then i hope it's been overtaken by events. the approach i recommend is, try EDNS0 and if it doesn't work, give the hell up, go back to DNS, forget about DNSSEC and any other EDNS-enabled feature for that transaction and for other transactions to that server for some period of time, after which, retry EDNS0. rationale: when there is something in the middle of the network that corrupts packets, the endpoints should detect this but not correct it. correcting it should be left to the operators and implementors of the middleboxes. users whose service level is lower because of the corruption, should complain. > A miscreant can, of course, still bomb port 53 w/ TCP, but keeping > legitimate queries on UDP where possible spares name servers unnecessary > load. a security-aware design requires that we not paint the target on our ass in the first place. if TCP/53 is trivially ddos-able, then we have to expect such ddos's to take place the moment there is value in launching them. so, our own correct but unnecessary load is not a worthy consideration, only our dependence and/or modalities. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From houseplants65@isbenaslodge.com Wed Aug 5 08:35: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 85E6B3A6C09; Wed, 5 Aug 2009 08:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.051 X-Spam-Level: X-Spam-Status: No, score=-15.051 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_DOYOU2=1.633, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 SZH5iPifHRTd; Wed, 5 Aug 2009 08:35:09 -0700 (PDT) Received: from 200-140-61-89.gnace701.dsl.brasiltelecom.net.br (200-140-155-93.gnace701.dsl.brasiltelecom.net.br [200.140.155.93]) by core3.amsl.com (Postfix) with ESMTP id C5FD13A6C15; Wed, 5 Aug 2009 08:34:55 -0700 (PDT) Received: from 200.140.155.93 by backupmail.soru.me.uk.isbenaslodge.com; Wed, 5 Aug 2009 12:34:19 -0300 Content-type: text/html; charset="UTF-8" MIME-Version: 1.0 Message-ID: Date: Wed, 5 Aug 2009 12:34:19 -0300 From: "Joann Fenton" To: eap-archive@ietf.org Subject: Do you have 14 days to take part in our weight loss trial? Its easy to look great with Acai berry in your diet. Break into this site http://aiankypo.cn best regards Joann Fenton From owner-namedroppers@ops.ietf.org Wed Aug 5 08:41: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 98DF13A693D; Wed, 5 Aug 2009 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.145 X-Spam-Level: X-Spam-Status: No, score=-5.145 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 8moB7V-S43Er; Wed, 5 Aug 2009 08:41:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8334F3A682C; Wed, 5 Aug 2009 08:41:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYiVP-000Bqe-0E for namedroppers-data0@psg.com; Wed, 05 Aug 2009 15:34:19 +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 1MYiVD-000BpT-5o for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 15:34:08 +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 n75FY3Vg001172; Wed, 5 Aug 2009 08:34:03 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org" Message-Id: <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> From: Nicholas Weaver To: Paul Vixie In-Reply-To: <50179.1249484270@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] comments on draft-crocker-dnssec-algo-signal-03 Date: Wed, 5 Aug 2009 08:34:02 -0700 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 5, 2009, at 7:57 AM, Paul Vixie wrote: >> From: Eric Osterweil >> Date: Wed, 5 Aug 2009 08:20:38 -0600 >> >> ... However, TCP shouldn't be overused just because resolvers don't >> try >> more sane values between 4096 and 512. > > is this input for EDNS0-bis, specifically, new fallback advice? if > so then > i hope it's been overtaken by events. the approach i recommend is, > try EDNS0 > and if it doesn't work, give the hell up, go back to DNS, forget > about DNSSEC > and any other EDNS-enabled feature for that transaction and for other > transactions to that server for some period of time, after which, > retry EDNS0. > > rationale: when there is something in the middle of the network that > corrupts > packets, the endpoints should detect this but not correct it. > correcting it > should be left to the operators and implementors of the > middleboxes. users > whose service level is lower because of the corruption, should > complain. I think this advice should be different these days. The in-path corruption for recursive resolvers is commonly an inability to handle fragments, and for end-hosts its most commonly an inability to handle fragments or an assumption that DNS=512B. Actually not being able to handle EDNS0 at all is the minority case from the observations we reported. Thus the fallback should probably be: EDNS0 @ 4096 EDNS0 @ 1400 EDNS0 @ 512 with each using a fallback to TCP on truncation, and only if EDNS0 @ 512B doesn't work should one decide "No EDNS, give up" And it is, IMO, impossible to get the operators and middleboxes to change. Look at the pulling-teeth hastle people have on trying to get, say, 2-wire to fix trivial vulnerabilities in their NATs, let alone more subtle denial of service conditions. Thus the algorithm/fallback should understand the common causes of corruption and attempt to work around them, out of operational necessity. -- to unsubscribe send a message to namedroppers-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 Aug 5 09:02: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 C9A433A6A12; Wed, 5 Aug 2009 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ptkdO0X1UGtk; Wed, 5 Aug 2009 09:02:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B807E3A6824; Wed, 5 Aug 2009 09:02:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYis3-000G0h-Q9 for namedroppers-data0@psg.com; Wed, 05 Aug 2009 15:57:43 +0000 Received: from [2607:f010:3fe:302:1013:72ff:fe5b:6032] (helo=out-31.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYirw-000Fys-3T for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 15:57:38 +0000 Received: from smtp-6.smtp.ucla.edu (smtp-6.smtp.ucla.edu [169.232.48.241]) by out-31.smtp.ucla.edu with ESMTP id n75FuhMT011560; Wed, 05 Aug 2009 08:56:45 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-6.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n75FuhMT011560; Wed, 5 Aug 2009 08:56:43 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n75Fufc4017619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2009 08:56:42 -0700 Cc: Paul Vixie , "namedroppers@ops.ietf.org" Message-Id: From: Eric Osterweil To: Nicholas Weaver In-Reply-To: <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Wed, 5 Aug 2009 09:56:39 -0600 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.241 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2009, at 9:34 AM, Nicholas Weaver wrote: > > On Aug 5, 2009, at 7:57 AM, Paul Vixie wrote: > >>> From: Eric Osterweil >>> Date: Wed, 5 Aug 2009 08:20:38 -0600 >>> >>> ... However, TCP shouldn't be overused just because resolvers =20 >>> don't try >>> more sane values between 4096 and 512. >> >> is this input for EDNS0-bis, specifically, new fallback advice? if =20= >> so then >> i hope it's been overtaken by events. the approach i recommend is, =20= >> try EDNS0 >> and if it doesn't work, give the hell up, go back to DNS, forget =20 >> about DNSSEC >> and any other EDNS-enabled feature for that transaction and for other >> transactions to that server for some period of time, after which, =20 >> retry EDNS0. >> >> rationale: when there is something in the middle of the network =20 >> that corrupts >> packets, the endpoints should detect this but not correct it. =20 >> correcting it >> should be left to the operators and implementors of the =20 >> middleboxes. users >> whose service level is lower because of the corruption, should =20 >> complain. > > I think this advice should be different these days. The in-path =20 > corruption for recursive resolvers is commonly an inability to =20 > handle fragments, and for end-hosts its most commonly an inability =20 > to handle fragments or an assumption that DNS=3D512B. Actually not =20= > being able to handle EDNS0 at all is the minority case from the =20 > observations we reported. > > Thus the fallback should probably be: > EDNS0 @ 4096 > EDNS0 @ 1400 > EDNS0 @ 512 > with each using a fallback to TCP on truncation, and only if EDNS0 @ =20= > 512B doesn't work should one decide "No EDNS, give up" > > And it is, IMO, impossible to get the operators and middleboxes to =20 > change. Look at the pulling-teeth hastle people have on trying to =20 > get, say, 2-wire to fix trivial vulnerabilities in their NATs, let =20 > alone more subtle denial of service conditions. > > Thus the algorithm/fallback should understand the common causes of =20 > corruption and attempt to work around them, out of operational =20 > necessity. I would completely agree with this. Especially since there is a lot =20 of evidence that resolvers often CAN overcome these issues by =20 adjusting their buffer sizes. It's a fix that can go into one of the =20= components that can be directly addressed; the resolver. That is, a =20 resolver operator who wants to fix this problem can upgrade their =20 resolver w/o addressing middleboxes that she may or may not be =20 responsible for. Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkp5q7cACgkQK/tq6CJjZQI+SQCglJC4L07CNJPiq39hUVuAyPbE JF4AnRas0BVOYUisKJWMeRR5wP6RoaA4 =3DU/Kr -----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 Aug 5 11:55: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 A39B73A6C4C; Wed, 5 Aug 2009 11:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 v5cQs2-QduTm; Wed, 5 Aug 2009 11:55:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE63E3A71F8; Wed, 5 Aug 2009 11:55:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYlVH-000KLJ-PT for namedroppers-data0@psg.com; Wed, 05 Aug 2009 18:46:23 +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 1MYlV9-000KKU-Kd for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 18:46:20 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 00852A9443B; Wed, 5 Aug 2009 18:46:14 +0000 (UTC) Message-ID: <4A79D376.3050606@mail-abuse.org> Date: Wed, 05 Aug 2009 11:46:14 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Eric Osterweil CC: Nicholas Weaver , Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/5/09 8:56 AM, Eric Osterweil wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Aug 5, 2009, at 9:34 AM, Nicholas Weaver wrote: > >> >> On Aug 5, 2009, at 7:57 AM, Paul Vixie wrote: >> >>>> From: Eric Osterweil >>>> Date: Wed, 5 Aug 2009 08:20:38 -0600 >>>> >>>> ... However, TCP shouldn't be overused just because resolvers don't try >>>> more sane values between 4096 and 512. >>> >>> is this input for EDNS0-bis, specifically, new fallback advice? if so >>> then >>> i hope it's been overtaken by events. the approach i recommend is, >>> try EDNS0 >>> and if it doesn't work, give the hell up, go back to DNS, forget >>> about DNSSEC >>> and any other EDNS-enabled feature for that transaction and for other >>> transactions to that server for some period of time, after which, >>> retry EDNS0. >>> >>> rationale: when there is something in the middle of the network that >>> corrupts >>> packets, the endpoints should detect this but not correct it. >>> correcting it >>> should be left to the operators and implementors of the middleboxes. >>> users >>> whose service level is lower because of the corruption, should complain. >> >> I think this advice should be different these days. The in-path >> corruption for recursive resolvers is commonly an inability to handle >> fragments, and for end-hosts its most commonly an inability to handle >> fragments or an assumption that DNS=512B. Actually not being able to >> handle EDNS0 at all is the minority case from the observations we >> reported. >> >> Thus the fallback should probably be: >> EDNS0 @ 4096 >> EDNS0 @ 1400 >> EDNS0 @ 512 >> with each using a fallback to TCP on truncation, and only if EDNS0 @ >> 512B doesn't work should one decide "No EDNS, give up" >> >> And it is, IMO, impossible to get the operators and middleboxes to >> change. Look at the pulling-teeth hastle people have on trying to get, >> say, 2-wire to fix trivial vulnerabilities in their NATs, let alone >> more subtle denial of service conditions. >> >> Thus the algorithm/fallback should understand the common causes of >> corruption and attempt to work around them, out of operational necessity. > > I would completely agree with this. Especially since there is a lot of > evidence that resolvers often CAN overcome these issues by adjusting > their buffer sizes. It's a fix that can go into one of the components > that can be directly addressed; the resolver. That is, a resolver > operator who wants to fix this problem can upgrade their resolver w/o > addressing middleboxes that she may or may not be responsible for. Middle boxes will experience about 1.5 times the traffic that EDNS0@4096 alone might have created. This traffic might already be at an amplification of 80. The 1.5x increased traffic and 3x increased latency will aggravate packet loss during ongoing attacks and may cause higher levels of TCP fallback during attack scenarios. With TCP fallback, amplifications increased to 4 times that of a functional ENDS0@4096. Now consider the use of SMTP authorization macros embedded within cached resource records that can further increase the number of transactions of often large TXT records by factors that range from 10 to 100, without costing the attacker additional resources beyond what was used to spam. The macros allow local-parts to modulate the requests. The macro processing has become embedded within several MTAs and various MUA spam filters. -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 Aug 5 11:57: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 A21CD3A7214; Wed, 5 Aug 2009 11:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 Sk4mny5Xb2kt; Wed, 5 Aug 2009 11:57:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B00373A6C4C; Wed, 5 Aug 2009 11:57:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYldF-000LW4-DW for namedroppers-data0@psg.com; Wed, 05 Aug 2009 18:54: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 1MYldB-000LUD-FA for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 18:54: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 n75IsTB3024045; Wed, 5 Aug 2009 11:54:29 -0700 (PDT) Cc: Nicholas Weaver , Eric Osterweil , Paul Vixie , "namedroppers@ops.ietf.org" Message-Id: <70E51974-780A-48F1-86CF-A0195CFE5F23@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Douglas Otis In-Reply-To: <4A79D376.3050606@mail-abuse.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] comments on draft-crocker-dnssec-algo-signal-03 Date: Wed, 5 Aug 2009 11:54:28 -0700 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <4A79D376.3050606@mail-abuse.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 5, 2009, at 11:46 AM, Douglas Otis wrote: >> >> I would completely agree with this. Especially since there is a lot >> of >> evidence that resolvers often CAN overcome these issues by adjusting >> their buffer sizes. It's a fix that can go into one of the components >> that can be directly addressed; the resolver. That is, a resolver >> operator who wants to fix this problem can upgrade their resolver w/o >> addressing middleboxes that she may or may not be responsible for. > > Middle boxes will experience about 1.5 times the traffic that > EDNS0@4096 alone might have created. This traffic might already be > at an amplification of 80. The 1.5x increased traffic and 3x > increased latency will aggravate packet loss during ongoing attacks > and may cause higher levels of TCP fallback during attack > scenarios. With TCP fallback, amplifications increased to 4 times > that of a functional ENDS0@4096. There is nothing to say that such fallback shouldn't be stateful: Once you know what an authority's level of response is, the results should obviously be cached, which eliminates the extra RTTs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mesabiepa97@iso-iki.com Wed Aug 5 12:17: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 021B928C586; Wed, 5 Aug 2009 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.474 X-Spam-Level: X-Spam-Status: No, score=-21.474 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, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, 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_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, 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 NzBYfiRVTfBW; Wed, 5 Aug 2009 12:17:25 -0700 (PDT) Received: from 201-24-209-139.mganm703.e.brasiltelecom.net.br (201-24-209-139.mganm703.e.brasiltelecom.net.br [201.24.209.139]) by core3.amsl.com (Postfix) with ESMTP id 2AFF93A71CD; Wed, 5 Aug 2009 12:17:24 -0700 (PDT) Received: from 201.24.209.139 by iso-iki.com; Wed, 5 Aug 2009 16:15:29 -0300 Message-ID: <000d01ca1601$185eba00$6400a8c0@mesabiepa97> From: dnsext-archive@lists.ietf.org To: Subject: Acai dissolves unwanted fats Date: Wed, 5 Aug 2009 16:15:29 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1601.185EBA00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1601.185EBA00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Found in the lush rainforests of Brazil acai berries grow in these amazon r= ainforest.   Acai Slim, lose weight without impossible diets.=20 =20 Lose weight safely with Acai diet , endorsed by Oprah.=20 =20 =20 Visit this site best regards Skyla=20 Crow ------=_NextPart_000_0007_01CA1601.185EBA00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Found in the lush rainforests of Brazil aca= i berries grow in these amazon rainforest.
 
Acai Slim, lose weight without imposs= ible diets.
Lose weight safely with Acai diet , e= ndorsed by Oprah.

=20 Visit this site<= /FONT>

best regards Skyla=20 Crow
------=_NextPart_000_0007_01CA1601.185EBA00-- From owner-namedroppers@ops.ietf.org Wed Aug 5 12:51: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 BC0453A6BC1; Wed, 5 Aug 2009 12:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 WNqT36jQpBu4; Wed, 5 Aug 2009 12:51:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C22A93A6AD5; Wed, 5 Aug 2009 12:51:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYmOU-0003Xi-DA for namedroppers-data0@psg.com; Wed, 05 Aug 2009 19:43:26 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:93ec] (helo=out-76.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYmOQ-0003XA-Ep for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 19:43:24 +0000 Received: from smtp-15.smtp.ucla.edu (smtp-15.smtp.ucla.edu [169.232.46.242]) by out-76.smtp.ucla.edu with ESMTP id n75JhAO4024030; Wed, 05 Aug 2009 12:43:10 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-15.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n75JhAO4024030; Wed, 5 Aug 2009 12:43:10 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n75Jgh9n010110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2009 12:43:09 -0700 Cc: Douglas Otis , Paul Vixie , "namedroppers@ops.ietf.org" Message-Id: <3B007718-2106-4629-A6E0-52D8EEE21BA3@CS.UCLA.EDU> From: Eric Osterweil To: Nicholas Weaver In-Reply-To: <70E51974-780A-48F1-86CF-A0195CFE5F23@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Wed, 5 Aug 2009 13:43:06 -0600 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <4A79D376.3050606@mail-abuse.org> <70E51974-780A-48F1-86CF-A0195CFE5F23@ICSI.Berkeley.EDU> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.242 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2009, at 12:54 PM, Nicholas Weaver wrote: > > On Aug 5, 2009, at 11:46 AM, Douglas Otis wrote: >>> >>> I would completely agree with this. Especially since there is a =20 >>> lot of >>> evidence that resolvers often CAN overcome these issues by adjusting >>> their buffer sizes. It's a fix that can go into one of the =20 >>> components >>> that can be directly addressed; the resolver. That is, a resolver >>> operator who wants to fix this problem can upgrade their resolver =20= >>> w/o >>> addressing middleboxes that she may or may not be responsible for. >> >> Middle boxes will experience about 1.5 times the traffic that =20 >> EDNS0@4096 alone might have created. This traffic might already be =20= >> at an amplification of 80. The 1.5x increased traffic and 3x =20 >> increased latency will aggravate packet loss during ongoing attacks =20= >> and may cause higher levels of TCP fallback during attack =20 >> scenarios. With TCP fallback, amplifications increased to 4 times =20= >> that of a functional ENDS0@4096. > > There is nothing to say that such fallback shouldn't be stateful: =20 > Once you know what an authority's level of response is, the results =20= > should obviously be cached, which eliminates the extra RTTs. Indeed, resolvers already maintain per-nameserver information such as =20= RTT. Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkp54MoACgkQK/tq6CJjZQJEBACeOPQmHPTgM8icN9BjL1vcTDMa gJwAn0X28qLmuw1E9ZalYKoEpjyUQsXf =3DYNLn -----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 Aug 5 13:36: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 CA0503A7223; Wed, 5 Aug 2009 13:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2lFmV1DT4CJn; Wed, 5 Aug 2009 13:36:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B22643A6C16; Wed, 5 Aug 2009 13:36:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYn8c-0009PO-Ap for namedroppers-data0@psg.com; Wed, 05 Aug 2009 20:31: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 1MYn8Y-0009Ou-0P for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 20:31:04 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 91D99ABBE3 for ; Wed, 5 Aug 2009 20:31:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: edns fallback (was Re: [dnsext] comments on draft-crocker-...) In-Reply-To: Your message of "Wed, 05 Aug 2009 08:34:02 MST." <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 05 Aug 2009 20:31:01 +0000 Message-ID: <64437.1249504261@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i really should be writing a specific proposal rather than debating this; my apologies for my lack of self discipline as shown in two replies below. --- > From: Nicholas Weaver > Date: Wed, 5 Aug 2009 08:34:02 -0700 > > > rationale: when there is something in the middle of the network that > > corrupts packets, the endpoints should detect this but not correct it. > > correcting it should be left to the operators and implementors of the > > middleboxes. users whose service level is lower because of the > > corruption, should complain. > > I think this advice should be different these days. The in-path > corruption for recursive resolvers is commonly an inability to handle > fragments, and for end-hosts its most commonly an inability to handle > fragments or an assumption that DNS=512B. ... unless we intend that all dns protocol agents contain this level of complexity, and that all future large-UDP WAN applications (like EDNS) contain this level of complexity, and that both DNS and other large-UDP WAN applications continue to ratchet up this body count in the indefinite future, then we have to let the middle solve itself. > ... Thus the fallback should probably be: > EDNS0 @ 4096 > EDNS0 @ 1400 > EDNS0 @ 512 > with each using a fallback to TCP on truncation, and only if EDNS0 @ 512B > doesn't work should one decide "No EDNS, give up" given that each fallback can involve a timeout, the aggregate global application and end-user state load implied by having that many fallbacks is way too high. DNS is supposed to be quick and lightweight even when it fails. > And it is, IMO, impossible to get the operators and middleboxes to change. of course not. we're going to have to do DNS over XML over TCP/445 (HTTPS) when a user or their DNS protocol agent knows that or detects that it is behind a corrupting middlebox (or inside of a corrupting ISP). we already know this, and we know that no amount of EDNS or fragmentation fixage will avoid the need for it. --- > From: Eric Osterweil > Date: Wed, 5 Aug 2009 09:56:39 -0600 > > > Thus the algorithm/fallback should understand the common causes of > > corruption and attempt to work around them, out of operational > > necessity. > > I would completely agree with this. Especially since there is a lot of > evidence that resolvers often CAN overcome these issues by adjusting > their buffer sizes. It's a fix that can go into one of the components > that can be directly addressed; the resolver. That is, a resolver > operator who wants to fix this problem can upgrade their resolver w/o > addressing middleboxes that she may or may not be responsible for. this target is still moving and will keep moving. any complexity we add to the endpoints to deal with corrupting middleboxes will simply re-baseline the market for even more-corruptive middleboxes in that possible future. i don't plan to play whack-a-mole with ISP's and NAT vendors for the rest of eternity and i don't think anybody else should do so either. we're experiencing information warfare here. people in the middle want their revenue and/or their control, and they will impinge/corrupt our packets as necessary to get the win they need. they do not want reliable end-to-end DNS to be possible, or they don't care whether end-to-end DNS can evolve new features. either way they own the middle and their goals are in opposition and if we want to deliver our information we have to stop assuming that the problems we're solving are accidental and/or sitting still. --- === -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From arroyosfo246@isinorthamerica.com Wed Aug 5 13:50: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 0461C3A7229; Wed, 5 Aug 2009 13:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.177 X-Spam-Level: *** X-Spam-Status: No, score=3.177 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, 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, 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, SUBJECT_DIET=1.466, 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 kxs7ZEs+-b7R; Wed, 5 Aug 2009 13:50:07 -0700 (PDT) Received: from 82-44-113-128.cable.ubr16.enfi.blueyonder.co.uk (82-44-113-128.cable.ubr16.enfi.blueyonder.co.uk [82.44.113.128]) by core3.amsl.com (Postfix) with ESMTP id 7DFFC3A723F; Wed, 5 Aug 2009 13:48:44 -0700 (PDT) Received: from 82.44.113.128 by server112.appriver.com; Wed, 5 Aug 2009 21:48:13 +0000 Date: Wed, 5 Aug 2009 21:48:13 +0000 Message-Id: <058M1987942.4W97U7TE45395138@isinorthamerica.com> From: Junior Blackmon To: dix@ietf.org Subject: Lose Weight and Feel Great Free Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
your free trial for a skinny tight body
Get your Free Trial Now!
 
Thank You!
best regards Junior Blackmon
From owner-namedroppers@ops.ietf.org Wed Aug 5 14:41: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 461B628C57B; Wed, 5 Aug 2009 14:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.41 X-Spam-Level: X-Spam-Status: No, score=-4.41 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 8JCkpfNj3NvY; Wed, 5 Aug 2009 14:40:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1F253A693C; Wed, 5 Aug 2009 14:40:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYo94-000Hj0-51 for namedroppers-data0@psg.com; Wed, 05 Aug 2009 21:35:38 +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 1MYo90-000Hih-DR for namedroppers@ops.ietf.org; Wed, 05 Aug 2009 21:35:36 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 1A610A9443B; Wed, 5 Aug 2009 21:35:34 +0000 (UTC) Message-ID: <4A79FB25.5060706@mail-abuse.org> Date: Wed, 05 Aug 2009 14:35:33 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Nicholas Weaver CC: Eric Osterweil , Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <4A79D376.3050606@mail-abuse.org> <70E51974-780A-48F1-86CF-A0195CFE5F23@ICSI.Berkeley.EDU> In-Reply-To: <70E51974-780A-48F1-86CF-A0195CFE5F23@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/5/09 11:54 AM, Nicholas Weaver wrote: > > There is nothing to say that such fallback shouldn't be stateful: Once > you know what an authority's level of response is, the results should > obviously be cached, which eliminates the extra RTTs. The concern has been from behavior in the form of distributed attacks. Botnets lend themselves to this type of activity. Millions of DNS servers might be making requests against uncached resources from infrequently seen servers. Do not assume attackers will confine themselves to a set of known servers, or that even completing a first pass with exponential back-off occurs before initial requests time out. -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 themesok30@isaberg-rapid.net Wed Aug 5 16:46: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 8B2E23A68AB; Wed, 5 Aug 2009 16:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.593 X-Spam-Level: X-Spam-Status: No, score=-25.593 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, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, 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 JoTA7UhqkY3s; Wed, 5 Aug 2009 16:46:37 -0700 (PDT) Received: from adsl196-117-200-206-196.adsl196-7.iam.net.ma (adsl196-117-200-206-196.adsl196-7.iam.net.ma [196.206.200.117]) by core3.amsl.com (Postfix) with ESMTP id 6E0163A6898; Wed, 5 Aug 2009 16:46:36 -0700 (PDT) Received: from 196.206.200.117 by mail.anxious.se; Wed, 5 Aug 2009 23:45:58 +0000 Date: Wed, 5 Aug 2009 23:45:58 +0000 From: dnsext-archive@lists.ietf.org Subject: Everyone noticed some weight loss only after 2 weeks and energy levels increased after 5 days See How To: Message-ID: <000d01ca1626$e195ce20$6400a8c0@themesok30> 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 Start your day off right with a serving of Acai Slim everyday. Visit this minute http://aijgctqo.cn best regards Delmas Bower From owner-namedroppers@ops.ietf.org Wed Aug 5 20:16: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 DFACB3A6872; Wed, 5 Aug 2009 20:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 DhzKO7bg7kCn; Wed, 5 Aug 2009 20:16:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 650CE3A67FB; Wed, 5 Aug 2009 20:16:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYtLo-0006W2-72 for namedroppers-data0@psg.com; Thu, 06 Aug 2009 03:09:08 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:956f] (helo=out-71.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYtLh-0006UZ-87 for namedroppers@ops.ietf.org; Thu, 06 Aug 2009 03:09:04 +0000 Received: from smtp-14.smtp.ucla.edu (smtp-14.smtp.ucla.edu [169.232.46.250]) by out-71.smtp.ucla.edu with ESMTP id n7638QsI029179; Wed, 05 Aug 2009 20:08:27 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.150]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7638QsI029179; Wed, 5 Aug 2009 20:08:26 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7638PfL026861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2009 20:08:26 -0700 Cc: namedroppers@ops.ietf.org Message-Id: <7C8121AE-A721-428B-B5AB-DCDB2EE2A7DC@cs.ucla.edu> From: Eric Osterweil To: Paul Vixie In-Reply-To: <64437.1249504261@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: edns fallback (was Re: [dnsext] comments on draft-crocker-...) Date: Wed, 5 Aug 2009 21:08:18 -0600 References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <64437.1249504261@nsa.vix.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.250 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2009, at 2:31 PM, Paul Vixie wrote: > i really should be writing a specific proposal rather than debating =20= > this; > my apologies for my lack of self discipline as shown in two replies =20= > below. > > --- > >> From: Nicholas Weaver >> Date: Wed, 5 Aug 2009 08:34:02 -0700 >> >>> rationale: when there is something in the middle of the network that >>> corrupts packets, the endpoints should detect this but not correct =20= >>> it. >>> correcting it should be left to the operators and implementors of =20= >>> the >>> middleboxes. users whose service level is lower because of the >>> corruption, should complain. >> >> I think this advice should be different these days. The in-path >> corruption for recursive resolvers is commonly an inability to handle >> fragments, and for end-hosts its most commonly an inability to handle >> fragments or an assumption that DNS=3D512B. ... > > unless we intend that all dns protocol agents contain this level of > complexity, and that all future large-UDP WAN applications (like EDNS) > contain this level of complexity, and that both DNS and other large-=20= > UDP > WAN applications continue to ratchet up this body count in the =20 > indefinite > future, then we have to let the middle solve itself. The proposal here is to keep the intelligence at the ends. Much like =20= TCP adjusts its window size at the ends, these agents can adjust their =20= buffer sizes at the ends. > > >> ... Thus the fallback should probably be: >> EDNS0 @ 4096 >> EDNS0 @ 1400 >> EDNS0 @ 512 >> with each using a fallback to TCP on truncation, and only if EDNS0 =20= >> @ 512B >> doesn't work should one decide "No EDNS, give up" > > given that each fallback can involve a timeout, the aggregate global > application and end-user state load implied by having that many =20 > fallbacks > is way too high. DNS is supposed to be quick and lightweight even =20 > when it > fails. Well, some of these fallbacks result in immediate TC bits being set. =20= Intelligent guessing and persistent state (with periodic reassessment) =20= would allow for occasional timeouts, but not consistent timeouts. For =20= example, if 4096 times out, a quick 512 can tell the resolver if the =20 name server is online (not followed by a TCP connection). Then a more =20= intelligent UDP-search of the space (perhaps starting at 1400) can =20 proceed. Remember, getting TC bits is better than getting timeouts, =20 so a search of the space should keep that in mind. > > >> And it is, IMO, impossible to get the operators and middleboxes to =20= >> change. > > of course not. we're going to have to do DNS over XML over TCP/445 =20= > (HTTPS) > when a user or their DNS protocol agent knows that or detects that =20 > it is > behind a corrupting middlebox (or inside of a corrupting ISP). we =20 > already > know this, and we know that no amount of EDNS or fragmentation =20 > fixage will > avoid the need for it. This sounds like throwing the baby out with the bath water. Yes, =20 sometimes messages will not fit over the path. No, this is not always =20= the case. UDP can, and should, continue to be the best option for DNS =20= queries and responses, and TCP (or TCP/445...) can be a fallback, but =20= there doesn't seem to be a good reason overreact. > > > --- > >> From: Eric Osterweil >> Date: Wed, 5 Aug 2009 09:56:39 -0600 >> >>> Thus the algorithm/fallback should understand the common causes of >>> corruption and attempt to work around them, out of operational >>> necessity. >> >> I would completely agree with this. Especially since there is a =20 >> lot of >> evidence that resolvers often CAN overcome these issues by adjusting >> their buffer sizes. It's a fix that can go into one of the =20 >> components >> that can be directly addressed; the resolver. That is, a resolver >> operator who wants to fix this problem can upgrade their resolver w/o >> addressing middleboxes that she may or may not be responsible for. > > this target is still moving and will keep moving. any complexity we =20= > add to > the endpoints to deal with corrupting middleboxes will simply re-=20 > baseline > the market for even more-corruptive middleboxes in that possible =20 > future. i > don't plan to play whack-a-mole with ISP's and NAT vendors for the =20 > rest of > eternity and i don't think anybody else should do so either. This is about making the components of the system more robust. You =20 can't say that since there are middlebox problems resolvers should =20 avoid trying to overcome surmountable issues. This is a very simple =20 adjustment that uses all of the mechanisms that exist now. By your =20 own pen, EDNS0 allows resolvers to address this obstacle through =20 clueful choice of buffer sizes, and if done well, this can be done =20 with less overhead than a TCP connection. Prognosticating that vendors will sense weakness and pounce on us with =20= increasingly stupid appliances seems... An odd conclusion. However, =20 hamstringing our own systems to send them a message seems counter =20 productive. > > > we're experiencing information warfare here. people in the middle =20 > want their > revenue and/or their control, and they will impinge/corrupt our =20 > packets as > necessary to get the win they need. they do not want reliable end-=20 > to-end > DNS to be possible, or they don't care whether end-to-end DNS can =20 > evolve new > features. either way they own the middle and their goals are in =20 > opposition > and if we want to deliver our information we have to stop assuming =20 > that the > problems we're solving are accidental and/or sitting still. "Never ascribe to malice that which is adequately explained by =20 incompetence" I really don't know that this is a matter of warfare. I =20= don't know what business model is benefited by dropping DNSKEY =20 messages at this early stage of the deployment. If there is an on-=20 path attacker (say an ISP) then there are serious troubles no matter =20 how you slice it. However, without such an attacker, we still see =20 PMTU problems, and many of them can be solved with a little bit of =20 logic by using the provisions that already exist today (as described =20 in a few of the above emails). Seriously, I think there is a very simple set of adjustments that can =20= be made that, in many cases, will alleviate some of the frivolous TCP =20= connections. Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkp6SSYACgkQK/tq6CJjZQLPZgCfXEStN1sh8Q5yQYDIEBd3wQgU mr4AnRnA6AYKsnytdzBxE5nZZH7Ktl7Q =3DkO+6 -----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 Aug 6 07:55: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 DC60228C115; Thu, 6 Aug 2009 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.369 X-Spam-Level: X-Spam-Status: No, score=-4.369 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 4r7+akZjUWns; Thu, 6 Aug 2009 07:55:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8D433A6853; Thu, 6 Aug 2009 07:55:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZ4FC-0000GK-T7 for namedroppers-data0@psg.com; Thu, 06 Aug 2009 14:47:02 +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 1MZ4F0-0000D6-Kb for namedroppers@ops.ietf.org; Thu, 06 Aug 2009 14:46:54 +0000 Received: from dotis-mac.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id D7734A94446; Thu, 6 Aug 2009 14:46:49 +0000 (UTC) Message-ID: <4A7AECD9.4060900@mail-abuse.org> Date: Thu, 06 Aug 2009 07:46:49 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Eric Osterweil CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: edns fallback (was Re: [dnsext] comments on draft-crocker-...) References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <64437.1249504261@nsa.vix.com> <7C8121AE-A721-428B-B5AB-DCDB2EE2A7DC@cs.ucla.edu> In-Reply-To: <7C8121AE-A721-428B-B5AB-DCDB2EE2A7DC@cs.ucla.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/5/09 8:08 PM, Eric Osterweil wrote: > On Aug 5, 2009, at 2:31 PM, Paul Vixie wrote: > >> i really should be writing a specific proposal rather than debating this; >> my apologies for my lack of self discipline as shown in two replies >> below. [] >> unless we intend that all dns protocol agents contain this level of >> complexity, and that all future large-UDP WAN applications (like EDNS) >> contain this level of complexity, and that both DNS and other large-UDP >> WAN applications continue to ratchet up this body count in the indefinite >> future, then we have to let the middle solve itself. > > The proposal here is to keep the intelligence at the ends. Much like TCP > adjusts its window size at the ends, these agents can adjust their > buffer sizes at the ends. [] >> given that each fallback can involve a timeout, the aggregate global >> application and end-user state load implied by having that many fallbacks >> is way too high. DNS is supposed to be quick and lightweight even when it >> fails. > > Well, some of these fallbacks result in immediate TC bits being set. > Intelligent guessing and persistent state (with periodic reassessment) > would allow for occasional timeouts, but not consistent timeouts. For > example, if 4096 times out, a quick 512 can tell the resolver if the > name server is online (not followed by a TCP connection). Then a more > intelligent UDP-search of the space (perhaps starting at 1400) can > proceed. Remember, getting TC bits is better than getting timeouts, so a > search of the space should keep that in mind. With hundreds of millions of botnet systems that might offer DNS, expansion of server state info must guard against overflow. During overflow of the acquired state, resulting traffic should be considered. DNSSEC already increases network amplifications, where the added fallback attempts will aggravates this problem by a factor of 2 to 4. SCTP causes less traffic and will better deals with congestion. >>> And it is, IMO, impossible to get the operators and middleboxes to >>> change. >> >> of course not. we're going to have to do DNS over XML over TCP/445 >> (HTTPS) >> when a user or their DNS protocol agent knows that or detects that it is >> behind a corrupting middlebox (or inside of a corrupting ISP). we already >> know this, and we know that no amount of EDNS or fragmentation fixage >> will avoid the need for it. HTTP or HTTPS will require a dramatic increase in needed resources and will inhibit simple conversions. Even so, TCP will not achieve comparable resilience. SCTP offers better protection without modifying DNS messages. Rather than expensive HTTP or HTTPS services, SCTP to UDP appliances could convert DNS messages for those that do not wish to otherwise alter their infrastructure. Those that don't want to adopt SCTP in some fashion, might need to forgo DNSSEC. > This sounds like throwing the baby out with the bath water. Yes, > sometimes messages will not fit over the path. No, this is not always > the case. UDP can, and should, continue to be the best option for DNS > queries and responses, and TCP (or TCP/445...) can be a fallback, but > there doesn't seem to be a good reason overreact. Would reflected attacks or DDoSing of TCP offer a reason? -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 Thu Aug 6 08:28: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 2A8A728C13F; Thu, 6 Aug 2009 08:28:24 -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 QbbcCJDLi7HA; Thu, 6 Aug 2009 08:28:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4071D28C11A; Thu, 6 Aug 2009 08:28:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZ4pY-0005Hk-Ay for namedroppers-data0@psg.com; Thu, 06 Aug 2009 15:24: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 1MZ4pA-0005F7-Mt for namedroppers@ops.ietf.org; Thu, 06 Aug 2009 15:24:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 50918ABD63 for ; Thu, 6 Aug 2009 15:24:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: edns fallback (was Re: [dnsext] comments on draft-crocker-...) In-Reply-To: Your message of "Thu, 06 Aug 2009 07:46:49 MST." <4A7AECD9.4060900@mail-abuse.org> References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <64437.1249504261@nsa.vix.com> <7C8121AE-A721-428B-B5AB-DCDB2EE2A7DC@cs.ucla.edu> <4A7AECD9.4060900@mail-abuse.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 06 Aug 2009 15:24:12 +0000 Message-ID: <18487.1249572252@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Thu, 06 Aug 2009 07:46:49 -0700 > From: Douglas Otis > > HTTP or HTTPS will require a dramatic increase in needed resources and will > inhibit simple conversions. Even so, TCP will not achieve comparable > resilience. SCTP offers better protection without modifying DNS messages. if folks want to do uncorrupted DNS inside corrupting ISPs, today's choice is use a VPN. perhaps that's a good enough choice but i don't think it supports opendns well and i know i get a little irritable when i have to tunnel my DNS over SSH. i think an XML profile for DNS, carried over HTTPS, would be useful and popular for stub-to-recursive traffic. provisioning at the server side is an economics question for the I.T. department (would they rather support VPN's?) and for opendns (how can they deliver their services to comcast's customers?) and so while i know HTTPS has a very high cost i still expect it to be a lower cost than existing alternatives for some folks. > Rather than expensive HTTP or HTTPS services, SCTP to UDP appliances could > convert DNS messages for those that do not wish to otherwise alter their > infrastructure. Those that don't want to adopt SCTP in some fashion, might > need to forgo DNSSEC. SCTP seems way more useful in recursive-to-authority flows. florian's note on nanog today (which i'll fwd here in its entirety) highlighted the short lifespan of the usual stub resolver context. someone else on nanog pointed out that NSCD (or presumably LWRESD) could hide the shortness of that life time, but i don't think we want to force people to run local forwarders. -- to unsubscribe send a message to namedroppers-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 Aug 6 08:29: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 93A4E3A6E05; Thu, 6 Aug 2009 08:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=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 OFxkxL88KjFu; Thu, 6 Aug 2009 08:29:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5EFC828C13F; Thu, 6 Aug 2009 08:28:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZ4rF-0005XJ-7W for namedroppers-data0@psg.com; Thu, 06 Aug 2009 15:26:21 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZ4r8-0005Wg-OL for namedroppers@ops.ietf.org; Thu, 06 Aug 2009 15:26:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 766AAABD5B for ; Thu, 6 Aug 2009 15:26:14 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] Re: DNS hardening, was Re: Dan Kaminsky In-Reply-To: Your message of "Thu\, 06 Aug 2009 07\:22\:14 GMT." <82eirp8l09.fsf@mid.bfk.de> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <82eirp8l09.fsf@mid.bfk.de> 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: Thu, 06 Aug 2009 15:26:14 +0000 Message-ID: <18671.1249572374@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: doug otis, paul vixie, and florian weimer splashed some SCTP over on nanog@ in the last 24 hours. here's the interesting part, as i measure such thing= s: > Subject: Re: DNS hardening, was Re: Dan Kaminsky > From: Florian Weimer > Date: Thu, 06 Aug 2009 07:22:14 +0000 >=20 > * Paul Vixie: >=20 > > there is no server side protocol control block required in SCTP. >=20 > SCTP needs per-peer state for congestion control and retransmission. >=20 > > someone sends you a "create association" request, you send back a > > "ok, here's your cookie" and you're done until/unless they come back > > and say "ok, here's my cookie, and here's my DNS request." so a > > spoofer doesn't get a cookie and a reflector doesn't burden a server > > any more than a ddos would do. >=20 > This is a red herring. The TCP state issues are deeper and haven't > got much to do with source address validation. The issues are mostly > caused by how the BSD sockets API is designed. SCTP uses the same API > model, and suffers from similar problems. >=20 > > because of the extra round trips nec'y to create an SCTP "association" > > (for which you can think, lightweight TCP-like session-like), it's > > going to be nec'y to leave associations in place between iterative > > caches and authority servers, and in place between stubs and iterative > > caches. >=20 > This doesn't seem possible with current SCTP because the heartbeat > rate quickly adds up and overloads servers further upstream. It also > does not work on UNIX-like system where processes are short-lived and > get a fresh stub resolver each time they are restarted. >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Aug 6 17:36: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 60CB93A6E66; Thu, 6 Aug 2009 17:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 u7a-Pf2LgEPQ; Thu, 6 Aug 2009 17:36:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 652393A6931; Thu, 6 Aug 2009 17:36:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZDJJ-000MlR-SP for namedroppers-data0@psg.com; Fri, 07 Aug 2009 00:27: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 1MZDJG-000Ml6-3p for namedroppers@ops.ietf.org; Fri, 07 Aug 2009 00:27:51 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 1B60EE609D; Fri, 7 Aug 2009 00:27: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 n770Rjha018211; Fri, 7 Aug 2009 10:27:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908070027.n770Rjha018211@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <64437.1249504261@nsa.vix.com> <7C8121AE-A721-428B-B5AB-DCDB2EE2A7DC@cs.ucla.edu> <4A7AECD9.4060900@mail-abuse.org> <18487.1249572252@nsa.vix.com> Subject: Re: edns fallback (was Re: [dnsext] comments on draft-crocker-...) In-reply-to: Your message of "Thu, 06 Aug 2009 15:24:12 GMT." <18487.1249572252@nsa.vix.com> Date: Fri, 07 Aug 2009 10:27:45 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Years ago (well over a decade) I created a local DNS proxy listening on 127.0.0.1 that just tracked response times from the nameservers listed in resolv.conf and forwarded the queries based on that using its own id space with retries. The stub resolver used connected sockets to talk to it and fell back to the nameservers listed in resolv.conf if it was not available. The idea was to handle dead nameservers in resolv.conf more efficently. Such a proxy could keep the SCTP state for all the stub resolvers in a machine. It's just a little more shared state. The proxy would need to manage EDNS buffer sizes these days in addition to the id space. The proxy could even sign requests on behalf of the stub resolvers allowing DH to be used efficiently. The proxy would not be used if the stub resolver re-set the nameservers. This also helps with long running applications as only the proxy needs to track nameserver changes in resolv.conf. 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 hothousing@iparegistr.com Thu Aug 6 19:30: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 360EE3A6A3F; Thu, 6 Aug 2009 19:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.859 X-Spam-Level: X-Spam-Status: No, score=-23.859 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_EQ_DYNAMIC=1.144, 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_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 8izHwKgjvNgB; Thu, 6 Aug 2009 19:30:07 -0700 (PDT) Received: from port-92-206-60-4.dynamic.qsc.de (port-92-206-60-4.dynamic.qsc.de [92.206.60.4]) by core3.amsl.com (Postfix) with ESMTP id BA9D83A6E6E; Thu, 6 Aug 2009 19:28:47 -0700 (PDT) Received: from 92.206.60.4 by glade.tutby.com; Fri, 7 Aug 2009 04:28:47 +0100 Message-ID: <000d01ca1706$cb1fec30$6400a8c0@hothousing> From: Lynette Jacobson To: Subject: If you are struggling and looking for effective ways to drop weight fast Try Acai Berry Date: Fri, 7 Aug 2009 04:28:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1706.CB1FEC30" 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_01CA1706.CB1FEC30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lose Weight Fast with Acai Berry Too much to know, all I know is that i love this, and I wish I was still ge= tting it free   Inviting you to click =A0 =A0 Thank You!=20 best regards Lynette=20 Jacobson ------=_NextPart_000_0007_01CA1706.CB1FEC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Lose Weight Fast with Acai Berry
Too much to know, all I know is that i love this, and I wis= h I was still getting it free
 
Inviting you to click<= /FONT>
=A0
=A0
Thank You!
best regards Lynette=20 Jacobson
------=_NextPart_000_0007_01CA1706.CB1FEC30-- From mcanales@afip.gov.ar Fri Aug 7 06:20:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C673A6910 for ; Fri, 7 Aug 2009 06:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.966 X-Spam-Level: X-Spam-Status: No, score=-24.966 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgN6vExifVvh for ; Fri, 7 Aug 2009 06:20:00 -0700 (PDT) Received: from vipnet245-80.mobile.CARNet.hr (vipnet245-80.mobile.carnet.hr [193.198.80.245]) by core3.amsl.com (Postfix) with SMTP id 67A523A6A66 for ; Fri, 7 Aug 2009 06:19:58 -0700 (PDT) To: From: Subject: Official Site Pfizer. Subscribe MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20090807131959.67A523A6A66@core3.amsl.com> Date: Fri, 7 Aug 2009 06:19:58 -0700 (PDT)
Click here to view as a web page.

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

Copyright © 2009 bcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890klmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890 Inc. All rights reserved.
From roentgento08@iqoutfitters.com Fri Aug 7 07: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 A375F3A6F10; Fri, 7 Aug 2009 07:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.581 X-Spam-Level: X-Spam-Status: No, score=-26.581 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, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_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_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 awf3qFg7gdeq; Fri, 7 Aug 2009 07:08:16 -0700 (PDT) Received: from 201-66-207-196.pltce701.dsl.brasiltelecom.net.br (201-66-207-196.pltce701.dsl.brasiltelecom.net.br [201.66.207.196]) by core3.amsl.com (Postfix) with ESMTP id 649583A6D04; Fri, 7 Aug 2009 07:08:15 -0700 (PDT) Received: from 201.66.207.196 by iqoutfitters.com; Fri, 7 Aug 2009 11:07:34 -0300 Date: Fri, 7 Aug 2009 11:07:34 -0300 Message-Id: <2AQ4BIF700811.W4RATULHAV729877@201.66.207.196.iqoutfitters.com> From: action@ietf.org To: action@ietf.org Subject: 5$ And You Got that sexy body back Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
I know that you arent here, when you get back check this out
 
Your Acai Berry free trial is waiting for you.
best regards Golda Haas
From websbm7@ispcymru.com Fri Aug 7 08:56: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 25F7D3A6F16; Fri, 7 Aug 2009 08:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.297 X-Spam-Level: X-Spam-Status: No, score=-25.297 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, 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_XBL=3.033, 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 PJBuT40-RLAj; Fri, 7 Aug 2009 08:56:06 -0700 (PDT) Received: from 79-175-87-21.adsl-a-1.sezampro.yu (79-175-65-62.adsl-a-1.sezampro.yu [79.175.65.62]) by core3.amsl.com (Postfix) with ESMTP id 1BEF33A6A89; Fri, 7 Aug 2009 08:56:04 -0700 (PDT) Received: from 79.175.65.62 by mx.murphx.net; Fri, 7 Aug 2009 17:54:59 +0100 Message-ID: <000d01ca1777$6b097750$6400a8c0@websbm7> From: Belva Graham To: Subject: Trials While Supplies Last Only Date: Fri, 7 Aug 2009 17:54:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1777.6B097750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1777.6B097750 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey I have been meaning to tell you about this, just go for it   Let Accai Berry imporve your health.=20 =20 Staying healthy has never been easier =20 =20 Visit everybody best regards Belva=20 Graham ------=_NextPart_000_0007_01CA1777.6B097750 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hey I have been meaning to tell you about t= his, just go for it
 
Let Accai Berry imporve your health. =
Staying healthy has never been easier=

=20 Visit everybody

best regards Belva=20 Graham
------=_NextPart_000_0007_01CA1777.6B097750-- From napa@accommodations-net.com Sat Aug 8 07:31: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 E09F23A69CC for ; Sat, 8 Aug 2009 07:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 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_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 SrrzcwBL4c1e for ; Sat, 8 Aug 2009 07:31:42 -0700 (PDT) Received: from 93-47-37-144.ip111.fastwebnet.it (93-47-37-144.ip111.fastwebnet.it [93.47.37.144]) by core3.amsl.com (Postfix) with SMTP id 236293A6BD3 for ; Sat, 8 Aug 2009 07:31:40 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 0665-0, 29/12/2006), Outbound message X-Antivirus-Status: Clean Message-Id: <20090808143141.236293A6BD3@core3.amsl.com> Date: Sat, 8 Aug 2009 07:31:40 -0700 (PDT) Show picture and go to site now! From owner-namedroppers@ops.ietf.org Sat Aug 8 08:54: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 6D1C828C227; Sat, 8 Aug 2009 08:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, 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 RIWm6j+UhyjQ; Sat, 8 Aug 2009 08:54:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C5573A6C76; Sat, 8 Aug 2009 08:53:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZo87-000P3n-4T for namedroppers-data0@psg.com; Sat, 08 Aug 2009 15:46: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 1MZo80-000P2q-8q for namedroppers@ops.ietf.org; Sat, 08 Aug 2009 15:46:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 04925AC090 for ; Sat, 8 Aug 2009 15:46:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] SCTP trials on NANOG, 3 of 3 (Re: DNS hardening) In-Reply-To: Your message of "Fri, 07 Aug 2009 22:41:05 -0400." <20090807224105.62dfb659@cs.columbia.edu> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <20090807224105.62dfb659@cs.columbia.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 08 Aug 2009 15:46:40 +0000 Message-ID: <71652.1249746400@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i'm fwd'ing these here to be sure that protocol people and not just ops people have a chance to see and hear what's being said and asked re: SCTP. > Date: Fri, 7 Aug 2009 22:41:05 -0400 > From: "Steven M. Bellovin" > To: Paul Vixie > Cc: nanog@merit.edu > Subject: Re: DNS hardening, was Re: Dan Kaminsky > Organization: Columbia University > X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd) > > On Thu, 06 Aug 2009 06:51:24 +0000 > Paul Vixie wrote: > > > Christopher Morrow writes: > > > > > how does SCTP ensure against spoofed or reflected attacks? > > > > there is no server side protocol control block required in SCTP. > > someone sends you a "create association" request, you send back a > > "ok, here's your cookie" and you're done until/unless they come back > > and say "ok, here's my cookie, and here's my DNS request." so a > > spoofer doesn't get a cookie and a reflector doesn't burden a server > > any more than a ddos would do. > > > > because of the extra round trips nec'y to create an SCTP > > "association" (for which you can think, lightweight TCP-like > > session-like), it's going to be nec'y to leave associations in place > > between iterative caches and authority servers, and in place between > > stubs and iterative caches. however, because the state is mostly on > > the client side, a server with associations open to millions of > > clients at the same time is actually no big deal. > > Am I missing something? The SCTP cookie guards against the equivalent > of SYN-flooding attacks. The problem with SCTP is normal operations. > A UDP DNS query today takes a message and a reply, with no (kernel) > state created on the server end. For SCTP, it takes two round trips to > set up the connection -- which includes kernel state -- followed by the > query and reply, and tear-down. I confess that I don't remember the > SCTP state diagram; in TCP, the side that closes first can end up in > FIN-WAIT2 state, which is stable. That is, suppose the server -- the > loaded party -- tries to shed kernel state by closing its DNS socket > first. If the client goes away or is otherwise uncooperative, the > server will then end up in FIN-WAIT2, in which case kernel memory is > consumed "forever" by conforming server TCPs. Does SCTP have that > problem? > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb -- to unsubscribe send a message to namedroppers-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 Aug 8 08:54: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 9724C28C20A; Sat, 8 Aug 2009 08:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 CdvpgiXK3Vps; Sat, 8 Aug 2009 08:54:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9A9E3A6965; Sat, 8 Aug 2009 08:54:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZo6u-000Or1-SM for namedroppers-data0@psg.com; Sat, 08 Aug 2009 15:45: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 1MZo6p-000OoQ-G8 for namedroppers@ops.ietf.org; Sat, 08 Aug 2009 15:45:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C4715AC12A for ; Sat, 8 Aug 2009 15:45:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] SCTP trials over on NANOG, 2 of 3 (Re: DNS hardening) In-Reply-To: Your message of "Thu\, 06 Aug 2009 07\:07\:32 GMT." <82my6d8lor.fsf@mid.bfk.de> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <82my6d8lor.fsf@mid.bfk.de> 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, 08 Aug 2009 15:45:26 +0000 Message-ID: <71625.1249746326@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: there's one more after this, from steve bellovin, will be fwd'd in a moment. > From: Florian Weimer > Newsgroups: gmane.org.operators.nanog > Subject: Re: DNS hardening, was Re: Dan Kaminsky > Date: Thu, 06 Aug 2009 07:07:32 +0000 > Cc: nanog@nanog.org > To: Douglas Otis > Archived-At: >=20 > * Douglas Otis: >=20 > > Establishing SCTP as a preferred DNS transport offers a safe harbor > > for major ISPs. >=20 > SCTP is not a suitable transport for DNS, for several reasons: >=20 > Existing SCTP stacks are not particularly robust (far less than TCP). > The number of bugs still found in them is rather large. >=20 > Only very few stacks (if any) implement operation without kernel > buffers. The remaining ones are subject to the same state exhaustion > attacks as TCP stacks are. >=20 > At least some parts of SCTP and the SCTP API were designed for a > cooperative environment. >=20 > The SCTP API specification is very ambiguous, which is quite strange > for such a young protocol. For instance, it is not clear if a single > socket is used to communicate with multiple peers, head-of-line > blocking can occur. >=20 > The protocol has insufficient signalling to ensure that > implementations turn off features which are harmful on a global scale. > For instance, persistant authoritative <-> resolver connections only > work if you switch off heartbeat, but the protocol cannot do this, and > it is likely that many peers won't do it. >=20 > SCTP proposers generally counter these observations by referring to > extensions and protocols which are not yet standardized, not > implemented, or both, constantly moving the goalposts. >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 >=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: From turncoatsy8@italyeurope.com Sat Aug 8 10: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 665303A6A5A; Sat, 8 Aug 2009 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.456 X-Spam-Level: X-Spam-Status: No, score=-15.456 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT2=0.001, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MALE_ENHANCE=2.596, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, 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 8MfOlWZjJfF4; Sat, 8 Aug 2009 10:46:59 -0700 (PDT) Received: from 201-75-111-66-ma.cpe.vivax.com.br (201-75-111-66-ma.cpe.vivax.com.br [201.75.111.66]) by core3.amsl.com (Postfix) with ESMTP id 32F2B3A6AD3; Sat, 8 Aug 2009 10:46:56 -0700 (PDT) Received: from 201.75.111.66 by mail.italyeurope.com; Sat, 8 Aug 2009 14:44:38 -0300 Content-type: text/html; charset="UTF-8" MIME-Version: 1.0 Message-ID: Date: Sat, 8 Aug 2009 14:44:38 -0300 From: "Natasha Dunbar" To: aaa-archive@lists.ietf.org Subject: FDA approved enhancment formula Buy the BEST penis enlargement pills online for natural male enhancement products click here http://www.unerveliattro.net/?bwqytbjaw Thank You Natasha Dunbar From dipsomaniacfh4@irenuffici.com Sat Aug 8 11:21: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 37AE13A6BE7; Sat, 8 Aug 2009 11:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, 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, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, 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 7-MXxVxCP3Oj; Sat, 8 Aug 2009 11:21:12 -0700 (PDT) Received: from 66-190-215-178.dhcp.slid.la.charter.com (66-190-215-178.dhcp.slid.la.charter.com [66.190.215.178]) by core3.amsl.com (Postfix) with ESMTP id 6475C3A6A5F; Sat, 8 Aug 2009 11:21:12 -0700 (PDT) Received: from 66.190.215.178 by mailhost.irenuffici.com; Sat, 8 Aug 2009 11:21:12 -0800 Content-type: text/html; charset="iso-8859-2" MIME-Version: 1.0 Message-ID: Date: Sat, 8 Aug 2009 11:21:12 -0800 From: "Golden Echols" To: emu-request@ietf.org Subject: 10 tips to get her in your bed Always wanted to be the bigger man, now you can try our Penis pills http://www.ontresiblez.net/?rcupntjowyrdn Thank You Golden Echols From owner-namedroppers@ops.ietf.org Sat Aug 8 11:24: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 43EA428C0E6; Sat, 8 Aug 2009 11:24:39 -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 cwLv7YevW+EW; Sat, 8 Aug 2009 11:24:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84F393A6A5F; Sat, 8 Aug 2009 11:24:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZqVb-000Jsd-OY for namedroppers-data0@psg.com; Sat, 08 Aug 2009 18:19:11 +0000 Received: from [209.85.211.201] (helo=mail-yw0-f201.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZqVY-000JsI-Cc for namedroppers@ops.ietf.org; Sat, 08 Aug 2009 18:19:09 +0000 Received: by ywh39 with SMTP id 39so467891ywh.32 for ; Sat, 08 Aug 2009 11:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=aKv5czvxqIFPXNAorx80aJJ3CLXoWpeCHLPVKvuZwNM=; b=bjL343yEhsLuX2fFhmirT7oAbZD+hPDeRdhpRlGXWdiCH+/JW+Ne8iSKRWZJ6UEPaA xMBsWCwOxaVaOvd6EVTjdgHzvQgyUmSV/rAqXdYZAZlzB25CGNqStVKM/S3Ntq+xSY2z /bk8odWfuSsoOnRjMK2egDP1DT+uAhnrfVc5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=L3FPZW0B1+yuJdm/o+2yyVaWczMaKdOF8JjP3xelMofDpBsYyGBi+1MAlETKaELb72 lKI5kVJMPfXqgZlsQlaMlVl5FFGeHFh46fupBSSUFnnIbRwnZVqFKOiWhnpDd/NmAaVz aeZ1ZuvlXpf6fwvBu9Y9Hu6/PUT+4gOoMpWo0= Received: by 10.90.67.20 with SMTP id p20mr2096121aga.63.1249755547491; Sat, 08 Aug 2009 11:19:07 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 38sm6453129agd.9.2009.08.08.11.19.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Aug 2009 11:19:06 -0700 (PDT) Message-ID: <4A7DC199.9040700@gmail.com> Date: Sat, 08 Aug 2009 14:19:05 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] Signing the root with SHA-1 by Sep 1st Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The original subject "Signing the root with SHA-1 or SHA-2" seems to have diverged, but after re-reading the thread, it seems there is fairly strong consensus to run with SHA-1, exercising algorithm rollover later. I'm proposing Sep 1st. My rationale is that educational institutions will be started, or ready to start shortly thereafter. They are already dealing with new students, and help desks will be able to give strong feedback on any problems. Likewise, many/most businesses will have their staff back from holidays. Finally, it's a Tuesday. I've always found it best to roll out changes on Tuesday, as it gives plenty of customer feedback time during the week. Mondays are often consumed with catching up on any operational problems over the weekend. Tuesday is better. 02:00 UTC is my favorite, although anytime after 00:00 UTC usually works OK. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From MAILER-DAEMON Sat Aug 8 13: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 364533A6E65 for ; Sat, 8 Aug 2009 13:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.6 X-Spam-Level: X-Spam-Status: No, score=-66.6 tagged_above=-999 required=5 tests=[AWL=-35.580, BAYES_50=0.001, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, IP_NOT_FRIENDLY=0.334, MANGLED_OFF=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, SARE_UNI=0.591, UNPARSEABLE_RELAY=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpEm8yknJ70h for ; Sat, 8 Aug 2009 13:13:09 -0700 (PDT) Received: from ee01.elistx.com (ee01.elistx.com [67.154.239.222]) by core3.amsl.com (Postfix) with ESMTP id 429E33A6823 for ; Sat, 8 Aug 2009 13:13:09 -0700 (PDT) Received: from PROCESS-DAEMON.elistx.com by elistx.com (PMDF V6.3-2x2 #31546) id <0KO200301QQWK6@elistx.com> for dnsext-archive@lists.ietf.org; Sat, 08 Aug 2009 16:11:21 -0400 (EDT) Received: from elistx.com (PMDF V6.3-2x2 #31546) id <0KO200209QGEUK@elistx.com>; Sat, 08 Aug 2009 16:11:20 -0400 (EDT) Date: Sat, 08 Aug 2009 16:11:20 -0400 (EDT) From: PMDF Internet Messaging Subject: Delivery Notification: Delivery has failed To: dnsext-archive@lists.ietf.org Message-id: <0KO20020ZQQWUK@elistx.com> MIME-version: 1.0 Content-type: multipart/report; boundary="Boundary_(ID_Pu66vfv/n51se5K381Os+w)"; report-type=delivery-status --Boundary_(ID_Pu66vfv/n51se5K381Os+w) Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT This report relates to a message you sent with the following header fields: Message-id: <0KO100L0TR4YYK@elistx.com> Date: Sat, 08 Aug 2009 03:22:14 -0400 (EDT) From: VIAGRA =?UNKNOWN?B?rrrr?= Official Site To: dnsext@ogud.com Subject: Dear dnsext@ogud.com 81% 0FF on Pfizer ! Your message cannot be delivered to the following recipients: Recipient address: dnsext@ogud.com Reason: SMTP client-server loop detected Remote system: dns;smtp.elistx.com (TCP|10.0.0.21|60398|67.154.239.222|25) (ee01.elistx.com -- Server ESMTP [PMDF V6.3-2x2#31546]) --Boundary_(ID_Pu66vfv/n51se5K381Os+w) Content-type: message/delivery-status Original-envelope-id: 0KO100M02R530S@elistx.com Reporting-MTA: dns;elistx.com (TCP-OGUD) Action: failed Status: 5.4.6 (SMTP client-server loop detected) Original-recipient: rfc822;dnsext@ogud.com Final-recipient: rfc822;dnsext@ogud.com Remote-MTA: dns;smtp.elistx.com (TCP|10.0.0.21|60398|67.154.239.222|25) (ee01.elistx.com -- Server ESMTP [PMDF V6.3-2x2#31546]) --Boundary_(ID_Pu66vfv/n51se5K381Os+w) Content-type: message/rfc822 Return-path: Received: from TCP-OGUD.elistx.com by elistx.com (PMDF V6.3-2x2 #31546) id <0KO200209QGEUK@elistx.com> (original mail from dnsext-archive@lists.ietf.org); Sat, 08 Aug 2009 16:11:20 -0400 (EDT) Received: from CONVERSION-DAEMON.elistx.com by elistx.com (PMDF V6.3-2x2 #31546) id <0KO100M01R530S@elistx.com> for dnsext@ogud.com; Sat, 08 Aug 2009 03:22:22 -0400 (EDT) Received: from chip (98-162-178-94.pool.ukrtel.net [94.178.162.98]) by elistx.com (PMDF V6.3-2x2 #31546) with SMTP id <0KO100L0RR4VYK@elistx.com> for dnsext@elistx.ogud.com (ORCPT dnsext@ogud.com); Sat, 08 Aug 2009 03:22:14 -0400 (EDT) Date: Sat, 08 Aug 2009 03:22:14 -0400 (EDT) Date-warning: Date header was inserted by elistx.com From: VIAGRA =?UNKNOWN?B?rrrr?= Official Site Subject: Dear dnsext@ogud.com 81% 0FF on Pfizer ! To: dnsext@elistx.ogud.com Message-id: <0KO100L0TR4YYK@elistx.com> MIME-version: 1.0 Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 8BIT News
Click here to view as a web page.

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

Copyright © 2009 tdrax Inc. All rights reserved.
--Boundary_(ID_Pu66vfv/n51se5K381Os+w)-- From owner-namedroppers@ops.ietf.org Sat Aug 8 13:51: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 1F3973A6BAB; Sat, 8 Aug 2009 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.988, 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 7QVM7aZGqweK; Sat, 8 Aug 2009 13:51:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0B843A6BDD; Sat, 8 Aug 2009 13:51:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZslb-000F3R-2i for namedroppers-data0@psg.com; Sat, 08 Aug 2009 20:43:51 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZslW-000F2z-8v for namedroppers@ops.ietf.org; Sat, 08 Aug 2009 20:43:48 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=thavLs/7/qHb4S/IPihsyvCVe3FY68I6mN1W2jT40gwgBR/9duBsizovTopC5hei; 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.100.244] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MZslV-0000uW-2e; Sat, 08 Aug 2009 16:43:45 -0400 Message-ID: <4A7DF05A.CCFEF1C1@ix.netcom.com> Date: Sat, 08 Aug 2009 15:38:34 -0600 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: William Allen Simpson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 by Sep 1st References: <4A7DC199.9040700@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b140a6b47a6194c2a77a39ddf72cef0f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.100.244 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill and all, This is take I have as well. William Allen Simpson wrote: > The original subject "Signing the root with SHA-1 or SHA-2" seems to have > diverged, but after re-reading the thread, it seems there is fairly > strong consensus to run with SHA-1, exercising algorithm rollover later. > > I'm proposing Sep 1st. > > My rationale is that educational institutions will be started, or ready > to start shortly thereafter. They are already dealing with new students, > and help desks will be able to give strong feedback on any problems. > > Likewise, many/most businesses will have their staff back from holidays. > > Finally, it's a Tuesday. I've always found it best to roll out changes > on Tuesday, as it gives plenty of customer feedback time during the week. > Mondays are often consumed with catching up on any operational problems > over the weekend. Tuesday is better. 02:00 UTC is my favorite, although > anytime after 00:00 UTC usually works OK. > > -- > to 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 delawareansnn72@italporta.com Sat Aug 8 16:03: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 5FBC33A6914; Sat, 8 Aug 2009 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, SARE_ADULT2=1.42, SARE_SEXDRIVE=1.66, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 fypPdGSmIODd; Sat, 8 Aug 2009 16:03:07 -0700 (PDT) Received: from h198.9.90.75.dynamic.ip.windstream.net (h198.9.90.75.dynamic.ip.windstream.net [75.90.9.198]) by core3.amsl.com (Postfix) with ESMTP id 804B13A697E; Sat, 8 Aug 2009 16:03:07 -0700 (PDT) Received: from 75.90.9.198 by italporta.com; Sat, 8 Aug 2009 19:03:04 -0500 Content-type: text/html; charset="us-ascii" MIME-Version: 1.0 Message-ID: <655E30.3B7OXP.44121716189173640KU1QH12@3514.75.90.9.198> Date: Sat, 8 Aug 2009 19:03:04 -0500 From: "Jame Hairston" To: eap-archive@ietf.org Subject: Enhance, enlarge and thicken your manhood Our penis pills will increase the length and girth of your penis – and boost up your sexual drive and energy at the same time! http://www.cryziat.net/?kpdmwyrtdl Best Regards Jame Hairston From skimpyrers@iproinco.com Sat Aug 8 16: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 261113A697E; Sat, 8 Aug 2009 16:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, 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, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 od0Yfiw9z6cW; Sat, 8 Aug 2009 16:03:29 -0700 (PDT) Received: from pool-71-162-103-2.bstnma.east.verizon.net (pool-71-162-103-2.bstnma.east.verizon.net [71.162.103.2]) by core3.amsl.com (Postfix) with ESMTP id 0DB953A6914; Sat, 8 Aug 2009 16:03:24 -0700 (PDT) Received: from 71.162.103.2 by mx01.dns-servicios.com; Sat, 8 Aug 2009 19:03:18 -0500 Content-type: text/html; charset="UTF-8" MIME-Version: 1.0 Message-ID: Date: Sat, 8 Aug 2009 19:03:18 -0500 From: "Paulette Strong" To: dnsext-archive@lists.ietf.org Subject: 10 tips to get her in your bed Penis Pills are the easiest methods to enlarge your penis size without having to go through complicate surgery http://www.cryziat.net/?kpdmwyrtdl Thanks Paulette Strong From owner-namedroppers@ops.ietf.org Sun Aug 9 13:13: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 73E313A6D06; Sun, 9 Aug 2009 13:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 Wnrbp6TsTqCt; Sun, 9 Aug 2009 13:13:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76A1B3A693E; Sun, 9 Aug 2009 13:13:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaEe2-0005vt-H2 for namedroppers-data0@psg.com; Sun, 09 Aug 2009 20:05:30 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaEdy-0005v9-IA for namedroppers@ops.ietf.org; Sun, 09 Aug 2009 20:05:28 +0000 Received: from [193.110.157.130] (unknown [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id C638E5E60C; Sun, 9 Aug 2009 16:05:24 -0400 (EDT) Date: Sun, 9 Aug 2009 16:05:23 -0400 (EDT) From: Paul Wouters To: Mark Andrews cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: edns fallback (was Re: [dnsext] comments on draft-crocker-...) In-Reply-To: <200908070027.n770Rjha018211@drugs.dv.isc.org> Message-ID: References: <99253.1249407211@nsa.vix.com> <19065.13519.721.206474@guava.gson.org> <71569EC0-F2A2-4AA2-A582-28CD0DAAD473@cs.ucla.edu> <50179.1249484270@nsa.vix.com> <51FE5848-DBFC-4D65-AC41-9AB98D6D77F8@icsi.berkeley.edu> <64437.1249504261@nsa.vix.com> <7C8121AE-A721-428B-B5AB-DCDB2EE2A7DC@cs.ucla.edu> <4A7AECD9.4060900@mail-abuse.org> <18487.1249572252@nsa.vix.com> <200908070027.n770Rjha018211@drugs.dv.isc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, 7 Aug 2009, Mark Andrews wrote: > Years ago (well over a decade) I created a local DNS proxy listening > on 127.0.0.1 that just tracked response times from the nameservers > listed in resolv.conf and forwarded the queries based on that using > The proxy would need to manage EDNS buffer sizes these days in > addition to the id space. The proxy could even sign requests on > behalf of the stub resolvers allowing DH to be used efficiently. > This also helps with long running applications as only the proxy > needs to track nameserver changes in resolv.conf. Uhm, are you going to add validation to your "stub" next? Paul -- to unsubscribe send a message to namedroppers-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 Aug 9 14:44: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 E58343A680B; Sun, 9 Aug 2009 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UVjA5gWX0pv; Sun, 9 Aug 2009 14:44:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47CC73A681C; Sun, 9 Aug 2009 14:43:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaG60-000H6u-4Q for namedroppers-data0@psg.com; Sun, 09 Aug 2009 21:38:28 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaG5v-000H5z-L1 for namedroppers@ops.ietf.org; Sun, 09 Aug 2009 21:38:26 +0000 Received: by pzk38 with SMTP id 38so2906556pzk.33 for ; Sun, 09 Aug 2009 14:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SQUuis2pgw8HqjhZyfwbEMuG7uUEUlW7G950xy9NaeY=; b=oI0+LEHsbjBprLHBvLJmU8Dj+6MAW/fRAHFgCO7i0ZNNGq4UtwQjQ+ctGQzsJAGWxs RIGVQWaeTbg8kiqIYGfCrNo987Q7c77Yx69Bs7w6xzKX3ojj0To1jKyxxVMjPkXsLRLj Y8KGtTrqKb8eXKITkI60mTc1N+M8zblCA7HzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QR92GNHU5NN9D9akRJplyVS8Poe3BZ8juOEGtbWyKBUQ46UmbH467OR06J6gEIfAZO TX0LGXP5uvQy+6lLImaEKqmi+botT7dawySQVFjHmuxBmDgTDmwMTwyIEvcVVbA7KgH0 ErV5hixt09LKukWKIejaiIvMeqaaFiADKNdHs= Received: by 10.115.46.14 with SMTP id y14mr5402224waj.165.1249853902375; Sun, 09 Aug 2009 14:38:22 -0700 (PDT) Received: from dotis-mac.local (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) by mx.google.com with ESMTPS id n30sm6150808wag.6.2009.08.09.14.38.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Aug 2009 14:38:21 -0700 (PDT) Message-ID: <4A7F41CB.10202@gmail.com> Date: Sun, 09 Aug 2009 14:38:19 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] SCTP trials on NANOG, 3 of 3 (Re: DNS hardening) References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <20090807224105.62dfb659@cs.columbia.edu> <71652.1249746400@nsa.vix.com> In-Reply-To: <71652.1249746400@nsa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/8/09 8:46 AM, Paul Vixie wrote: >> Am I missing something? The SCTP cookie guards against the equivalent >> of SYN-flooding attacks. The problem with SCTP is normal operations. >> A UDP DNS query today takes a message and a reply, with no (kernel) >> state created on the server end. For SCTP, it takes two round trips to >> set up the connection -- which includes kernel state -- followed by the >> query and reply, and tear-down. There is info within initial exchanges (beyond that exchanged with TCP) that allows SCTP to be robust. TCP transitions from Listen to SYN_RCVD send SYN ACK, ACK recv, Established. From SYN_RVCD, it might also send FIN, transition with recv ACK, and stick on FIN-WAIT2 for recv FIN. >> I confess that I don't remember the >> SCTP state diagram; in TCP, the side that closes first can end up in >> FIN-WAIT2 state, which is stable. That is, suppose the server -- the >> loaded party -- tries to shed kernel state by closing its DNS socket >> first. If the client goes away or is otherwise uncooperative, the >> server will then end up in FIN-WAIT2, in which case kernel memory is >> consumed "forever" by conforming server TCPs. Does SCTP have that >> problem? SCTP state diagram: http://www.csm.ornl.gov/~dunigan/netperf/SCTPstate.png TCP state diagram: http://www.csm.ornl.gov/~dunigan/netperf/TCPstate.gif SCTP goes from Closed, recv Cookie ECHO, Send Cookie ACK to Established. Shutdown sent with Timer. SCTP can transitions from any to state to Closed with Abort for any reason. Minor state adjustments are handled by the Out-of-the-Blue (OOTB) routines. RFC4460 provides SCTP errata and issue review. As part of a long term strategy, the concept of allowing (somewhat) persistent SCTP DNS associations versus single transactions per TCP connection is to retain the low latency obtained with UDP, in that the next query might be bundled in a separate stream or issued within some period of time later. Deciding when an association is to be shutdown should weigh the overhead of retaining associations and heartbeats, against establishing new associations. SCTP DNS handled in this fashion should help eliminate spoofing between ISP recursive resolvers, and provide reliable transactions with authoritative name servers without extra ordinary provisioning. SCTP HTTP should also help make web sites more impervious to DDoS attacks and various types of exploits. Using SCTP with DNS should also ensure teething issues are quickly overcome. Flood protections often put in place for TCP may block without verifying the source's involvement. This means TCP can be globally flooded, or have sources selectively inhibited due to address spoofing. In addition, as a result of DNSSEC response sizes, UDP responses may also imperil the networks reaching the addresses being spoofed. SCTP eliminates these threats while demanding the least amount of additional resources. SCTP multi-home feature work best within an IPv6 environment, however SCTP's use with DNS should also help ensure it works well with IPv4 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 Sun Aug 9 17:34: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 C6F413A6B1B; Sun, 9 Aug 2009 17:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP5DbdqaKp0L; Sun, 9 Aug 2009 17:34:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F33E43A6A99; Sun, 9 Aug 2009 17:34:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaIjv-000D0G-HO for namedroppers-data0@psg.com; Mon, 10 Aug 2009 00:27: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 1MaIjs-000Czr-14 for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 00:27:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A4034AC3B7; Mon, 10 Aug 2009 00:27:47 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Doug Otis cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] SCTP trials on NANOG, 3 of 3 (Re: DNS hardening) In-Reply-To: Your message of "Sun, 09 Aug 2009 14:38:19 MST." <4A7F41CB.10202@gmail.com> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <20090807224105.62dfb659@cs.columbia.edu> <71652.1249746400@nsa.vix.com> <4A7F41CB.10202@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 10 Aug 2009 00:27:47 +0000 Message-ID: <69498.1249864067@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Sun, 09 Aug 2009 14:38:19 -0700 > From: Doug Otis > > On 8/8/09 8:46 AM, Paul Vixie wrote: > > >> Am I missing something? The SCTP cookie guards against the equivalent actually steve bellovin wrote that not me. -- to unsubscribe send a message to namedroppers-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 Aug 10 09:09:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8392C3A68A2; Mon, 10 Aug 2009 09:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.489 X-Spam-Level: X-Spam-Status: No, score=-4.489 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 BdLhDbbgXQGv; Mon, 10 Aug 2009 09:09:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2EDA3A6B09; Mon, 10 Aug 2009 09:09:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaXLx-0001ok-5i for namedroppers-data0@psg.com; Mon, 10 Aug 2009 16:04:05 +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 1MaXLt-0001o1-EO for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 16:04:02 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 02AEAA9443A; Mon, 10 Aug 2009 16:04:00 +0000 (UTC) Message-ID: <4A8044EF.2020907@mail-abuse.org> Date: Mon, 10 Aug 2009 09:03:59 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Paul Vixie CC: Doug Otis , namedroppers@ops.ietf.org Subject: Re: [dnsext] SCTP trials on NANOG, 3 of 3 (Re: DNS hardening) References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <20090807224105.62dfb659@cs.columbia.edu> <71652.1249746400@nsa.vix.com> <4A7F41CB.10202@gmail.com> <69498.1249864067@nsa.vix.com> In-Reply-To: <69498.1249864067@nsa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/9/09 5:27 PM, Paul Vixie wrote: >> Date: Sun, 09 Aug 2009 14:38:19 -0700 >> From: Doug Otis >> >> On 8/8/09 8:46 AM, Paul Vixie wrote: >> >>>> Am I missing something? The SCTP cookie guards against the equivalent > > actually steve bellovin wrote that not me. My apologies. I should have started by saying Steve and not delete the line- From: "Steven M. Bellovin" -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 Aug 10 09:09:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4003A68A2; Mon, 10 Aug 2009 09:09:55 -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 FafzNvA3t+E6; Mon, 10 Aug 2009 09:09:54 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B5B263A6E8A; Mon, 10 Aug 2009 09:09:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaXND-0002GS-JB for namedroppers-data0@psg.com; Mon, 10 Aug 2009 16:05:23 +0000 Received: from [209.85.198.237] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaXN9-0002FK-B8 for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 16:05:21 +0000 Received: by rv-out-0506.google.com with SMTP id f9so869135rvb.41 for ; Mon, 10 Aug 2009 09:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=jrtaCp+IWKrr5J8NsJEJ5+ckXptcfLaekHLzp7An4ls=; b=FX7VU6g8QVI3ETMlg+cD3b5ttn0l1u7sTzCM/eXVovKo5MAxryJCQ+YiX9OLbIcYvZ FxtS0EEc/zQcty39HVRHO27dc7qCxfLBA2OEKfGXSJHsCyzITsw1kzOEfhL4G2bY3MIy 3aTxmPXuHEYQ05VEqtU7TDUdb+A/3vWAF56qg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=lxm0ObnspLaDnYLL+uxyxTtFmBW3POarm7VeLlu0Yy2r/yVs85t1DqHxw0AwcizGz5 wDKcVbWJgEkvL+4FJ7UY1jL9hs1El1kO4NX0fRRJVHi7WjvY9LmCfELQBpBY1fh3M41s qA7OnU6MVKrTOhQJXUOc6wy6uPL8XIqih20tg= Received: by 10.140.172.21 with SMTP id u21mr1907111rve.208.1249920318956; Mon, 10 Aug 2009 09:05:18 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id k37sm23210850rvb.2.2009.08.10.09.05.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 09:05:18 -0700 (PDT) Message-ID: <4A80453B.1000203@gmail.com> Date: Mon, 10 Aug 2009 12:05:15 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] DNS over SCTP problems, part 1, theory Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In general, I'm opposed to trying to run DNS over SCTP. I've started composing this message several times (previously for the NANOG list), as this is a complicated issue. I've even downgraded the "Subject:" from "considered harmful" to "problems" to try to be less alarmist.... I'd hoped that the IETF would have paid attention and made the changes to the SCTP protocol suggested circa 2000. Sadly, that has not happened. SCTP is an overly complicated protocol, with different kinds of TLV parameters, some of which are called "chunks" instead. It probably would have been better to only have chunks. But DNS packets already have their own variable length parameters, so there's 4 or more layers of variable length checking, and overlapping layers of error returns. It would be easier and better to add cookie extensions to EDNS0 (or TCP). === SCTP asserts that is has "[a] cookie mechanism, similar to" the Photuris security protocol "described by Karn and Simpson in [RFC2522]". Unfortunately, the authors don't seem to have an actual understanding of the underlying theory of cookies and Message Authentication Codes (MACs). The resulting cookie specification is at best half-baked. [NB: There are many chunky and cookie puns in the specification.] In SCTP, the Verification Tag field(s) performs a similar function to the Photuris Cookie pair. The Verification Tags are only 32 bits. Only 1 tag is present in the common header. Photuris Cookies are 128 bits each. The *PAIR* of cookies forms the 256-bit message identification found in every Photuris common header. Why 256-bits? According to Ron Rivest's calculations, that's enough for a multi-terabit per second attack. Even 15 years ago, we were planning for higher link speeds and long delay paths. 32 bits is not remotely enough today. Not for gigabit links, not for satellite links, nor for any other broadcast/multi-path/radio links. The Verification Tags seem to be nonces (generated randomly, used once). "Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the life time of an association." [page 72, section 5.3.1] I've not been able to discern how this happens, as the Verification Tag sent by the initiator is merely sent back by the responder (who discards it). And the responder is depending on the initiator to send back its own (discarded) random nonce, so garbling could cause the entire exchange to fail without notice. Or not fail, depending entirely on the implementation.... A random number that is different in every message, merely to identify its response, might have some utility intended to prevent mid-connection guessing attacks. Even then, 32-bits is not really adequate today. In SCTP, the exchange of its single "Cookie", created entirely by the responder, begins one packet later than Photuris. For some odd reason, it suggests using a MAC. In cryptologic terminology, a MAC requires a secret verifiable by both parties. There's not any such secret in SCTP, so there's no "authentication" (the "A" in "MAC"). Unlike Photuris, there are no requirements for its generation. It's not specified to be dependent on the initiator's Verification Tag, nor the responder's Verification Tag, nor the IP addresses, nor the ports. It's simply opaque. Hopefully, it's not merely dependent on the internal secret used at the time of generation. That would be an easy replay attack. The attacker would merely send a valid request, get the current "cookie" and its time remaining, and then send spoofed packets. The time can be used to estimate the number of attempts before making another valid request.... Moreover, the specification explicitly leaks the length of time the internal secret used to generate the responder "cookie" will remain valid! This is very bad. If that wasn't bad enough, the specification allows the initiator to suggest lengthening the "stale cookie" time by a "Cookie Preservative" parameter. Fortunately, that can be ignored. Finally, for any protocol (let alone a "security" protocol), there should be some method for determining and recovering from an attack. There are plenty of error messages, but the single most important lack is signaling between the parties that there has been unknown intermediate tampering, or that the other party has lost all its prior state. Photuris has the simplest method (brilliantly suggested by Keromytis): a Counter of the number of previously established connections. -- to unsubscribe send a message to namedroppers-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 Aug 10 09:46: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 5A1A33A6B34; Mon, 10 Aug 2009 09:46:08 -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 w8s1wEF9Km9E; Mon, 10 Aug 2009 09:46:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BA933A6A3E; Mon, 10 Aug 2009 09:46:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaXx5-0008XT-40 for namedroppers-data0@psg.com; Mon, 10 Aug 2009 16:42:27 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaXx1-0008X2-Lk for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 16:42:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 31359AC4FD for ; Mon, 10 Aug 2009 16:42:23 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Mon, 10 Aug 2009 12:05:15 -0400." <4A80453B.1000203@gmail.com> References: <4A80453B.1000203@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 10 Aug 2009 16:42:23 +0000 Message-ID: <8560.1249922543@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Mon, 10 Aug 2009 12:05:15 -0400 > From: William Allen Simpson > > It would be easier and better to add cookie extensions to EDNS0 (or TCP). edns0 and tcp have other problems that make datagram-friendly transport alternatives worth looking at. large messages, state load at high volume. if sctp isn't suitable then we may be looking at extensions to udp, or at some completely new transport. btw, would photuris be a candidate? -- to unsubscribe send a message to namedroppers-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 Aug 10 09:55: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 3FF9328C18A; Mon, 10 Aug 2009 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 tswD5wU6Zuz0; Mon, 10 Aug 2009 09:55:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BCD73A6CBF; Mon, 10 Aug 2009 09:55:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaY7S-000A0Y-JD for namedroppers-data0@psg.com; Mon, 10 Aug 2009 16:53:10 +0000 Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaY7N-0009zm-F6 for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 16:53:08 +0000 Received: by ewy28 with SMTP id 28so136789ewy.41 for ; Mon, 10 Aug 2009 09:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=bU6t8TKULSzcVVD81lwu6VD56tSkbQb6aGuviYp+Ue4=; b=w07OvwQTu8vSzeicFEtLhhA6HJdZsyfmPpKmSgtmGvcm1wVUMwlrqeccLwBoHT++WP km3BbrrCiyDeL3lVVUt8Qyw7LUnpWgW2Bx2KUJM8k5skHEtIPAVluhblWPOaouh11Wld Jh1sm3WMrALKng1IQxurw4POYaKsp9kh+LCx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=Q57A47xGLEZfm0JX2NoHq2xFv2WLG8KQ+djuhEUVl2UurV8zPvlaBrieVSZeJklyJo GGpHkvbPlvflstEBOGPeXVtHSo2gpv+Rs+uyXoqOaVJuxdyp7sefnx68FOxZslbdKA30 n8+kpPX/SHpaSBr/VRSo5gNRw4Rk6vWmVHRWs= MIME-Version: 1.0 Received: by 10.210.68.17 with SMTP id q17mr5169921eba.58.1249923184124; Mon, 10 Aug 2009 09:53:04 -0700 (PDT) From: bert hubert Date: Mon, 10 Aug 2009 18:52:44 +0200 Message-ID: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> Subject: [dnsext] NSEC3 confusion (in .org) To: "namedroppers@ops.ietf.org 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: Hi everybody, As indicated previously, I'm implementing DNSSEC in a PowerDNS prototype, and this is succeeding pretty well, well enough that I've decided to go for NSEC3 support. I've previously asked DNSSEC questions on the list, and was invited to keep this up, as questions from implementation may imply inclarity in the RFCs, so I gratefully make use of the invitation by asking another question. I'm now studying the huge complexity that is NSEC3, and I'm confused for what RRSETs I should generate NSEC3 records. When I query .org for a non-existent delegation, I get three NSEC3's returned. Wouter Wijngaards helped me understand why three are required (thanks!), but what I don't get is how two of these three NSEC records appear to start from an A RRSET. As far as I know, there are no non-glue A records in ORG? Or does this mean I need to hash non-authoritative data too? To observe, try: $ dig www.123.456.powerdnssecc.org +dnssec @D0.ORG.AFILIAS-NST.org. | grep "IN NSEC3" h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB H9RSFB7FPF2L8HG35CMPC765TDK23RP6 NS SOA RRSIG DNSKEY NSEC3PARAM 3gltncluplu62jh7veingh4epqqfj6pj.org. 86400 IN NSEC3 1 1 1 D399EAAB 3GNP00TJJB0VVL9K7OCT4RDEBB9NJ229 A RRSIG vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 1 1 1 D399EAAB VAJL90D4DFJFL9N6TVEDLDAI33BGAO6S A RRSIG I've also asked Afilias what their take on this is, but I assume I misunderstand how NSEC3 works. RFC 5155, 7.2 however appears to imply that NSECs should only be generated for authoritative data. Thoughts? 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 Aug 10 10:34: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 D6FA928C1D3; Mon, 10 Aug 2009 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 l8oCoH56R-5R; Mon, 10 Aug 2009 10:34:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF73C28C1DD; Mon, 10 Aug 2009 10:34:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaYgh-000FZj-5Z for namedroppers-data0@psg.com; Mon, 10 Aug 2009 17:29:35 +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 1MaYgV-000FXt-7S for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 17:29:31 +0000 Received: from [10.31.200.194] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7AHTFew087795; Mon, 10 Aug 2009 13:29:16 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> Date: Mon, 10 Aug 2009 13:29:13 -0400 To: bert hubert From: Edward Lewis Subject: Re: [dnsext] NSEC3 confusion (in .org) Cc: "namedroppers@ops.ietf.org 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: Just to make sure, the "error" is in "powerdnssecc.org" and the www.123.455 is just a red herring here. What the NSEC and NSEC3 both are doing is providing proof that the algorithm in RFC 1034, 4.3.2 ("the algorithm") is indeed being followed and "where a match is not possible" - that a match was indeed not possible. The difference here between NSEC and NSEC3 is that NSEC "exposes" the internal structure (as well as all the names, but that's not the issue here) of the zone while NSEC3 "flattens" the zone into a single list. Because of wild cards, you need to have three proofs to deny that there is a match for a name. One is the name itself must be "absent." Two, you need proof that the *claimed* "closest encloser" is indeed the closest encloser. And then three you need proof that there was no "*" label below the closest encloser. I'm no whiz with hashes so I tried this: ;; QUESTION SECTION: ;powerdnssecc.org. IN A h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 ... NSEC3PARAM 3gltncluplu62jh7veingh4epqqfj6pj.org. 86400 IN NSEC3 ... vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 ... administrators-computer-4:~ edlewis$ dig powerdnsseccc.org +dnssec h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 ... NSEC3PARAM jmnb7p7ulrsn3c0h2fnun2bo4eos72tt.org. 86400 IN NSEC3 ... vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 ... I'll wager then that "h9p7u7tr2u91d0v0ljs9l1gidnp90u3h" is the hash for the apex (it owns NSEC3PARAM). And I'll wager that "3gltncluplu62jh7veingh4epqqfj6pj" covers the first name (as opposed to the one with yet another c). So that means "vad5ip2eetmcrkvsv6teloij2vi1cul3" would cover the asterisk. To try to confirm that, I'll ask for it... ;*.org. IN A ;; AUTHORITY SECTION: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 ... NSEC3PARAM vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 ... This time I get two - because the proof there is no asterisk label (exact match) is the same as the proof that there is no "source of synthesis" (RFC 4592 speak for the "*" label). Does that make sense? NSEC3 #1 says the QNAME isn't here, NSEC3 #2 identifies the closest encloser (by denying their is a closer name to QNAME), and NSEC3 #3 reports that there's no source of synthesis. At 18:52 +0200 8/10/09, bert hubert wrote: >Hi everybody, > >As indicated previously, I'm implementing DNSSEC in a PowerDNS >prototype, and this is succeeding pretty well, well enough that I've >decided to go for NSEC3 support. >I've previously asked DNSSEC questions on the list, and was invited to >keep this up, as questions from implementation may imply inclarity in >the RFCs, so I gratefully make use of the invitation by asking another >question. > >I'm now studying the huge complexity that is NSEC3, and I'm confused >for what RRSETs I should generate NSEC3 records. > >When I query .org for a non-existent delegation, I get three NSEC3's >returned. Wouter Wijngaards helped me understand why three are >required (thanks!), but what I don't get is how two of these three >NSEC records appear to start from an A RRSET. As far as I know, there >are no non-glue A records in ORG? > >Or does this mean I need to hash non-authoritative data too? > >To observe, try: >$ dig www.123.456.powerdnssecc.org +dnssec @D0.ORG.AFILIAS-NST.org. | >grep "IN NSEC3" >h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB >H9RSFB7FPF2L8HG35CMPC765TDK23RP6 NS SOA RRSIG DNSKEY NSEC3PARAM >3gltncluplu62jh7veingh4epqqfj6pj.org. 86400 IN NSEC3 1 1 1 D399EAAB >3GNP00TJJB0VVL9K7OCT4RDEBB9NJ229 A RRSIG >vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 1 1 1 D399EAAB >VAJL90D4DFJFL9N6TVEDLDAI33BGAO6S A RRSIG > >I've also asked Afilias what their take on this is, but I assume I >misunderstand how NSEC3 works. RFC 5155, 7.2 however appears to imply >that NSECs should only be generated for authoritative data. > >Thoughts? > > 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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Mon Aug 10 10:51: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 95FEF3A6CAC; Mon, 10 Aug 2009 10:51: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 Y2QPEI9OA6Qr; Mon, 10 Aug 2009 10:51:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7B1F3A6C48; Mon, 10 Aug 2009 10:51:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaYyd-000In4-8y for namedroppers-data0@psg.com; Mon, 10 Aug 2009 17:48:07 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaYyZ-000ImX-HO for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 17:48:05 +0000 Received: by pzk38 with SMTP id 38so3427647pzk.33 for ; Mon, 10 Aug 2009 10:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UPn6wi36ORogMtshUlybXgBtrbwC/NlbVU9jmER9Y7s=; b=GtqHVWqwmu44yCRZ53PLjl7gvYTq4ska6yDNWdeiCkqxBYnm5SPtYGEfB+JcuHrHHN dy33u2BTVAR2A3qSKIDB4exo0X4nImfFad+8E+P01VSsAQ3HFAoJQwW6HvKafuAK1qNj abGd8HMORdV16uGQe91IbBjMq+Ur+qybrAA5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VilW9aHHt25Ag8As7fFGT+tY8GAKrlVRWgnSsPEck8FEdoCTjLXddUbm+UUElzOY8N +PbLlPQuk6MhrWojn0bQqgzLStr4SnhUeXuxcaEGOzoi0CC8palVyD+AN034Mf6CHNOW s8++rUftZBXTYi4vn8IJhjS1rhh5Nbm3FmPcI= Received: by 10.114.77.9 with SMTP id z9mr6610592waa.76.1249926482868; Mon, 10 Aug 2009 10:48:02 -0700 (PDT) Received: from SJC-Office-NAT-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id f20sm7509555waf.52.2009.08.10.10.48.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 10:48:02 -0700 (PDT) Message-ID: <4A805D4F.20407@gmail.com> Date: Mon, 10 Aug 2009 10:47:59 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: William Allen Simpson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> In-Reply-To: <4A80453B.1000203@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/10/09 9:05 AM, William Allen Simpson wrote: > SCTP is an overly complicated protocol, with different kinds of TLV > parameters, some of which are called "chunks" instead. It probably > would have been better to only have chunks. > > But DNS packets already have their own variable length parameters, so > there's 4 or more layers of variable length checking, and overlapping > layers of error returns. > > It would be easier and better to add cookie extensions to EDNS0 (or TCP). Concerns prompting a recommendation of SCTP regard large UDP packets attempting to return DNSSEC answers, and if or when that becomes blocked, subsequent reliance upon TCP Fallback. Some have suggested partial UDP responses be enabled by an EDNS0 option. In essence, this develops a sequential transport protocol lacking effective congestion avoidance, since this relies on application layer behaviors. When it was pointed out to SPF proponents the time their sequential DNS queries might take, they imposed timeouts at the application layer which was free to restart the process against the same target immediately. :^( Applications wanting faster DNS responses might simply request all pages at once to reduce latency. Perhaps this could be avoided by returning tokens needed to request subsequent pages. This scheme becomes increasingly fragile with packet loss. Your comments about needing better Cookies appears to refer to the experimental RFC 2522 that establishes short lived session keys. You appear to not understand what SCTP cookies provide. A cookie represents the entire INIT chunk, tie-tags (two unsigned 32 bit variables), time-stamps, and time-stamp life. When combined with the two verification tags, this depends upon four 32 bit association variables. These values can then be protected by a secret held by the server and a secure hash. The SCTP cookie validates the source of the client. There are SCTP AUTH RFC 4895, and SCTP TLS RFC 3436 to increase the level of protection that SCTP affords. Frankly, DNSSEC has that covered. Why are are worried about SCTP verification tags being modified? -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 Aug 10 11:00: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 66B373A6853; Mon, 10 Aug 2009 11:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-0.610, 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 zpxTXdUgamfN; Mon, 10 Aug 2009 11:00:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74E003A67EF; Mon, 10 Aug 2009 11:00:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZ7z-000KMY-Qc for namedroppers-data0@psg.com; Mon, 10 Aug 2009 17:57:47 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZ7v-000KLk-Mo for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 17:57:45 +0000 Received: by pzk38 with SMTP id 38so3433166pzk.33 for ; Mon, 10 Aug 2009 10:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=k6rCnaRCLRnd6NQ+Nm6AV7z9Ygg6BVy4o8Q553eFtJ0=; b=kdnGsa4fDqD594agMBjQ3OqAIVmd7mQ9QhpO5OpcD/6KmS8+AtSIRvLTqzgmECKhzW 7yVVW4oimUp6VnPiEzjJJChUgXC7ZS+JRUmcYv8xG880O9NGZ9MDII8yKuUcie+woIyk pdPqAuuxtSliK34xIgouGcO4lfSM0CNvPwkHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=o7XYRWAT4pcDDV+c7wclkyS8yMDUnTcOb/Zk1UKVBA1zVK5abPpVLl/9tH32fVyKg7 7FDhKTdKUIkMgwjJcuPLGLgRi+1iPsNVrf9carF6t0pHDU85V2aSY4r4ZMUItPMQDxhu 8Esj4NTKTlH+hKnsgdFt0tnw9oSIERnYorWe8= Received: by 10.114.59.14 with SMTP id h14mr6673120waa.11.1249927063032; Mon, 10 Aug 2009 10:57:43 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id m28sm7590268waf.37.2009.08.10.10.57.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 10:57:42 -0700 (PDT) Message-ID: <4A805F92.4060703@gmail.com> Date: Mon, 10 Aug 2009 13:57:38 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] DNS over SCTP problems, part 2, practice Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In my previous thread, "DNS over SCTP problems, part 1, theory", some of the most egregious security problems are covered. This thread is for some additional operational difficulties. SCTP is an overly complicated protocol, with different kinds of TLV parameters, some of which are called "chunks" instead. It probably would have been better to only have chunks. But DNS packets already have their own variable length parameters, so there's 4 or more layers of variable length checking, and overlapping layers of error returns. It would be easier and better to add cookie extensions to EDNS0 (or TCP). === SCTP has a "State Cookie" that is of unspecific, variable length. "An implementation SHOULD make the cookie as small as possible to ensure interoperability." [Pages 50-51, section 3.3.11; 61, section 5.1.3.] How small? What's the minimum size? How about the maximum size? The specification doesn't specify.... Obviously, a 32-bit cookie would be a waste of space and time. But apparently that's allowed. Even a zero bit cookie is allowed. There has been recent discussion about whether to upgrade DNSsec from SHA-1 (160-bits) to SHA-256. One of the issues is the change in size. Yet this is peanuts compared to a specification that from the outset failed to provide for expected sizes. Upgrading a SCTP implementation could cause the DNS to fail without warning. The error messages are not sufficient to deterministically indicate that it's the length of the "State Cookie" causing the problem. === SCTP has some facilities for multi-homing. One might think this would support anycast DNS servers. One might be wrong. The "State Cookie" is dependent on a secret. Certainly, such a secret would not be very secure passed in the clear between anycast systems, nor could a deterministically generated "secret" remain secret for long. Some form of confidentiality protocol would be required. Moreover, it would not be as easy to ensure that truly random secrets time-out synchronously. There's no provision for falling back to a specific system, nor for error messages that relate to different systems handling the subsequent traffic. === SCTP has many options for control and data chunks for streams (useless for DNS), yet is missing well-known TCP options that make RTT calculation and congestion control easier. Others have already discussed the underlying assumption that connections are long-term. Operationally, this is not a good fit 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 Mon Aug 10 11:24: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 09E8B3A6853; Mon, 10 Aug 2009 11:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=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 6REXpwa6Daqk; Mon, 10 Aug 2009 11:24:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3049328C170; Mon, 10 Aug 2009 11:24:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZUR-000NS5-MY for namedroppers-data0@psg.com; Mon, 10 Aug 2009 18:20:59 +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 1MaZUL-000NRi-L2 for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 18:20:57 +0000 Received: from [10.31.200.194] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7AIKjCC088408; Mon, 10 Aug 2009 14:20:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0908101058o7d51bda5i5af6b8a4556eed59@mail.gmail.com> References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> <3efd34cc0908101058o7d51bda5i5af6b8a4556eed59@mail.gmail.com> Date: Mon, 10 Aug 2009 14:20:34 -0400 To: bert hubert From: Edward Lewis Subject: Re: [dnsext] NSEC3 confusion (in .org) Cc: Edward Lewis , "namedroppers@ops.ietf.org 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:58 +0200 8/10/09, bert hubert wrote: >The thing I wonder about is how two of the NSEC3s can claim to have an >A in its type-set, since .org is 'delegation only'. This is the tricky part. I mean "getting over that." The catch is that the hashes are sorted in the order of the hashes, not the order of the zone as DNSSEC has come to define. (Pre-DNSSEC there was no order to a zone except that the apex came first.) Hmm, oh, yeah, about why there are "A" records in the bitmaps. Good question. I missed looking into that last message. I don't see them in "gov." NSEC3's. (You still get 3 NSEC3's, but the bit maps are "NS" - just haven't hit a DS'd one.) >Not looking forward to the empty non-terminals bit either. In the development days, there was a large fear of them. But then we "discovered" the notion of the closest encloser and that erased a lot of the pain. Yes, you have to generate NSEC3's for all nodes, empty or not, and that is one nuisance I didn't like. But once all is set up, then processing queries is not hard - because in the case of a NXDOMAIN response you still need the same three NSEC3's - the QNAME, proving the closest encloser, and the lack of a *-label. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Mon Aug 10 11:40:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F233A6F11; Mon, 10 Aug 2009 11:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70IexZCLVwvd; Mon, 10 Aug 2009 11:40:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15FE83A6892; Mon, 10 Aug 2009 11:40:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZiG-000PNt-Ax for namedroppers-data0@psg.com; Mon, 10 Aug 2009 18:35:16 +0000 Received: from [209.85.200.171] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZiA-000PMF-W9 for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 18:35:12 +0000 Received: by wf-out-1314.google.com with SMTP id 29so1365647wff.32 for ; Mon, 10 Aug 2009 11:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=j4Q/5vaf6fOVE+PBc4l78Qn0P7zKZqR8A1jZJlciPok=; b=XATPUU3tLoUy13qaLEvPoqqPrexLoMmZzn5UmaLIAAflqjrj0cfcJN/faY2z5rrfFY AbHIYGEtm+Y54MTuUTwAj0Y0YQszW3ChKXwj+2QUhRE965n3LaJMl2IJW8hJ1jKxCy6e yzMpqFPgynJdzhEkl1RAAQoGSwO5xbzV12zc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=bzw7TGuB/cLiRFTy7f2t0Jy2NdRL1hmxQvxgcesWZ9dRBOVzA86QSBjgtVMXf8TPDy yhbCGc9/lFBBSfafBiD3k5jYlineXtpktmp00LPurRZ39SGn98M/bGDmP07cRRJLEri4 tGi9CcfvrPmy2pXsTgu3WDHPPPCqzT3uCr4hE= Received: by 10.142.233.9 with SMTP id f9mr194278wfh.44.1249929310178; Mon, 10 Aug 2009 11:35:10 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 32sm13097139wfc.14.2009.08.10.11.35.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 11:35:09 -0700 (PDT) Message-ID: <4A80685A.1080104@gmail.com> Date: Mon, 10 Aug 2009 14:35:06 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> In-Reply-To: <8560.1249922543@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> Date: Mon, 10 Aug 2009 12:05:15 -0400 >> From: William Allen Simpson >> >> It would be easier and better to add cookie extensions to EDNS0 (or TCP). > > edns0 and tcp have other problems that make datagram-friendly transport > alternatives worth looking at. large messages, state load at high volume. > if sctp isn't suitable then we may be looking at extensions to udp, or at > some completely new transport. > SCTP has greater state load than TCP. It only has the advantage that the state is delayed until after the initial handshake, by passing the context back to the initiator, and expecting the initiator to pass it back again. Clever, but that could have easily been added as a TCP option. SCTP is much more complex than either EDNS0 or TCP. Whatever happened to the EDNS0 shortcut, where only part of the answer was passed back, and the rest was requested in a second exchange? That would have generated a lot less packets and RTT and state. > btw, would photuris be a candidate? > No, that's an entire protocol (like DNS) that was specifically designed to generate session keys for other protocols to use (just as DNS looks up addresses and stuff for other protocols to use). Photuris ran over UDP (and PPP, although never published by IETF). -- to unsubscribe send a message to namedroppers-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 Aug 10 12:12: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 A340028C20D; Mon, 10 Aug 2009 12:12:29 -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 dFgvDem0peAv; Mon, 10 Aug 2009 12:12:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C991228C212; Mon, 10 Aug 2009 12:12:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaE4-00049L-BC for namedroppers-data0@psg.com; Mon, 10 Aug 2009 19:08: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 1MaaDw-00048B-GH for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 19:08:02 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F254BAC526 for ; Mon, 10 Aug 2009 19:07:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Mon, 10 Aug 2009 14:35:06 -0400." <4A80685A.1080104@gmail.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 10 Aug 2009 19:07:59 +0000 Message-ID: <14621.1249931279@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Mon, 10 Aug 2009 14:35:06 -0400 > From: William Allen Simpson > > Whatever happened to the EDNS0 shortcut, where only part of the answer > was passed back, and the rest was requested in a second exchange? there was an MD bit ("more data") in the original EDNS0 proposal but it was removed by the working group in the name of protocol simplification. there's a current proposal ("page mode") by george barwood that i don't like because then state has to be held in the application rather than in the stack, and i don't want to pay in context switches to resist a ddos. > That would have generated a lot less packets and RTT and state. if N>1 packets have to remain associated, then somebody somewhere's got state. but we need something that isn't like current udp or current tcp. from what you and florian have said, sctp isn't going to be "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 Mon Aug 10 12:30: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 7BBC63A6C53; Mon, 10 Aug 2009 12:30:00 -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 XEiICGnNpFI0; Mon, 10 Aug 2009 12:29:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 533FE3A68F5; Mon, 10 Aug 2009 12:29:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaVb-0006Ud-4W for namedroppers-data0@psg.com; Mon, 10 Aug 2009 19:26:15 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaVW-0006UB-33 for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 19:26:12 +0000 Received: by pzk38 with SMTP id 38so3484719pzk.33 for ; Mon, 10 Aug 2009 12:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NecZiCvKeRZjbbcuSOFkWFtGBKskyjFE0r1qmK6tRUY=; b=YazzSWSdbdMy+vRsTDR6UiiQW9z/lfjsQ5ucp3MoJJ/3AcGomn+1rWPBYtgXpxNkW3 q7Bfb1WYbQz6GuJvpxPr3GkIfCVNuZ3ANsDW78pvCrPfT/61Znlhh8KWy8dik/+pcBLy fSE+srjUxlQp9D6088TY7/pKyVGDjDtQw4CIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=W5QsA1N9Oxiok2xfkP5ZEojqE1XDQU6v2HYI3XRGC7lzW6Qh2pE9r4j7vSAeEwqH05 c+Bo5RCaM45g8UmJRTAA6RsqJtNsbtuOCm2bdKbmA88gzaNYQ4PPHxkiB3Ga9zgzRNTa CRl7ieAb+pc3nWtkEwJI9yMtNsegJLVawVWrI= Received: by 10.114.254.8 with SMTP id b8mr6736427wai.106.1249932369508; Mon, 10 Aug 2009 12:26:09 -0700 (PDT) Received: from SJC-Office-NAT-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id m6sm7776813wag.33.2009.08.10.12.26.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 12:26:08 -0700 (PDT) Message-ID: <4A80744E.5080400@gmail.com> Date: Mon, 10 Aug 2009 12:26:06 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: William Allen Simpson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> In-Reply-To: <4A805F92.4060703@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/10/09 10:57 AM, William Allen Simpson wrote: > But DNS packets already have their own variable length parameters, so > there's 4 or more layers of variable length checking, and overlapping > layers of error returns. > > It would be easier and better to add cookie extensions to EDNS0 (or TCP). Additional DNS exchanges based upon EDNS0 options are likely inserted by the application or the API which makes control over congestion avoidance questionable and the API more complex. > SCTP has a "State Cookie" that is of unspecific, variable length. SCTP cookie information is exchanged during association initialization. DNS data would not be exchanged by the server until receipt of cookie ack, just as there would not be any during initialization of TCP connections. > There has been recent discussion about whether to upgrade DNSsec from > SHA-1 (160-bits) to SHA-256. One of the issues is the change in size. SCTP can fragment and reassemble packets that exceed association PMTUs. SCTP headers afford a means to directly place data to avoid copying and head of queue blocking. A win over TCP. > Upgrading a SCTP implementation could cause the DNS to fail without > warning. When SCTP is not supported, the fallback would be to UDP and then TCP. > The error messages are not sufficient to deterministically indicate > that it's the length of the "State Cookie" causing the problem. See above. > SCTP has some facilities for multi-homing. One might think this would > support anycast DNS servers. One might be wrong. SCTP would be affected by anycast in a similar manner to that of TCP. > The "State Cookie" is dependent on a secret. Certainly, such a secret > would not be very secure passed in the clear between anycast systems, nor > could a deterministically generated "secret" remain secret for long. Some > form of confidentiality protocol would be required. Moreover, it would not > be as easy to ensure that truly random secrets time-out synchronously. Concerns about SCTP cookies or error handling appear exaggerated. SCTP cookies mitigate source spoofing which is accomplished without secrets and hashes. A spoofed packet would still need to guess the value for 4 x 32 bit variables plus the TSN. Distributing zones to any cast servers could easily include a salt added to a shared secret. > There's no provision for falling back to a specific system, nor for error > messages that relate to different systems handling the subsequent traffic. SCTP does not need to support multi-homing. DNS already provides alternative server mechanisms. > SCTP has many options for control and data chunks for streams (useless for > DNS), yet is missing well-known TCP options that make RTT calculation and > congestion control easier. Review sctpConstants.h for a better idea of the application layer. Verification Tags and TSN permit the tracking of specific exchanges, and their response. > Others have already discussed the underlying assumption that connections > are long-term. When queries are made in bursts (perhaps while obtaining various server resolutions related to a specific domain), being able to combine several closely spaced transactions into a common association will significantly reduce the overall latency. Heartbeat rates can be adjusted, and associations can end at any time. Persistence of associations might be dictated by use, and resource availability. > Operationally, this is not a good fit for DNS. SCTP does offer a good fit. Use of SCTP by DNS will also help SCTP support for use with HTTP. At some distant point in time, SOHO routers might even be able to handle multi-homing with IPv4. :^) -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 Aug 10 12:38: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 5002E3A68F5; Mon, 10 Aug 2009 12:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-0.436, 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 e-QTscgrWWH5; Mon, 10 Aug 2009 12:38:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB99E28C247; Mon, 10 Aug 2009 12:38:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaeM-0007hC-T9 for namedroppers-data0@psg.com; Mon, 10 Aug 2009 19:35:18 +0000 Received: from [209.85.146.181] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaeE-0007d9-5J for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 19:35:12 +0000 Received: by wa-out-1112.google.com with SMTP id j37so645291waf.9 for ; Mon, 10 Aug 2009 12:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bFVbV/J1QWrBme4jwd4mm6zCJuU+3wZkf2A5UwKeOxQ=; b=wS+fdHbuJnojF9Jj0D4t43wIFJHtddE3wS3Yzx1xTsl9G/Sp/Pv69NXSr5O5EF3egy Aj4IjvvNMEqE4TB+u6Sl/D6aYXJaodWlP+J3egtzKneOthzvqip6H273VXCMpmBUM4IZ o4cjKO3j7l9NSSJEnDC+tyoaSW9Ae/3keLSvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ILv9+Y8v2OTduVNO1uL+uJ91LdL6oCeOMC2ZYy9Gkmx7Skr3kdKSR9Z0VnuCktzhwr G8vSUbEOIMgrBj3fzAa7tztlSb9uOy0X/CA4opUpx6v5j3B6TeD9RLJ419rSAOojansm prd695okPkZ9dUX3w20F/O+B3QwsnLRrtGBds= Received: by 10.140.251.12 with SMTP id y12mr1149702rvh.3.1249932909376; Mon, 10 Aug 2009 12:35:09 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id k41sm23812984rvb.48.2009.08.10.12.35.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 12:35:08 -0700 (PDT) Message-ID: <4A807668.2020603@gmail.com> Date: Mon, 10 Aug 2009 15:35:04 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <4A805D4F.20407@gmail.com> In-Reply-To: <4A805D4F.20407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Doug Otis wrote: > Concerns prompting a recommendation of SCTP regard large UDP packets > attempting to return DNSSEC answers, and if or when that becomes > blocked, subsequent reliance upon TCP Fallback. > Thank you for restating the obvious. Hint: I wrote one of the first widely deployed DNS implementations, circa 1987 (yes, that's an 8). And was peripherally involved in the first DNSsec go 'round.... > Some have suggested partial UDP responses be enabled by an EDNS0 option. Long ago, I was in this camp. What happened to the option? > In essence, this develops a sequential transport protocol lacking > effective congestion avoidance, since this relies on application layer > behaviors. When it was pointed out to SPF proponents the time their > sequential DNS queries might take, they imposed timeouts at the > application layer which was free to restart the process against the same > target immediately. :^( > OK, prove that SCTP (4 handshakes plus data plus close, probably 6-8 RTT) will take less time than 2-3 RTT of UDP? Yes, there are programmers that do stupid things, and applications that do stupid things, and operating systems that do stupid things. Your point? > Applications wanting faster DNS responses might simply request all pages > at once to reduce latency. Perhaps this could be avoided by returning > tokens needed to request subsequent pages. This scheme becomes > increasingly fragile with packet loss. > True. But an appropriate design can handle it. > Your comments about needing better Cookies appears to refer to the > experimental RFC 2522 that establishes short lived session keys. Yes, I quoted and cited the SCTP references to RFC-2522. Arguably, some ideas from Phorutis were appropriated without understanding them. > You > appear to not understand what SCTP cookies provide. A cookie represents > the entire INIT chunk, tie-tags (two unsigned 32 bit variables), > time-stamps, and time-stamp life. When combined with the two > verification tags, this depends upon four 32 bit association variables. > These values can then be protected by a secret held by the server and a > secure hash. > Interesting, that /one/ of us might "not understand what SCTP cookies provide." Did you take a peek at the authors of RFC-2522? Now, please explain exactly where in RFC-4960 your interpretation of that whole megillah was defined? All I see is the technically incorrect and woefully insufficient: 5.1.3. Generating State Cookie ... 3) From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key.... ... Note there's no mention of "the entire INIT chunk, tie-tags (two unsigned 32 bit variables), time-stamps, and time-stamp life." None of those are in the traditional TCB. And that's my point. Those should all be hashed in the cookie. That should be specified. Anything else should be non-conformant. Even with "four 32 bit association variables", that's *much* too small. Compare with Photuris: 3.3.2. Responder Cookie The Responder secret value that affects its cookies MAY remain the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 60 seconds). The Responder-Cookie SHOULD include the Initiator-Cookie. The Responder-Cookie MUST include the Counter (that is returned in the Cookie_Response). This provides improved synchronization and protection against replay attacks. It is recommended that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own UDP Destination port, the Counter, the Initiator-Cookie, and the currently Offered-Schemes. ... That's a proper one-way hash of a *thousand* bits or more. > The SCTP cookie validates the source of the client. ... Why are are worried > about SCTP verification tags being modified? [sic] > Well, actually as a technical matter it *doesn't* validate any source. There is a nice proof that verification cannot occur without generating a shared session-key. (By memory, van Oorshot and somebody.) All a properly formed cookie can ever do is provide resistance to replay and spoofing attacks, as long as the attacker isn't in the middle. -- to unsubscribe send a message to namedroppers-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 Aug 10 13:12: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 B5C993A6972; Mon, 10 Aug 2009 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-0.382, 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 HhxQlVTMaxq3; Mon, 10 Aug 2009 13:12:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD4543A67B6; Mon, 10 Aug 2009 13:12:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mab95-000CTv-Mu for namedroppers-data0@psg.com; Mon, 10 Aug 2009 20:07:03 +0000 Received: from [209.85.198.232] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mab8z-000CTR-PW for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 20:07:00 +0000 Received: by rv-out-0506.google.com with SMTP id f9so913428rvb.41 for ; Mon, 10 Aug 2009 13:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=po4j9gjdsZfvkP7Ycbs7n+fQgwyb7lRBZKIvvs9XuZg=; b=IXNrwf/2j7Tvb2Xw9c7IInHihowRbUOxjInDOhNH8LruTujDipRqqNZC12j0SFdINm 4AYJFMaJbAZTq9Qrk3C6cSo+k+x097gTAkR4x1mBHjqgdQ676Y3tfTyhjJ+oEtyd/SIE 1mhGMtNmSeemI9oz8pZqe0Xc5YgqsOPwJCWQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=UkJC7QGKYQv/7/VPXqXcRVk4UHd0av6Qqve/YtgEEEBR/KJU/kqHbIddY4Y2Xi2v9l RV9Esbhj5pu3kVi73AGpRu9qREdjIqE9CfQLqThh70VvIKkjNkWkTxR5IMfZoiNDVNSx FFH+v61e8ltU4hLf4UCfsE0fp4F2CSKhdEjHo= Received: by 10.140.207.2 with SMTP id e2mr2210280rvg.298.1249934817407; Mon, 10 Aug 2009 13:06:57 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id l31sm26696950rvb.54.2009.08.10.13.06.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 13:06:56 -0700 (PDT) Message-ID: <4A807DDD.7080502@gmail.com> Date: Mon, 10 Aug 2009 16:06:53 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <14621.1249931279@nsa.vix.com> In-Reply-To: <14621.1249931279@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> From: William Allen Simpson >> >> Whatever happened to the EDNS0 shortcut, where only part of the answer >> was passed back, and the rest was requested in a second exchange? > > there was an MD bit ("more data") in the original EDNS0 proposal but it > was removed by the working group in the name of protocol simplification. > Ah, the joy of working groups. Now somebody's proposing simplifying even further by falling back from DNS to SCTP to TCP.... Some simplification! > there's a current proposal ("page mode") by george barwood that i don't > like because then state has to be held in the application rather than in > the stack, and i don't want to pay in context switches to resist a ddos. > I cannot find it. The words "page mode" don't appear in the archive, and the only draft-barwood I could find was resolver-mitigations-08. However, I certainly agree about context switches. >> That would have generated a lot less packets and RTT and state. > > if N>1 packets have to remain associated, then somebody somewhere's got > state. but we need something that isn't like current udp or current tcp. Like Photuris (and SCTP to a lesser extent), keep the state in the UDP packets in transit. I'll start a new design thread later (probably tomorrow). > from what you and florian have said, sctp isn't going to be "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 Mon Aug 10 13:18: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 7DF7C3A67B6; Mon, 10 Aug 2009 13:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 sNLmvyBh0htd; Mon, 10 Aug 2009 13:18:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A89603A6452; Mon, 10 Aug 2009 13:18:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MabGw-000DMU-9U for namedroppers-data0@psg.com; Mon, 10 Aug 2009 20:15:10 +0000 Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MabGm-000DKq-Vz for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 20:15:03 +0000 Received: by ewy28 with SMTP id 28so284947ewy.41 for ; Mon, 10 Aug 2009 13:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=yrit+0CoPCEc7mouT3YH5hsOpREBHhnI/zcSs5uPIms=; b=L1ybqfh0wDEwrUiG60wPQcdgB4JP9pLM5i6Xjaq/PwE/3ILgxAFdyqenhz5Eg+KtHe uP8pbu44+MHy2XhgNwmMcOzuaBAP467gz8LX7D5mkuBgYOJ2LZ3iqfbjWcm9ovzr2cYU alMq2vRx2iMFYoE3r4bjr87A6+Zc2ctKmvuXY= 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=N4NEUCs5doVGpuK8ZpNNhsIWXuSpVY3DpZB4jYkDc2A5eViTBBnUcetOrNdlc33/lG EIHFUGNlgTPC80csKfwEm2JCpBmyWilyho5acNJjrzJTRdl4V4J/OMEPwdK80kvkOnJY Tom+1GRt0VZJnqF1v/aVdcxBXuz4W6b76DGxg= MIME-Version: 1.0 Received: by 10.210.78.16 with SMTP id a16mr3250411ebb.1.1249935299162; Mon, 10 Aug 2009 13:14:59 -0700 (PDT) In-Reply-To: <4A805F92.4060703@gmail.com> References: <4A805F92.4060703@gmail.com> From: bert hubert Date: Mon, 10 Aug 2009 22:14:39 +0200 Message-ID: <3efd34cc0908101314i7fc30235ldc358ad6edcbf3b9@mail.gmail.com> Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice To: William Allen Simpson 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 Mon, Aug 10, 2009 at 7:57 PM, William Allen Simpson wrote: > In my previous thread, "DNS over SCTP problems, part 1, theory", some of > the most egregious security problems are covered. =A0This thread is for s= ome > additional operational difficulties. > SCTP is an overly complicated protocol, with different kinds of TLV And perhaps to drive in the final nail, here are some of my earlier finding= s: 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. http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01220.html > Operationally, this is not a good fit for DNS. 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 Aug 10 13:54: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 59CBF3A6810; Mon, 10 Aug 2009 13:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.339, 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 YqIaqXcRbtrY; Mon, 10 Aug 2009 13:54:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3B033A6A37; Mon, 10 Aug 2009 13:54:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MabpV-000Idr-B7 for namedroppers-data0@psg.com; Mon, 10 Aug 2009 20:50:53 +0000 Received: from [209.85.198.228] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MabpN-000Ici-ED for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 20:50:50 +0000 Received: by rv-out-0506.google.com with SMTP id f9so921125rvb.41 for ; Mon, 10 Aug 2009 13:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+qrboOOG/ipfo0KU7Da82WU3qacEnB1IsKiymTuS1uk=; b=Cu5Xsiew/MwfDNSHN58gJZHw0cruqihd9ULAPafwsyyZrZ3iihqaL6gRhQSd/jqi2b kwNnUWLvGDpGpCwY1P5x8QJKoXuqR42iMxCtticHOjbZKrvfTZByrmyDdVrsIphEyQgR SC4Qsr/zRswsgsJMrBcGPRaPZT1wscjsA7hI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=dvSm7nAjbbbpk1u+bW1n/2VGpPARMWbWuFamP9gOzV7vX6iWlAG8DwWNL/gP889dxT 6fZNWBcfsTznF1giNGl/kaEeHewiQFXiOw5Y2YBEh3LxsmuJqBs+ERrXxVUSwjf74QgF lPzcX1PJ690wD7WFnVh9nFhWCgyBWo+UuZd2Q= Received: by 10.140.185.20 with SMTP id i20mr1820645rvf.271.1249937445232; Mon, 10 Aug 2009 13:50:45 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id k2sm24521849rvb.17.2009.08.10.13.50.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 13:50:44 -0700 (PDT) Message-ID: <4A808820.7010205@gmail.com> Date: Mon, 10 Aug 2009 16:50:40 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> In-Reply-To: <4A80744E.5080400@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Doug Otis wrote: > Additional DNS exchanges based upon EDNS0 options are likely inserted by > the application or the API which makes control over congestion avoidance > questionable and the API more complex. > Goodness gracious, I'd not design it that way -- why would anybody? >> SCTP has a "State Cookie" that is of unspecific, variable length. > > SCTP cookie information is exchanged during association initialization. You can assume we've read the specification; especially replying to a message with page citations to the RFC. > DNS data would not be exchanged by the server until receipt of cookie > ack, just as there would not be any during initialization of TCP > connections. > And this is relevant, how? >> There has been recent discussion about whether to upgrade DNSsec from >> SHA-1 (160-bits) to SHA-256. One of the issues is the change in size. > > SCTP can fragment and reassemble packets that exceed association PMTUs. You can assume we've read the specification. > SCTP headers afford a means to directly place data to avoid copying and > head of queue blocking. A win over TCP. > And this is relevant, how? I'm not sure it's always true, as the checksum is in the header. And there's little control of packet alignment crossing user-system boundaries and task switching. But every TCP stack I've implemented (2) has attempted to provide this feature in the general case of routing between interfaces. >> Upgrading a SCTP implementation could cause the DNS to fail without >> warning. > > When SCTP is not supported, the fallback would be to UDP and then TCP. > Actually, since SCTP would only be the fallback from UDP, that would only leave TCP. After you've tried UDP (a 2 RTT timeout), and SCTP (minimum 4 RTT timeout, but probably with exponential backoff), why exactly are we falling back to TCP? Won't most applications have already retried another server? >> The error messages are not sufficient to deterministically indicate > > that it's the length of the "State Cookie" causing the problem. > > See above. > What above? We need deterministic error messages to indicate that the server has to be taken out of the queue, and log it. >> SCTP has some facilities for multi-homing. One might think this would >> support anycast DNS servers. One might be wrong. > > SCTP would be affected by anycast in a similar manner to that of TCP. > No, it's much worse. Anycast TCP is affected by loss of the connection. SCTP has the same problem, *and* an additional cookie problem. > Concerns about SCTP cookies or error handling appear exaggerated. SCTP > cookies mitigate source spoofing which is accomplished without secrets > and hashes. A spoofed packet would still need to guess the value for 4 > x 32 bit variables plus the TSN. Distributing zones to any cast servers > could easily include a salt added to a shared secret. > At this point, it's obvious to me that I'm speaking to somebody without a basic understanding of cookies; the concept *requires* secrets and hashes. Some years ago, the first time that I'd looked at SCTP, it seemed to me that cookies were just tacked on, after the original authors were told that those random 32-bit variables weren't cryptologically significant. Now, we've come full circle. >> There's no provision for falling back to a specific system, nor for error >> messages that relate to different systems handling the subsequent >> traffic. > > SCTP does not need to support multi-homing. DNS already provides > alternative server mechanisms. > ??? It's listed as a feature? >> SCTP has many options for control and data chunks for streams (useless >> for >> DNS), yet is missing well-known TCP options that make RTT calculation and >> congestion control easier. > > Review sctpConstants.h for a better idea of the application layer. What page in the RFC? Or how does that relate to options that aren't in the RFC? > Verification Tags and TSN permit the tracking of specific exchanges, and > their response. > ??? Random bits? >> Others have already discussed the underlying assumption that connections >> are long-term. > > When queries are made in bursts (perhaps while obtaining various server > resolutions related to a specific domain), being able to combine several > closely spaced transactions into a common association will significantly > reduce the overall latency. Heartbeat rates can be adjusted, and > associations can end at any time. Persistence of associations might be > dictated by use, and resource availability. > Nothing in any operating system I'm familiar with works that way. And you might Google "I hate keep-alives" Craig Partridge Vice-Chairman, I Hate Keep-Alives Association [For those not in the know, Phil Karn is chair of the IHKAA, ... >> Operationally, this is not a good fit for DNS. > > SCTP does offer a good fit. Use of SCTP by DNS will also help SCTP > support for use with HTTP. At some distant point in time, SOHO routers > might even be able to handle multi-homing with IPv4. :^) > Proof by assertion is not good argument. Nor is this list about HTTP. (HTTP over SCTP, shuddering at the thought.) SOHO routers need to pass EDNS today, not "some distant point in 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 Mon Aug 10 14:27: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 7869F3A6F35; Mon, 10 Aug 2009 14:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 1UiMpi44yzyj; Mon, 10 Aug 2009 14:27:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E1683A6F2E; Mon, 10 Aug 2009 14:27:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MacJS-000OGV-Nx for namedroppers-data0@psg.com; Mon, 10 Aug 2009 21:21:50 +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 1MacJO-000OFi-Jj for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 21:21: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 n7ALLgse012495; Mon, 10 Aug 2009 14:21:42 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: William Allen Simpson In-Reply-To: <4A808820.7010205@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: [dnsext] DNS over SCTP problems, part 2, practice Date: Mon, 10 Aug 2009 14:21:42 -0700 References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stupid question: This is intended primarily as a fallback position for those EDNS0 capable resolvers who find themselves behind a middlebox which blocks either EDNS0 responses, responses >512B or fragmented responses, correct? What suggestion is there that for such a middlebox will allow SCTP unmolested without needing it to be tunneled over UDP? -- to unsubscribe send a message to namedroppers-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 Aug 10 15:32: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 735353A6A1E; Mon, 10 Aug 2009 15:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.308 X-Spam-Level: *** X-Spam-Status: No, score=3.308 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs9A-OpLRHwK; Mon, 10 Aug 2009 15:32:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 756143A6E99; Mon, 10 Aug 2009 15:32:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MadKb-00096N-Nn for namedroppers-data0@psg.com; Mon, 10 Aug 2009 22:27:05 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MadKX-000961-Ak for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 22:27:03 +0000 Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MadKV-0004s8-Sk; Mon, 10 Aug 2009 23:26:59 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MadKU-0006LF-Hh; Mon, 10 Aug 2009 23:26:58 +0100 Message-ID: <025CDA87D3294DCC8B0C212D4A3D7FDC@localhost> From: "George Barwood" To: "William Allen Simpson" , References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <14621.1249931279@nsa.vix.com> <4A807DDD.7080502@gmail.com> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Mon, 10 Aug 2009 23:26:54 +0100 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 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >> there's a current proposal ("page mode") by george barwood that i don't >> like because then state has to be held in the application rather than in >> the stack, and i don't want to pay in context switches to resist a ddos. >> > I cannot find it. The words "page mode" don't appear in the archive, and > the only draft-barwood I could find was resolver-mitigations-08. Sorry, no draft as yet, just an informal proposal, see http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html 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 Mon Aug 10 17:17: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 78E783A6F69; Mon, 10 Aug 2009 17:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_45=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 oemWLSPXd1ib; Mon, 10 Aug 2009 17:17:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 786763A6F64; Mon, 10 Aug 2009 17:17:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaexI-000LUr-J0 for namedroppers-data0@psg.com; Tue, 11 Aug 2009 00:11:08 +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 1MaexC-000LU1-Or for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 00:11:05 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id A51D0E606E; Tue, 11 Aug 2009 00:11:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7B0AvDR060945; Tue, 11 Aug 2009 10:10:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908110010.n7B0AvDR060945@drugs.dv.isc.org> To: bert hubert Cc: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" From: Mark Andrews References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> Subject: Re: [dnsext] NSEC3 confusion (in .org) In-reply-to: Your message of "Mon, 10 Aug 2009 18:52:44 +0200." <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> Date: Tue, 11 Aug 2009 10:10:57 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com>, bert hubert writes: > Hi everybody, > > As indicated previously, I'm implementing DNSSEC in a PowerDNS > prototype, and this is succeeding pretty well, well enough that I've > decided to go for NSEC3 support. > I've previously asked DNSSEC questions on the list, and was invited to > keep this up, as questions from implementation may imply inclarity in > the RFCs, so I gratefully make use of the invitation by asking another > question. > > I'm now studying the huge complexity that is NSEC3, and I'm confused > for what RRSETs I should generate NSEC3 records. > > When I query .org for a non-existent delegation, I get three NSEC3's > returned. Wouter Wijngaards helped me understand why three are > required (thanks!), but what I don't get is how two of these three > NSEC records appear to start from an A RRSET. As far as I know, there > are no non-glue A records in ORG? No. Just your assumption is false. NS RRsets are removed by registrars without the glue records beneath them also being removed for spam and other network abuse issues. This causes the glue to become authoritative data. The same thing happens in COM, NET and I presume all other zones with a registry/registrar model. The registrars really should be pulling the glue records as well. It's up to the registry enforce this however. Mark > Or does this mean I need to hash non-authoritative data too? > > To observe, try: > $ dig www.123.456.powerdnssecc.org +dnssec @D0.ORG.AFILIAS-NST.org. | > grep "IN NSEC3" > h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB > H9RSFB7FPF2L8HG35CMPC765TDK23RP6 NS SOA RRSIG DNSKEY NSEC3PARAM > 3gltncluplu62jh7veingh4epqqfj6pj.org. 86400 IN NSEC3 1 1 1 D399EAAB > 3GNP00TJJB0VVL9K7OCT4RDEBB9NJ229 A RRSIG > vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 1 1 1 D399EAAB > VAJL90D4DFJFL9N6TVEDLDAI33BGAO6S A RRSIG > > I've also asked Afilias what their take on this is, but I assume I > misunderstand how NSEC3 works. RFC 5155, 7.2 however appears to imply > that NSECs should only be generated for authoritative data. > > Thoughts? > > 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: -- 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 recapturedmf@ipius.com Mon Aug 10 18:34: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 25A3C28C147; Mon, 10 Aug 2009 18:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.705 X-Spam-Level: X-Spam-Status: No, score=-13.705 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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_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 GuNBsvqWvRT7; Mon, 10 Aug 2009 18:34:41 -0700 (PDT) Received: from dslb-088-072-080-214.pools.arcor-ip.net (dslb-088-072-080-214.pools.arcor-ip.net [88.72.80.214]) by core3.amsl.com (Postfix) with ESMTP id CD0A028C181; Mon, 10 Aug 2009 18:34:38 -0700 (PDT) Received: from 88.72.80.214 by ipius.com.s8a1.psmtp.com; Tue, 11 Aug 2009 03:34:13 +0100 Date: Tue, 11 Aug 2009 03:34:13 +0100 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Stay healthy the natural way Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
If you are unable to see the message below, click here to view.
Newsletter

Events

Major advancement in medical science
 


To submit feedback about our Professionals Community, complete the feedback form at: our web site

PROFILE AND SUBSCRIPTIONS To modify your profile, email address, subscriptions, and preferences, please visit our Subscription Center.

Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and newsletters from us. Or modify your profile, subscriptions, and preferences if you're already our customer. To no longer receives these messages from us. Read more about our privacy statement.
Copyright(c) 2009, QwyixfiSystems, Inc. All rights reserved.
 
From Richard.Campbell@BuroHappold.com Mon Aug 10 19:48: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 317273A68BF; Mon, 10 Aug 2009 19:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 ulV68YOGKqTq; Mon, 10 Aug 2009 19:48:19 -0700 (PDT) Received: from cluster-d.mailcontroller.altohiway.com (clusterd.mailcontroller.co.uk [213.83.66.161]) by core3.amsl.com (Postfix) with ESMTP id 3292B3A6A1D; Mon, 10 Aug 2009 19:48:18 -0700 (PDT) Received: from rlya6d.mailcontroller.altohiway.com (localhost.localdomain [127.0.0.1]) by rlya6d.mailcontroller.altohiway.com (MailController) with ESMTP id n7B2l9AJ003974; Tue, 11 Aug 2009 03:48:21 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rlya6d.mailcontroller.altohiway.com (MailControl) id n7B2kVVn029675; Tue, 11 Aug 2009 03:46:31 +0100 Received: from ex-fe02.burohappold.com ([77.73.8.93]) by rlya6d-eth0.mailcontroller.altohiway.com (envelope-sender Richard.Campbell@BuroHappold.com) (MIMEDefang) with ESMTP id n7B2kIEw027881; Tue, 11 Aug 2009 03:46:30 +0100 (BST) Received: from ex-be03.burohappold.com ([172.16.254.36]) by ex-fe02.burohappold.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 03:46:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1A2D.E61C9626" Subject: Dear Webmail User!!! Date: Tue, 11 Aug 2009 03:46:16 +0100 Message-ID: <769F37AB357BF741BC9FD2057F2618320AAB8809@ex-be03.burohappold.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dear Webmail User!!! Thread-Index: AcoaLeWbXQ586AGORwCkdSLmmYxrWQ== From: "Richard Campbell" X-OriginalArrivalTime: 11 Aug 2009 02:46:18.0408 (UTC) FILETIME=[E6F3FA80:01CA1A2D] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.195.1.116 To: undisclosed-recipients:; This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1A2D.E61C9626 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Email user, This message is from Administration centre Maintenance Policy verified that= your mailbox exceeds its limit, you will be unable to receive=20 new email, To re-set your SPACE on our database prior to maintain your INBO= X, you must click the link below.=20 =20 Click Here: http://app.formassembly.com/forms/view/108302 =20 =20 (If the link above does not appear clickable or does not open a browser win= dow when you click it, copy it and paste it into=20 your web browser's Location bar.) =20 Thank you for your cooperation. Web Mail Technical Services. This message has been scanned by MailController - www.MailController.altohi= way.com ------_=_NextPart_001_01CA1A2D.E61C9626 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Email user,

This message is from Administration centre Main= tenance Policy verified that your mailbox exceeds its limit, you will be un= able to receive
new email, To re-set your SPACE on our database prior t= o maintain your INBOX, you must click the link below.

 

Click Here: http://app.formassembly.com/forms/view/10830= 2 

 

(If the link above does not appear clickable or= does not open a browser window when you click it, copy it and paste it int= o
your web browser's Location bar.)

 

Thank you for your cooperation.

Web Mail Technical Services.

<= /DIV>

This message has been scanned by MailController.

= ------_=_NextPart_001_01CA1A2D.E61C9626-- From owner-namedroppers@ops.ietf.org Mon Aug 10 22:45:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA723A67E2; Mon, 10 Aug 2009 22:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.305, 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 icCGxB991JjT; Mon, 10 Aug 2009 22:45:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E081A3A676A; Mon, 10 Aug 2009 22:45:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mak2Y-0004jy-Hz for namedroppers-data0@psg.com; Tue, 11 Aug 2009 05:36:54 +0000 Received: from [209.85.211.201] (helo=mail-yw0-f201.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mak2U-0004jS-QZ for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 05:36:52 +0000 Received: by ywh39 with SMTP id 39so2458175ywh.32 for ; Mon, 10 Aug 2009 22:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=SHADghLbgydbGVAGahcZMUEizAD7VTVPMpHrcDbWxtk=; b=gWWCw6tjP9yyh9JFShY4buyt1yB3s/Lal0OJYlR2oB4qchwztPKhlMVpqW7naGtsh5 fPj7gmN5U4iJxWANop3ed1oyQN9f72LgMb0SVGKhZkQVR6QA85826tZO4gxhqFg59ArD MyYltI9qecFL6vllKheGR8zXrn0sdyalC+DKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=rkFFAxaEde9FzTh3OSdasN8+HD0zIo4C8TTwyZSTgfPBACxxoEzufl1u26UVmdS3IK G898bajmGMq+R6bCdLOuw8UH4QxCcwOLsIqCZjnRP4wCrrpVioJmrowqXIg5xMzSmGnJ kpHY+c13hTL+0ildKZABVH1she0UoJhLBNEag= Received: by 10.90.32.4 with SMTP id f4mr4743378agf.101.1249969009856; Mon, 10 Aug 2009 22:36:49 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 4sm1578679aga.13.2009.08.10.22.36.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 22:36:49 -0700 (PDT) Message-ID: <4A81036F.5030504@gmail.com> Date: Tue, 11 Aug 2009 01:36:47 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] Rethinking the security too large for UDP problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I'm already on record elsewhere in support of dnsssec-algo-signal-03, as that may very well solve most packet too large problems. But in the hopefully rare cases, there's simply not enough information to autonomously make a deterministic decision about the next step. What we really need to know: 1) The security algorithms supported. Easy. The Algorithm Understood (AU) option could be passed in the response, with a list of all the available algorithms. That means the truncation routine should ensure there's enough room for the option. 2) The RRTypes of the truncated records. I just don't see how to pass that in the current protocol. If we knew this, we could just ask for the rest of the records by type. 3) The total size of the untruncated data. Again, I just don't see how to pass that in the current protocol. If we knew this, we could decide whether TCP is required, or 2 or 1 should be done instead. 4) Ideally, the size of the untruncated security data per algorithm. Any ideas? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From maddest@ironcrewmc.com Tue Aug 11 00:21: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 706393A6B60; Tue, 11 Aug 2009 00:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.964 X-Spam-Level: X-Spam-Status: No, score=-14.964 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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_XBL=3.033, RDNS_DYNAMIC=0.1, 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 ehYzzXe+7kjb; Tue, 11 Aug 2009 00:21:53 -0700 (PDT) Received: from 76-14-196-89.or.wavecable.com (76-14-196-89.or.wavecable.com [76.14.196.89]) by core3.amsl.com (Postfix) with ESMTP id 3E8333A6F83; Tue, 11 Aug 2009 00:21:52 -0700 (PDT) Received: from 76.14.196.89 by mail.ironcrewmc.com; Tue, 11 Aug 2009 00:21:54 -0800 Message-ID: <000d01ca1a54$67853a80$6400a8c0@maddest> From: Darold Jordan To: Subject: Safely lose weight with Acai Diet , Endorsed by Oprah. Date: Tue, 11 Aug 2009 00:21:54 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1A54.67853A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1A54.67853A80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Lose weight without stress , Acai Berry. Food for thought, give this a try, a real try...It's free.   Enter promptly =20 =20 Thank You!=20 best regards Darold=20 Jordan ------=_NextPart_000_0007_01CA1A54.67853A80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Lose weight without stress , Acai Berry.
Food for thought, give this a try, a real try...It's free.<= /FONT>
 
Enter = promptly
Thank You!
best regards Darold=20 Jordan
------=_NextPart_000_0007_01CA1A54.67853A80-- From owner-namedroppers@ops.ietf.org Tue Aug 11 00:40: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 EE4E03A68A4; Tue, 11 Aug 2009 00:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=-1.293, 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 1+NJeTC5YsZy; Tue, 11 Aug 2009 00:40:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3B4D3A6B85; Tue, 11 Aug 2009 00:40:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Malsw-000Lhc-LB for namedroppers-data0@psg.com; Tue, 11 Aug 2009 07:35: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 1Malsn-000LfB-Iq for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 07:35:04 +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 1Malsj-0008QY-RG; Tue, 11 Aug 2009 09:34:53 +0200 Received: by bfk.de with local id 1Malsj-0006ec-MT; Tue, 11 Aug 2009 07:34:53 +0000 To: bert hubert Cc: "namedroppers\@ops.ietf.org namedroppers\@ops.ietf.org" Subject: Re: [dnsext] NSEC3 confusion (in .org) References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> From: Florian Weimer Date: Tue, 11 Aug 2009 07:34:53 +0000 In-Reply-To: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> (bert hubert's message of "Mon\, 10 Aug 2009 18\:52\:44 +0200") Message-ID: <82prb2iz1e.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: * bert hubert: > As far as I know, there are no non-glue A records in ORG? There are: ; <<>> DiG 9.5.1-P3 <<>> @a0.org.afilias-nst.info. dns1.buddycard.org. +nor= ecurse ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51573 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 4 ;; QUESTION SECTION: ;dns1.buddycard.org. IN A ;; ANSWER SECTION: dns1.buddycard.org. 86400 IN A 219.88.243.244 ;; AUTHORITY SECTION: org. 86400 IN NS a0.org.afilias-nst.info. org. 86400 IN NS a2.org.afilias-nst.info. org. 86400 IN NS b0.org.afilias-nst.org. org. 86400 IN NS b2.org.afilias-nst.org. org. 86400 IN NS c0.org.afilias-nst.info. org. 86400 IN NS d0.org.afilias-nst.org. ;; ADDITIONAL SECTION: b0.org.afilias-nst.org. 86400 IN A 199.19.54.1 d0.org.afilias-nst.org. 86400 IN A 199.19.57.1 b0.org.afilias-nst.org. 86400 IN AAAA 2001:500:c::1 d0.org.afilias-nst.org. 86400 IN AAAA 2001:500:f::1 ;; Query time: 123 msec ;; SERVER: 199.19.56.1#53(199.19.56.1) ;; WHEN: Tue Aug 11 09:29:16 2009 ;; MSG SIZE rcvd: 278 This domain is in state "PENDING DELETE RESTORABLE". The zone file provisioning is buggy. The majority of signed resources in .org are such spurious A records: $ zgrep "RRSIG A" org-2008770137-zone.gz | wc -l 5949 $ zgrep "RRSIG DS" org-2008770137-zone.gz | wc -l 20 --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Aug 11 01:16: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 D7FC43A6FB0; Tue, 11 Aug 2009 01:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=-1.601, 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 G8NGOwN5Ssmz; Tue, 11 Aug 2009 01:16:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C844B3A6A05; Tue, 11 Aug 2009 01:16:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MamU4-00012M-89 for namedroppers-data0@psg.com; Tue, 11 Aug 2009 08:13:28 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MamU0-00011g-2V; Tue, 11 Aug 2009 08:13: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=MsDv76DnKmy+fW50m+GFpfoQRL44/HJf+OZSeTiDRQ/AEmjF0KO9mv34 F/Eexh4d1s7rt599cfAkrxi5kKzrY+Uy5VGusj7oBOCqN22BHtU+9/2wH eUA+BYOKrx62PKO; 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=1249978404; x=1281514404; 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]=20DNS=20over=20SCTP=20problems,=20part=202,=20practic e|Date:=20Tue,=2011=20Aug=202009=2009:13:12=20+0100 |Message-ID:=20|To:=20William=20Allen=20 Simpson=20|Cc:=20namedro ppers@ops.ietf.org,=0D=0A=09owner-namedroppers@ops.ietf.o rg|MIME-Version:=201.0|In-Reply-To:=20<4A808820.7010205@g mail.com>|References:=20<4A805F92.4060703@gmail.com>=20<4 A80744E.5080400@gmail.com>=20<4A808820.7010205@gmail.com>; bh=NbBaWF6mzekhByZcX+66+skDHxTXEUs0g7xQnnyYPxI=; b=LsrAeT36bfjc/iM7YWqt02eD5qbVYOrG+f7ryfMRFTXzcAJ3oU4Sz1wp S+6T/M3ZC1Tel/ymGnz6GyjmWT/Ez1gmxDwCARWj3IbhjNK9E257Rcunm ToQx2bflQBYUc1m; X-IronPort-AV: E=Sophos;i="4.43,359,1246834800"; d="scan'208";a="16605670" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 11 Aug 2009 09:13:19 +0100 In-Reply-To: <4A808820.7010205@gmail.com> References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> To: William Allen Simpson Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 11 Aug 2009 09:13:12 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/08/2009 09:13:21 AM, Serialize complete at 11/08/2009 09:13:21 AM Content-Type: multipart/alternative; boundary="=_alternative 002D27828025760F_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 002D27828025760F_= Content-Type: text/plain; charset="US-ASCII" > SOHO routers need to pass EDNS today, not "some distant point in time".... Amen to that! Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 002D27828025760F_= Content-Type: text/html; charset="US-ASCII"
> SOHO routers need to pass EDNS today, not "some distant point in time"....
Amen  to that!

Ray

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


 --=_alternative 002D27828025760F_=-- -- to unsubscribe send a message to namedroppers-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 Aug 11 05:49: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 C0A2A3A70D9; Tue, 11 Aug 2009 05:49:44 -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 nH96iWpCSMsc; Tue, 11 Aug 2009 05:49:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 291EE3A70C6; Tue, 11 Aug 2009 05:49:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Maqhs-0009r8-LV for namedroppers-data0@psg.com; Tue, 11 Aug 2009 12:44:00 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Maqhj-0009q7-Bb for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 12:43:54 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60947) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Maqhi-0007KQ-Mr (Exim 4.70) (return-path ); Tue, 11 Aug 2009 13:43:50 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Maqhi-0001bP-2J (Exim 4.67) (return-path ); Tue, 11 Aug 2009 13:43:50 +0100 Date: Tue, 11 Aug 2009 13:43:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: William Allen Simpson cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: <4A80685A.1080104@gmail.com> Message-ID: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, 10 Aug 2009, William Allen Simpson wrote: > > SCTP has greater state load than TCP. It only has the advantage that the > state is delayed until after the initial handshake, by passing the context > back to the initiator, and expecting the initiator to pass it back again. > > Clever, but that could have easily been added as a TCP option. I was under the impression that TCP stacks already have this feature (SYN cookies) or have other SYN-flood protection mechanisms. So unless SCTP is a win for established associations, it isn't a win. 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 Tue Aug 11 07:23: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 0294B3A6F3F; Tue, 11 Aug 2009 07:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=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 53DZCViND+xz; Tue, 11 Aug 2009 07:23:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29D983A691D; Tue, 11 Aug 2009 07:23:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MasAJ-000OSI-5f for namedroppers-data0@psg.com; Tue, 11 Aug 2009 14:17:27 +0000 Received: from [209.85.200.169] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MasAG-000ORc-0Q for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 14:17:25 +0000 Received: by wf-out-1314.google.com with SMTP id 29so1642807wff.32 for ; Tue, 11 Aug 2009 07:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mnR251Zc3LjKYuP8+bmSMKbVMYLkuhM0/Fi4Yb2wrM0=; b=OWZWeaJfOvr/L7ZEJWUBftQWAcTT07nvHLo1+fif5rQgXvjnUPOn7VGUiqZvri760L bRiAce3mqk18jHqqgS3D4Y9uadPMnq/bt3ga/dSwWFuoPtgPAQiDIoLp17S3/SW+VA8m eONyWEhJAlcYFte1Cl7L4jSQjcFsCKiD/NajA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=N+x5qsCZA3OFtUGciy0au6MzKO7WmKVX15wYa3nPnIIYg/EhdYkgWEC5E10CgrrIFN PpHCTMo0IH1grfzbOd731W/Lkr6dIOexTa1UBf+ZrdxIU2sRo2iVAzSO/Mb2/4ZFBPzB k0Tvm18LrzpppXcI2Il19d7GFp9aV0/9If7Vs= Received: by 10.142.230.7 with SMTP id c7mr380344wfh.137.1250000243557; Tue, 11 Aug 2009 07:17:23 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 24sm16415742wfc.37.2009.08.11.07.17.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 07:17:22 -0700 (PDT) Message-ID: <4A817D6E.9040202@gmail.com> Date: Tue, 11 Aug 2009 10:17:18 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Tony Finch wrote: > I was under the impression that TCP stacks already have this feature (SYN > cookies) or have other SYN-flood protection mechanisms. So unless SCTP is > a win for established associations, it isn't a win. > It seems strange to me that this wasn't already specified, as I remember discussion back in the mid-90s. It also seems strange that it took 10+ years for Bernstein's clever (small) SYN cookies hack to be documented in the RFC series (RFC-4987). Apparently, the TCP community is even more conservative than the DNS community in making changes.... The proposal, as I remember it circa 1996, was to add an explicit Cookie option (128-bit cookie) to the original SYN, signaling to the responder that no TCB was necessary. If the Cookie option was returned (256-bit cookie) in the SYN+ACK, no TCB would be created. Then, the initiator would re-send all initial options (including the bigger 256-bit Cookie) back to the responder in the first data packet, and the responder TCB would be created. Maybe that's the original genesis of SCTP? One of the counter arguments at the time was that a robust IPv6 and IPsec would render this entirely unnecessary. Admittedly, at the time I was part of that chorus. In retrospect, I was wrong. Anyway, given the general conservative nature of TCP deployment, it would be better to work on methods for DNS to use UDP efficiently. Unless there's a *lot* of interest.... -- to unsubscribe send a message to namedroppers-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 Aug 11 07:49: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 D0DBA3A6A0A; Tue, 11 Aug 2009 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.585 X-Spam-Level: X-Spam-Status: No, score=0.585 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=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 bVJBF1IYsOsZ; Tue, 11 Aug 2009 07:49:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0718F3A6BFD; Tue, 11 Aug 2009 07:48:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Masal-0002SN-J7 for namedroppers-data0@psg.com; Tue, 11 Aug 2009 14:44: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 1Masah-0002Ru-Ig for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 14:44: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 n7BEifwZ002931 for ; Tue, 11 Aug 2009 10:44:41 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n7BEifCJ002930 for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 10:44:41 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZ9S-000Ka7-0D for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 17:59:19 +0000 Received: by ewy28 with SMTP id 28so185103ewy.41 for ; Mon, 10 Aug 2009 10:59:16 -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=ezMtN2lVzgdDoxO39EInYRhkwRZGKHDh/ki/MCEJzZ8=; b=RExyiRn8vBA6S4XK0krenh/oaj7S8dxmqH/sQQxGFkVMNFJTk3CV8Pw6F/+1b5A/+D XzHM5f/o7AQiNOUplep4GoXwxSUWK0FjE/qPVpsTTF8rJYwnCzt9pRGUKJq/T1sUhn3J X9+G/kGrHwzLINflpZoODvtvexwjG6r32aHUU= 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=ite0BnSZCeCZfxkMbiSlcrpdS9JhMboT/AqsTOcipR6AwkHQvIRbAJaE2Ycx7TXxrM acVScf7twMnHIhXtHAQdVlXM39I4gB8EfVL/28s+YUudL6Qd6wUZs9I/UmCQ2sipq2Tf MoANeNSMajKt4q7qAP0gALjtI5gIAyTu+Lc3E= MIME-Version: 1.0 Received: by 10.210.137.14 with SMTP id k14mr3099992ebd.95.1249927156107; Mon, 10 Aug 2009 10:59:16 -0700 (PDT) In-Reply-To: References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> From: bert hubert Date: Mon, 10 Aug 2009 19:58:56 +0200 X-Google-Sender-Auth: bef094dbbfddd501 Message-ID: <3efd34cc0908101058o7d51bda5i5af6b8a4556eed59@mail.gmail.com> Subject: Re: [dnsext] NSEC3 confusion (in .org) To: Edward Lewis Cc: "namedroppers@ops.ietf.org 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, Aug 10, 2009 at 7:29 PM, Edward Lewis wrote: > Just to make sure, the "error" is in "powerdnssecc.org" and the www.123.4= 55 > is just a red herring here. The thing I wonder about is how two of the NSEC3s can claim to have an A in its type-set, since .org is 'delegation only'. The rest of your analysis looks sound (thanks), even though I continue to have a very hard time grasping the finer details of NSEC3. Not looking forward to the empty non-terminals bit either. > Does that make sense? =A0NSEC3 #1 says the QNAME isn't here, NSEC3 #2 > identifies the closest encloser (by denying their is a closer name to > QNAME), and NSEC3 #3 reports that there's no source of synthesis. It is all incredibly clever. 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 Aug 11 09:08: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 8CC093A70CD; Tue, 11 Aug 2009 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSKnGADnf4G8; Tue, 11 Aug 2009 09:08:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B4153A70A2; Tue, 11 Aug 2009 09:08:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mato9-000Emp-Tp for namedroppers-data0@psg.com; Tue, 11 Aug 2009 16:02:41 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mato5-000EmN-SJ for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 16:02:39 +0000 Received: by pzk38 with SMTP id 38so4147177pzk.33 for ; Tue, 11 Aug 2009 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2jSVnLy9y+TPrfF3VDRE1p9TpvGsIPc0N9o32odTkFs=; b=izlwq5jCZ5Zmo3Mev9McQUTrQXaa7Dkgx3S3qYSGckAO2MfH116u+aA+fD0PIZWON/ Q+n9P1qmNKbiiHrB/M+LwH+t4N3NX4zWH/BEcLOdgkdpcc6bcW69/UcB/dk0uTuFUH9z 0NoCaGIa6JjyW3J/gemIW2loSwS3JPKU2/az4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ItbNzIIOxffBuGiV+eey5G/x88ggaLtud8skbc4LUf9kU5HymTrpJbhbEjYnuQ6nzG a2ixuhvemed0dz8fk0Nn1nHZvH31KeoJb62xa6d7kUUNizhdyxW+vo6ZgXWHDMJfVqEp rqmL2gfPX3W7ZC1QB4Pro2JPnd22Z+CmLdFjQ= Received: by 10.115.22.14 with SMTP id z14mr8376167wai.130.1250006557269; Tue, 11 Aug 2009 09:02:37 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id d20sm10491639waa.47.2009.08.11.09.02.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 09:02:36 -0700 (PDT) Message-ID: <4A819619.8030008@gmail.com> Date: Tue, 11 Aug 2009 12:02:33 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Rethinking the security too large for UDP problem References: <4A81036F.5030504@gmail.com> In-Reply-To: <4A81036F.5030504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: William Allen Simpson wrote: > I'm already on record elsewhere in support of dnsssec-algo-signal-03, > as that may very well solve most packet too large problems. > > But in the hopefully rare cases, there's simply not enough information > to autonomously make a deterministic decision about the next step. > After sleeping on the idea, I'm pretty sure that we can limit the scope to only those queries that already have the EDNS0. Without it, all implementations will already go directly to TCP -- do not pass Go -- do not collect $200. > What we really need to know: > > 1) The security algorithms supported. Easy. The Algorithm Understood > (AU) option could be passed in the response, with a list of all the > available algorithms. That means the truncation routine should > ensure there's enough room for the option. > It seems reasonable that the EDNS0 response could *always* list the Algorithm Understood (AU) option. It doesn't take much space, and it could be useful even without the DO bit set, to help formulate future queries (indicating that the AU option is understood, *and* security records are available). > 2) The RRTypes of the truncated records. I just don't see how to pass > that in the current protocol. If we knew this, we could just ask > for the rest of the records by type. > Proposing a new TRUNCATED option for DNS0, listing each truncated RRType, and the size of the buffer needed to contain them. As above, the truncation routine should ensure there's enough room for the option. This simple extension could be a really big win, as it could rapidly indicate whether relevant records could be gathered with fewer UDP RTT than TCP (minimum 3 RTT). Each query can have more than one RRType, so it can be estimated for fit. (But, the code might be fairly complex.) > 3) The total size of the untruncated data. Again, I just don't see how > to pass that in the current protocol. If we knew this, we could > decide whether TCP is required, or 2 or 1 should be done instead. > That could be determined by adding the records already received, and the list of others not received (above). > 4) Ideally, the size of the untruncated security data per algorithm. > Probably too hard. If the second UDP request for a desired limited set of algorithms is truncated, 2 RTTs have passed, try TCP instead. > Any ideas? > > I'd consider proposing a generic SIZE RRType for the Additional section to solve #3, that could be cached, and would rapidly indicate whether UDP or TCP should be used for future queries. But then I realized that there has to be a UDP request to get the SIZE. Might as well get real data at the same time, and not waste the round trip. -- to unsubscribe send a message to namedroppers-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 Aug 11 10:19: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 04B4C3A6B0C; Tue, 11 Aug 2009 10:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O69wAJDi2Md; Tue, 11 Aug 2009 10:19:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 957A13A67BE; Tue, 11 Aug 2009 10:18:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MauuS-000O60-OM for namedroppers-data0@psg.com; Tue, 11 Aug 2009 17:13:16 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MauuI-000O3w-BV for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 17:13:13 +0000 Received: by pzk38 with SMTP id 38so4188458pzk.33 for ; Tue, 11 Aug 2009 10:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1YkGuMIS4ao7QyM/APx++/VYK0YDzEX/rkAh96VF4t8=; b=edOe2w1c/z7XN5NATfEg5okhyaV7cycsqZc7TRQktsntLItMct03utzsUBSGCVqv8Z kmOnPmscHXkWHJ+KdJ5UV2tBKGquQuXqjgNvoiJptzlDwl27N9WksPxphyXO18ppr7Jp Fd8ooz/38u3Ya0VUCD2qR/6+U490eEZFc6qLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Spq2/2FDYrJQYHFECbz2cesSL78n7oWm/b5UNEdNCvUFDoMQmc3Bn56eyaJN4ZUNaD I0nEYPHcG0YKVCTCg9T2bZ28r0o9vEamyHplCSlwbVhJfEk/LFBqKMHFf9dItQYhP12Y bOpCD0j3XioTtkVQgB+f9pbXzane5TUB10Dhw= Received: by 10.114.126.1 with SMTP id y1mr8540278wac.91.1250010784958; Tue, 11 Aug 2009 10:13:04 -0700 (PDT) Received: from dotis-mac.local (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) by mx.google.com with ESMTPS id m28sm10714017waf.37.2009.08.11.10.13.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 10:13:03 -0700 (PDT) Message-ID: <4A81A69D.1060103@gmail.com> Date: Tue, 11 Aug 2009 10:13:01 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: William Allen Simpson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> In-Reply-To: <4A808820.7010205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/10/09 1:50 PM, William Allen Simpson wrote: > Doug Otis wrote: >> Additional DNS exchanges based upon EDNS0 options are likely inserted >> by the application or the API which makes control over congestion >> avoidance questionable and the API more complex. > > Goodness gracious, I'd not design it that way -- why would anybody? This viewed DNS as an application using network resources. An EDNS0 page option modifies DNS queries, and requires reassembly of partial DNS responses. Unless a transport is used or developed, a shim layer will be needed between the UDP API and the existing DNS (application). This shim layer will introduce new error states and additional delays. >> DNS data would not be exchanged by the server until receipt of cookie >> ack, just as there would not be any during initialization of TCP >> connections. > > And this is relevant, how? The concern about potential cookie size problems with SCTP have not been found in practice since there is no data contention. ,--- | Yet this is peanuts compared to a specification that from the outset | failed to provide for expected sizes. Upgrading a SCTP implementation | could cause the DNS to fail without warning. The error messages are not | sufficient to deterministically indicate that it's the length of the | "State Cookie" causing the problem. '--- SCTP offers a range of choices in how server resources are protected. Protections required by the server can be implemented in SCTP without impacting interchange. SCTP provides protections not available with standard TCP. An anti-SYN flood strategy, used in TCP, algorithmically constrains initial SYN values to avoid retaining initial values. This uses a 24 bit hash result of a server secret combined with the IP addresses and ports of the client and server combined with 5 bits of time and 8 different MSS selections. This TCP modification represents a weak strategy in comparison to what is normally offered with SCTP. This TCP modification does not support TCP options, and limits MSS values. >> SCTP headers afford a means to directly place data to avoid copying >> and head of queue blocking. A win over TCP. > > And this is relevant, how? When partial pages of DNS responses are returned in separate UDP packets, redundant information is still needed to link response chains, where a new state must track response reassembly. SCTP solves these issues, and defines data locations even for out-of-sequence packets, allowing direct placement as packets are received. This is not a property found with TCP. > I'm not sure it's always true, as the checksum is in the header. And > there's little control of packet alignment crossing user-system > boundaries and task switching. > > But every TCP stack I've implemented (2) has attempted to provide this > feature in the general case of routing between interfaces. Middle boxes prevent an assurance with respect to data alignment within TCP byte streams. SCTP has never been a byte stream and does not suffer this problem. >> When SCTP is not supported, the fallback would be to UDP and then TCP. > > Actually, since SCTP would only be the fallback from UDP, that would only > leave TCP. The goal would be to have SCTP support all DNS traffic and have it attempted first. Delays caused by timeouts due to blocked UDP responses are avoided, as are spoofed reflected attacks. SCTP also better ensures responses are protected from spoofed poisoning. This protection also avoids issuing large responses toward spoofed addresses, either as a set of pages or as large packets. > After you've tried UDP (a 2 RTT timeout), and SCTP (minimum 4 RTT timeout, > but probably with exponential backoff), why exactly are we falling back to > TCP? Won't most applications have already retried another server? UDP and TCP would support legacy clients. Clients that implement SCTP would accommodate separate timeouts and likely track non-support. SCTP's ability to manage persistent associations would reduce overall setup overhead and latency. > We need deterministic error messages to indicate that the > server has to be taken out of the queue, and log it. See RFC 4460. The errata corrected typos and error information. New error types can be defined as it becomes needed in practice, as one has been. Errors due to large cookies have not been a problem. >> SCTP would be affected by anycast in a similar manner to that of TCP. > > No, it's much worse. Anycast TCP is affected by loss of the connection. > SCTP has the same problem, *and* an additional cookie problem. Each server can implement its own resource protection strategy. Only when resource commitments is stored in cookies would there be a need for additional considerations, such as hashing info with secrets. Even 2 additional 32 bit values, combined with a secure hash and a server secret offers protections well beyond what is available with TCP. > At this point, it's obvious to me that I'm speaking to somebody without a > basic understanding of cookies; the concept *requires* secrets and hashes. > > Some years ago, the first time that I'd looked at SCTP, it seemed to me > that cookies were just tacked on, after the original authors were told > that those random 32-bit variables weren't cryptologically significant. > > Now, we've come full circle. Perhaps you could explain the cookie risk related to use with DNS, since it is not apparent. When cookies are used to retain resource commitments, additional considerations are required. SCTP does not define the scheme used. Perhaps you could write a BCP to address the concerns when cookies are used to retain resources. After all, SCTP has not precluded any server protection strategy. >> SCTP does not need to support multi-homing. DNS already provides >> alternative server mechanisms. >> > ??? It's listed as a feature? Unfortunately, to minimize problems caused by SOHO routers for DNS, SCTP multi-homing should be avoided with IPv4. While SCTP supports multi-homing, it would not be appropriate for DNS with IPv4 due to limited support on SOHO equipment. Again, multi-homing is not needed. >> Review sctpConstants.h for a better idea of the application layer. > > What page in the RFC? http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19 > Or how does that relate to options that aren't in the RFC? This was in regard to information available to applications with what might be regarded a reference implementation. >> Verification Tags and TSN permit the tracking of specific exchanges, >> and their response. >> > ??? Random bits? These randomly generated identifiers drive state within the stack. >> When queries are made in bursts (perhaps while obtaining various >> server resolutions related to a specific domain), being able to >> combine several closely spaced transactions into a common association >> will significantly reduce the overall latency. Heartbeat rates can be >> adjusted, and associations can end at any time. Persistence of >> associations might be dictated by use, and resource availability. >> > Nothing in any operating system I'm familiar with works that way. Good news. See page 49 of http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19 section 8.1.8. Automatic Close of Associations (SCTP_AUTOCLOSE) SCTP has automated this type of use. :^) >>> Operationally, this is not a good fit for DNS. >> >> SCTP does offer a good fit. Use of SCTP by DNS will also help SCTP >> support for use with HTTP. At some distant point in time, SOHO routers >> might even be able to handle multi-homing with IPv4. :^) >> > Proof by assertion is not good argument. > > Nor is this list about HTTP. (HTTP over SCTP, shuddering at the thought.) DNS is not the only service needing to become more robust against DDoS. > SOHO routers need to pass EDNS today, not "some distant point in time".... The multi-homing feature of SCTP is not required to support EDNS. At some point, it might become suitable. Avoiding the issuing of large responses to spoofed addresses, or even streams of partial responses to spoofed addresses represents network congestion concerns mitigated through connections or associations. Rather than developing a transport layer within DNS, DNS can instead benefit from the SCTP features aimed at latency sensitive services. It remains doubtful an EDNS0 page feature will adequately mitigate reflected spoof address attacks, or properly deal with DNS induced congestion when abused. Such an effort of extending UDP should be viewed on par with development of a new transport. Investigating SCTP with DNS should not detract from other approaches being considered, but SCTP still warrants review and testing as a possible long term solution. -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 Aug 11 10:40: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 D96983A6AF2; Tue, 11 Aug 2009 10:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 NxIUtFQ+YiEz; Tue, 11 Aug 2009 10:40:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1D6F3A68DA; Tue, 11 Aug 2009 10:40:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MavHK-0000cq-1I for namedroppers-data0@psg.com; Tue, 11 Aug 2009 17:36:54 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MavHG-0000cP-NQ for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 17:36:52 +0000 Received: by pzk38 with SMTP id 38so4201571pzk.33 for ; Tue, 11 Aug 2009 10:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=oWqedjGzNj0zYJcyIkA3p7G2HBV75zQcK3xc1dnVfHs=; b=VRJip7HtFk5TLCkY+qO75UTuFHHpgMeevsAZoEXMip/zZY1tdEd5sLUX8RG0dDUHx1 TDD3b0jgTDT97+e/rQs41wGgbtx8mjtWFMKuf/Vskw8S+C6ji6VwB6iYeZCFCMtSvVp1 LJ3QP0I2MuqAg55mu3XOd3VljnoT9L35oKIy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=aRWllaxFGwwusKUWyEh16VZxT1prUwWYi6O4xDiz4uCcSE6wZyjEyKvSoOKKzmvmeb GsPfnyWn7H0jvAzqZy33udnFUTeyAOgsQ9fCVKkAfSvh+P54YjAH7Fbrhl1f6x6hp7sP k5/fImjFpeEMHdOY4ARV4kJVtuyS+gxIYODwc= Received: by 10.114.210.10 with SMTP id i10mr8473104wag.86.1250012209646; Tue, 11 Aug 2009 10:36:49 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id l37sm10778339waf.40.2009.08.11.10.36.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 10:36:48 -0700 (PDT) Message-ID: <4A81AC2A.60802@gmail.com> Date: Tue, 11 Aug 2009 13:36:42 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] extending the EDNS Algorithm Understood (AU) option Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The current draft already has the language: 2. Signaling Algorithm Understood (AU) Using EDNS ... This document seeks to define a new EDNS0 option for a client to signal which algorithms the client prefers, /and the server to advertise which algorithms are used to sign a particular zone./ The latter doesn't seem to be included, yet! === Therefore, the following friendly amendment is proposed: 4. Server Considerations If the AU option is present but the DNSSEC-OK bit is not set, then the authoritative server does not include any additional DNSSEC RRs in the response. However, the AU option is included in the response, | listing all available algorithms in order of server preference. If | the DNSSEC-OK bit is set, [....] If the zone containing the QNAME is not signed, the authoritative server sends a traditional non-DNSSEC response without an AU option. | If the zone containing the QNAME is signed only with algorithm(s) | that are not present in the client query, [...] generate them. | Unless the response is truncated, no AU option is included, as all | algorithms are known. When the response is truncated, the server must ensure that there is | sufficient space to include the EDNS0 OPT RRType. The AU option is | included in the response, listing all available algorithms in order | of server preference. -- to unsubscribe send a message to namedroppers-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 Aug 11 11: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 514483A6B11; Tue, 11 Aug 2009 11:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=-0.197, 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 76TZcByIRH1p; Tue, 11 Aug 2009 11:50:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E73303A69BA; Tue, 11 Aug 2009 11:50:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MawLM-00091Y-SQ for namedroppers-data0@psg.com; Tue, 11 Aug 2009 18:45:08 +0000 Received: from [209.85.200.171] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MawLI-00090R-DU for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 18:45:07 +0000 Received: by wf-out-1314.google.com with SMTP id 29so1711472wff.32 for ; Tue, 11 Aug 2009 11:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=w5SU8VuGR6RXDXuR9FecPBH8l6S6v5y7QKaSFC0LJJs=; b=rNb2jfRTxpPUNcgJLNK3ao5ti6KU0izPDIziT+kcP+7Bq7Tl4pIMISEQCVcfECJzQZ puRMaRE1vB1cQiiZZ8Zst60W1n+TQKiiWKWsVb3hlOELX7dt6fDXgmnUtPH+mJFVmCp2 LoqKaoksnshDWz/CQAbYHAG/fixmLEinGyD14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Buf1NlqsSYnHeBlpcOltSD4xkKfvy2gqZmc1Ka8CCyDAgpvZV31besYkBLc41GA2JM I3pAytf9WJleT1ijtZkMzS5XUQ5+DjKk0+9K8LCPwQYcAoPdgsmkYsbXJsVJHfMm4tA0 566Cj69ZjkSbgsphZI3PnUS3q9Vj7nyn3k+kw= Received: by 10.142.49.2 with SMTP id w2mr378099wfw.321.1250016303701; Tue, 11 Aug 2009 11:45:03 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 28sm17472485wfd.4.2009.08.11.11.45.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 11:45:02 -0700 (PDT) Message-ID: <4A81BC2B.1040104@gmail.com> Date: Tue, 11 Aug 2009 14:44:59 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> <4A81A69D.1060103@gmail.com> In-Reply-To: <4A81A69D.1060103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Doug Otis wrote: > On 8/10/09 1:50 PM, William Allen Simpson wrote: >> Goodness gracious, I'd not design it that way -- why would anybody? > > This viewed DNS as an application using network resources. An EDNS0 > page option modifies DNS queries, and requires reassembly of partial DNS > responses. > > Unless a transport is used or developed, a shim layer will be needed > between the UDP API and the existing DNS (application). This shim layer > will introduce new error states and additional delays. > I'm tired of strawman arguments. There is no "EDNS0 page option". After my previous query, somebody kindly pointed me at the earlier discussion, where my mail handler showed me that I'd read the first 2 posts in the thread and ignored it thereafter. > The concern about potential cookie size problems with SCTP have not been > found in practice since there is no data contention. ??? Are you saying it hasn't been found in practice because it hasn't been implemented? Or that you have no data? > ,--- > | Yet this is peanuts compared to a specification that from the outset > | failed to provide for expected sizes. Upgrading a SCTP implementation > | could cause the DNS to fail without warning. The error messages are not > | sufficient to deterministically indicate that it's the length of the > | "State Cookie" causing the problem. > '--- > > SCTP offers a range of choices in how server resources are protected. > Protections required by the server can be implemented in SCTP without > impacting interchange. SCTP provides protections not available with > standard TCP. > Your answer to a specific technical problem reads like a propaganda brochure; content free and hand-waving. >>> SCTP headers afford a means to directly place data to avoid copying >>> and head of queue blocking. A win over TCP. >> >> And this is relevant, how? > > When partial pages of DNS responses are returned in separate UDP > packets, redundant information is still needed to link response chains, > where a new state must track response reassembly. SCTP solves these > issues, and defines data locations even for out-of-sequence packets, > allowing direct placement as packets are received. This is not a > property found with TCP. > What partial pages? What data locations? Are you talking about a particular implementation of SCTP and/or TCP? Certainly, there's nothing in the SCTP specification itself.... And it appears that you misused the term of art, head of queue blocking. It has nothing to do with TCP or transport (it's about switching queues of packets). Or some other group has misappropriated the terminology that we've long used in the network routing field. >> I'm not sure it's always true, as the checksum is in the header. And >> there's little control of packet alignment crossing user-system >> boundaries and task switching. > > >> But every TCP stack I've implemented (2) has attempted to provide this >> feature in the general case of routing between interfaces. > > Middle boxes prevent an assurance with respect to data alignment within > TCP byte streams. SCTP has never been a byte stream and does not suffer > this problem. > What middle boxes? I've yet to see a box between my user application space and my kernel network space, or between two routable interfaces. Enough hand-waving. Specify the manufacturer and the network. Show your work. >>> When SCTP is not supported, the fallback would be to UDP and then TCP. >> >> Actually, since SCTP would only be the fallback from UDP, that would only >> leave TCP. > > The goal would be to have SCTP support all DNS traffic and have it > attempted first. I think we've just arrived at over my dead body.... [remainder of message elided] We in the networking and security world have been waiting for widespread deployment of a workable DNSsec for many, many years. It finally seems within reach, and that got me interested here again. It should work through many/most IPv4 SOHO boxen. SCTP does not. Looks to me like a badly designed solution looking for 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 Aug 11 15:37: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 641043A6B28; Tue, 11 Aug 2009 15:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=1.024, 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 e7szkOr1FfG7; Tue, 11 Aug 2009 15:37:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F7B53A6884; Tue, 11 Aug 2009 15:37:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MazsZ-000Avf-GL for namedroppers-data0@psg.com; Tue, 11 Aug 2009 22:31:39 +0000 Received: from [204.152.187.111] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mazre-000ArQ-3N for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 22:30:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 977E5AC752; Tue, 11 Aug 2009 22:30:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: William Allen Simpson cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Tue, 11 Aug 2009 10:17:18 -0400." <4A817D6E.9040202@gmail.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 11 Aug 2009 22:30:11 +0000 Message-ID: <87474.1250029811@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 11 Aug 2009 10:17:18 -0400 > From: William Allen Simpson > > The proposal, as I remember it circa 1996, was to add an explicit Cookie > option (128-bit cookie) to the original SYN, signaling to the responder > that no TCB was necessary. this sounds really quite nice. is it dead? > One of the counter arguments at the time was that a robust IPv6 and IPsec > would render this entirely unnecessary. Admittedly, at the time I was > part of that chorus. In retrospect, I was wrong. "toldja so!" :-) > Anyway, given the general conservative nature of TCP deployment, it would > be better to work on methods for DNS to use UDP efficiently. a horrific number of badly implemented middleboxes think UDP/53 is fair game and thus rewrite messages according to policy. given that most messages do not get rewritten, this should not be a problem, but it is, since these badly implemented middleboxes make the single-packet assumption (no fragmentation). udp datagrams that are fragmented into multiple ip packets don't have udp headers or udp port numbers except in the first ip fragment. so these badly implemented middleboxes either drop all the fragments, or pass the first one and block the rest of them. none of us consider these badly implemented middleboxes to be repairable since they are all over the internet now and many of their manufacturers are out of business and many of their original installers/operators are retired or dead. so, the burden is back on the endpoints, to use a protocol that no badly implemented middleboxes are looking at. at the moment, endpoints don't get a reliable indication that edns0 with large datagrams won't work, since the symptom of brokenness tends to be a timeout, which is ambiguous. udp is not fragmentation-aware in the way that tcp is. tcp can set DF and wait for ICMP to tell it to use smaller segments. udp has no segmentation since it relies on ip's fragmentation, which as i mentioned above, doesn't work reliably and more importantly doesn't fail reliably. t/tcp is dead. sctp sounds like it remains unborn. what i worry about in what you say about bernstein's tcp cookie proposal is that we might not get reliable failure indication, other than timeouts, which are ambiguous. a fragmentation-aware udp-like protocol with session state based on cookies, that had its own ip protocol number, is starting to seem like a good idea. when it doesn't work it'll be unambiguous -- even a timeout is unambiguous if the protocol number is neither tcp nor udp... a timeout means this new protocol isn't going to work and that some kind of fallback (like udp/53 or tcp/53 or a VPN) should be used. i had thought sctp was possibly going to be that protocol but i guess not? -- to unsubscribe send a message to namedroppers-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 Aug 11 16:09: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 5AF233A6B89; Tue, 11 Aug 2009 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-0.825, 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 G7pZudvXpnFd; Tue, 11 Aug 2009 16:09:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB7103A691E; Tue, 11 Aug 2009 16:08:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb0OZ-000E6d-BW for namedroppers-data0@psg.com; Tue, 11 Aug 2009 23:04:43 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb0OR-000E5u-LB for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 23:04:41 +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]:34289) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1Mb0OQ-0003VZ-HJ (Exim 4.70) (return-path ); Wed, 12 Aug 2009 00:04:34 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Mb0OQ-0007hz-BI (Exim 4.67) (return-path ); Wed, 12 Aug 2009 00:04:34 +0100 Date: Wed, 12 Aug 2009 00:04:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: William Allen Simpson cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: <4A817D6E.9040202@gmail.com> Message-ID: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 11 Aug 2009, William Allen Simpson wrote: > > It seems strange to me that this wasn't already specified, as I remember > discussion back in the mid-90s. It also seems strange that it took 10+ > years for Bernstein's clever (small) SYN cookies hack to be documented in > the RFC series (RFC-4987). > > Apparently, the TCP community is even more conservative than the DNS > community in making changes.... TCP RFCs are often waaay behind deployment. See VJ congestion control for a major example. 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 Tue Aug 11 16: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 509493A67F8; Tue, 11 Aug 2009 16:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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 hOOo3cs6zo1f; Tue, 11 Aug 2009 16:55:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 42E893A6914; Tue, 11 Aug 2009 16:55:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb16y-000ICZ-6B for namedroppers-data0@psg.com; Tue, 11 Aug 2009 23:50: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 1Mb16t-000ICA-Rd for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 23:50: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 A8FB3E609B; Tue, 11 Aug 2009 23:50:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7BNoSY7089617; Wed, 12 Aug 2009 09:50:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908112350.n7BNoSY7089617@drugs.dv.isc.org> To: Paul Vixie Cc: William Allen Simpson , namedroppers@ops.ietf.org From: Mark Andrews References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-reply-to: Your message of "Tue, 11 Aug 2009 22:30:11 GMT." <87474.1250029811@nsa.vix.com> Date: Wed, 12 Aug 2009 09:50:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <87474.1250029811@nsa.vix.com>, Paul Vixie writes: > > Date: Tue, 11 Aug 2009 10:17:18 -0400 > > From: William Allen Simpson > > > > The proposal, as I remember it circa 1996, was to add an explicit Cookie > > option (128-bit cookie) to the original SYN, signaling to the responder > > that no TCB was necessary. > > this sounds really quite nice. is it dead? > > > One of the counter arguments at the time was that a robust IPv6 and IPsec > > would render this entirely unnecessary. Admittedly, at the time I was > > part of that chorus. In retrospect, I was wrong. > > "toldja so!" :-) > > > Anyway, given the general conservative nature of TCP deployment, it would > > be better to work on methods for DNS to use UDP efficiently. > > a horrific number of badly implemented middleboxes think UDP/53 is fair game > and thus rewrite messages according to policy. given that most messages do > not get rewritten, this should not be a problem, but it is, since these badly > implemented middleboxes make the single-packet assumption (no fragmentation). > > udp datagrams that are fragmented into multiple ip packets don't have udp > headers or udp port numbers except in the first ip fragment. so these badly > implemented middleboxes either drop all the fragments, or pass the first one > and block the rest of them. > > none of us consider these badly implemented middleboxes to be repairable sinc > e > they are all over the internet now and many of their manufacturers are out of > business and many of their original installers/operators are retired or dead. We don't need to repair them. The net can cope with the what is already out there. We just need to make sure new boxes being installed are not defective in particular all the IPv6 capable CPE equipement that will need to start rolling out the door in the next couple of years. That means doing the hop-by-hop processing that is in the DNS if you advertise yourself as a nameserver rather than forwarding the packet and hoping that it is ok. We know EDNS UDP sizes in the forwarded packets, both request and reply, may need to be reduced to reflect the actual buffer sizes in the CPE equipment. DO should be able to be passed through, similarly AD and CD. The client advertises a 4096 byte EDNS UDP size option, the CPE the advertises a 1460 byte EDNS UDP size option when it "forwards" the packet. The reply with a 4096 byte EDNS UDP size will then be able to be processed by the CPE equipment, when the reply is forwarded to the original client the CPE will put the miniumum of the received EDNS UDP size and its buffer size in the EDNS UDP size returned to the original client. The problem with CPE equipement is that it pretends to be a DNS server without fulfilling enough of the requirements of a DNS server. 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 Aug 11 16:58: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 2C6113A67F8; Tue, 11 Aug 2009 16:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 Fx4LIsavh9Uc; Tue, 11 Aug 2009 16:58:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 255FF3A6A2A; Tue, 11 Aug 2009 16:58:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb1BX-000Icm-OC for namedroppers-data0@psg.com; Tue, 11 Aug 2009 23:55:19 +0000 Received: from [209.85.211.188] (helo=mail-yw0-f188.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb1BT-000IcN-W3 for namedroppers@ops.ietf.org; Tue, 11 Aug 2009 23:55:18 +0000 Received: by ywh26 with SMTP id 26so5514625ywh.5 for ; Tue, 11 Aug 2009 16:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=FVhiyxhUYTAgC8ifYF5QpKHGApOCc1NCm9MlW8mQHVo=; b=b6tB3TmbbJO9W/m14Cfi+zxnTrm80kc0a91dBs4I07Vjr0cDK95sT5Pelqz7g1hLDR TTilGgIaUbHgPU5QROpVMFSiEp5HP94yKnbpvR8WtntVS7BtCFLM684udSEMOQ3o53wb f8GxsPx+6Be3eNrnf1cya4efm8MvsWLx7ZVeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=l02WlV/UaJq5lgQscA9NjQv0ojCEBDvboOQXLF1T2/lEpcK2Vuyu/gFnaaSAYSlHwN u085gtRX9+6KUC1XjiSBKgF4Fc3Zc5T2CHOvhURhejiDArbbfDeOoQawmuRoH6XyRNLk 6/00NKWcoim897NhnAbtVByzIUb/8T7pOOtO8= Received: by 10.91.102.6 with SMTP id e6mr251016agm.99.1250034914654; Tue, 11 Aug 2009 16:55:14 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 36sm1195819agc.20.2009.08.11.16.55.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 16:55:13 -0700 (PDT) Message-ID: <4A8204E0.4020601@gmail.com> Date: Tue, 11 Aug 2009 19:55:12 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> In-Reply-To: <87474.1250029811@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> Date: Tue, 11 Aug 2009 10:17:18 -0400 >> From: William Allen Simpson >> >> The proposal, as I remember it circa 1996, was to add an explicit Cookie >> option (128-bit cookie) to the original SYN, signaling to the responder >> that no TCB was necessary. > > this sounds really quite nice. is it dead? > I'd have to ask on the good old end2end-interest list. Do we know enough server developers? >> One of the counter arguments at the time was that a robust IPv6 and IPsec >> would render this entirely unnecessary. Admittedly, at the time I was >> part of that chorus. In retrospect, I was wrong. > > "toldja so!" :-) > Well, the old grey IETF, she ain't what she used to be.... >> Anyway, given the general conservative nature of TCP deployment, it would >> be better to work on methods for DNS to use UDP efficiently. > > a horrific number of badly implemented middleboxes think UDP/53 is fair game > and thus rewrite messages according to policy. [...] > > so, the burden is back on the endpoints, to use a protocol that no badly > implemented middleboxes are looking at. at the moment, endpoints don't get > a reliable indication that edns0 with large datagrams won't work, since the > symptom of brokenness tends to be a timeout, which is ambiguous. > Most of what you mentioned above has all been discussed at the meetings for years. I'd thought/hoped that the edns0 with a size of 1420 was working, and the IANA signed root tests for the past year had worked well? > ... > t/tcp is dead. sctp sounds like it remains unborn. what i worry about in > what you say about bernstein's tcp cookie proposal is that we might not get > reliable failure indication, other than timeouts, which are ambiguous. > And doesn't happen in any case until the box is under attack, so it doesn't get tested often enough. Still, it was clever and helped at a bad time. > a fragmentation-aware udp-like protocol with session state based on > cookies, that had its own ip protocol number, is starting to seem like a > good idea. when it doesn't work it'll be unambiguous -- even a timeout is > unambiguous if the protocol number is neither tcp nor udp... a timeout > means this new protocol isn't going to work and that some kind of fallback > (like udp/53 or tcp/53 or a VPN) should be used. > > i had thought sctp was possibly going to be that protocol but i guess not? > Besides the various problems with SCTP, there's the major one that only UDP and TCP get through most IPv4 NAT routers. Anyway, send me a private message with a phone and a time, and I'll call. -- to unsubscribe send a message to namedroppers-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 Aug 11 17:34: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 E770F3A66B4; Tue, 11 Aug 2009 17:34:53 -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 c2o0k-dwlnbc; Tue, 11 Aug 2009 17:34:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90F543A6879; Tue, 11 Aug 2009 17:34:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb1jP-000MSe-TJ for namedroppers-data0@psg.com; Wed, 12 Aug 2009 00:30: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 1Mb1jM-000MSL-6N for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 00:30:17 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D426BAC743 for ; Wed, 12 Aug 2009 00:30:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Tue, 11 Aug 2009 19:55:12 -0400." <4A8204E0.4020601@gmail.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <4A8204E0.4020601@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 12 Aug 2009 00:30:15 +0000 Message-ID: <92210.1250037015@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 11 Aug 2009 19:55:12 -0400 > From: William Allen Simpson > > Most of what you mentioned above has all been discussed at the meetings > for years. I'd thought/hoped that the edns0 with a size of 1420 was > working, and the IANA signed root tests for the past year had worked > well? i don't think of 1420 as working, nor do i think of 1420 as enough, nor do i think of dnssec metadata as the only thing that makes or can make or will make common/frequent dns messages exceed PMTU or that root zone signature sizes are the only signatures we need to test. so, "mumble." > > a fragmentation-aware udp-like protocol with session state based on > > cookies, that had its own ip protocol number, is starting to seem like > > a good idea. when it doesn't work it'll be unambiguous -- even a > > timeout is unambiguous if the protocol number is neither tcp nor > > udp... a timeout means this new protocol isn't going to work and that > > some kind of fallback (like udp/53 or tcp/53 or a VPN) should be used. > > > > i had thought sctp was possibly going to be that protocol but i guess not? > > Besides the various problems with SCTP, there's the major one that only UDP > and TCP get through most IPv4 NAT routers. that's a good thing and i'm counting on it. we need a reliable unambiguous indicator that fallback should be tried. trying to get through a middlebox that doesn't understand a new transport protocol at all, fits the bill. > Anyway, send me a private message with a phone and a time, and I'll call. on 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 Tue Aug 11 17: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 1AA3F3A66B4; Tue, 11 Aug 2009 17:41:24 -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 2WWQiDzAu7Sw; Tue, 11 Aug 2009 17:41:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7355D3A6768; Tue, 11 Aug 2009 17:41:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb1qs-000NYl-4J for namedroppers-data0@psg.com; Wed, 12 Aug 2009 00:38:02 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb1qo-000NYN-AL for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 00:37:59 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 15DE0741545; Tue, 11 Aug 2009 17:37:58 -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 VCIIk3nALu2i; Tue, 11 Aug 2009 17:37:54 -0700 (PDT) Received: from wlan39-188.mdr.icann.org (wlan39-188.mdr.icann.org [192.0.39.188]) by virtualized.org (Postfix) with ESMTP id 6F25F741518; Tue, 11 Aug 2009 17:37:54 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <6F36FE86-A01E-47FF-865C-F9E2705030F5@virtualized.org> From: David Conrad To: William Allen Simpson In-Reply-To: <4A8204E0.4020601@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Tue, 11 Aug 2009 17:37:53 -0700 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <4A8204E0.4020601@gmail.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 11, 2009, at 4:55 PM, William Allen Simpson wrote: > Most of what you mentioned above has all been discussed at the > meetings > for years. I'd thought/hoped that the edns0 with a size of 1420 was > working, and the IANA signed root tests for the past year had worked > well? Unfortunately, the IANA testbed doesn't generally see resolver-side failures. We did (or rather we hired OARC to) do some testing related to L root server and discovered that BIND's retry with a buffer size of 512 bytes with DO=1 (arguably in violation of 3226) significantly increases the fallback to TCP (since a signed NXDOMAIN is bigger than 512 bytes), but that's different. 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 Aug 11 19:39: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 52ACE3A67E6; Tue, 11 Aug 2009 19:39:54 -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 1nuJVz60yz0I; Tue, 11 Aug 2009 19:39:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACC803A67A3; Tue, 11 Aug 2009 19:39:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb3dZ-000AAW-Fv for namedroppers-data0@psg.com; Wed, 12 Aug 2009 02:32:25 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb3dV-000AA5-LT for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 02:32:23 +0000 Received: by pzk38 with SMTP id 38so4453900pzk.33 for ; Tue, 11 Aug 2009 19:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=sBArvstBX6iXOR6MoUHG0tv+5doM+oWDAsiAa1QnTWY=; b=tiChZk2vhAodG5JsVnK328VGmDMOH8ZxmeUvFAlxOgyGlu1ZSOYuNuKnglidKqYgtl 1flX4woBhXy64EYt1LLPsLHtQEDTs3zV6WF+/YEFZq0H34ysiP7lJwIUMzbMtDWlhr3V n/4wCEsO9cqelY+3W5M9Wl9roJOVWvfyjlbQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jLE64e7toL4ABZWvXZEz6sQZCFf2qKLhhxWm0DADOqQ0qjx/x/F117j50ruhAhkpzd kVN4xtOIOT/WgXLszASkCEno+QTxbaV7pxx1TOY/Lu9bn7CbcbTSK4Kn7hkXSgEDg9CT T+7TtT90ZkJFeWdW3ZAQ9xXhajmV8N2PQfRms= Received: by 10.115.59.2 with SMTP id m2mr2559304wak.214.1250044340404; Tue, 11 Aug 2009 19:32:20 -0700 (PDT) Received: from SJC-Office-NAT-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id m6sm11781531wag.33.2009.08.11.19.32.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Aug 2009 19:32:19 -0700 (PDT) Message-ID: <4A8229B0.2010400@gmail.com> Date: Tue, 11 Aug 2009 19:32:16 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: William Allen Simpson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> <4A81A69D.1060103@gmail.com> <4A81BC2B.1040104@gmail.com> In-Reply-To: <4A81BC2B.1040104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/11/09 11:44 AM, William Allen Simpson wrote: > Doug Otis wrote: >> On 8/10/09 1:50 PM, William Allen Simpson wrote: >> >> Unless a transport is used or developed, a shim layer will be >> needed between the UDP API and the existing DNS (application). This >> shim layer will introduce new error states and additional delays. > > I'm tired of strawman arguments. There is no "EDNS0 page option". > After my previous query, somebody kindly pointed me at the earlier > discussion, where my mail handler showed me that I'd read the first 2 > posts in the thread and ignored it thereafter. Okay, this leaves fragmented UDP that may not work in many cases, where even trying might lead to DDoS concerns, or TCP with its higher associated overhead, when compared to persistent SCTP. >> The concern about potential cookie size problems with SCTP have not >> been found in practice since there is no data contention. > > ??? Are you saying it hasn't been found in practice because it > hasn't been implemented? Or that you have no data? There are documented concerns within the specification, while there have also been years of use without this being an issue. Exceeding the PMTU, in this case, is not likely due to the size of the cookie state (which is conveyed to the client), but due to an inordinate number of multi-home parameter lists options. A blundering application would then see a timeout when the server does not receive a fragmented packet. Defining error values exchanged within the transport would be paradoxical, since the transport failed to initialize. It seems easier to be careful and pay attention to the API variables and chunk sizes. IMHO, initial plans at using SCTP should not employ the multi-homing feature. >> SCTP offers a range of choices in how server resources are >> protected. Protections required by the server can be implemented in >> SCTP without impacting interchange. SCTP provides protections not >> available with standard TCP. >> > Your answer to a specific technical problem reads like a propaganda > brochure; content free and hand-waving. Sorry. You are right. I should have been more specific. Section 5.1.3 of RFC 4690 provides a good overview of what is expected to be in the cookie state. Do you see anything wrong with this section? > What partial pages? What data locations? Are you talking about a > particular implementation of SCTP and/or TCP? Certainly, there's > nothing in the SCTP specification itself.... This was in response to the suggestion I thought you endorsed regarding the EDNS0 page mode. > And it appears that you misused the term of art, head of queue > blocking. It has nothing to do with TCP or transport (it's about > switching queues of packets). Or some other group has misappropriated > the terminology that we've long used in the network routing field. Sorry, the blocking caused by TCP's byte stream dependence upon ordered delivery. What is a good term for this? SCTP offers unordered delivery of framed data chunks. >> The goal would be to have SCTP support all DNS traffic and have it >> attempted first. Delays caused by timeouts due to blocked UDP >> responses are avoided, as are spoofed reflected attacks. SCTP also >> better ensures responses are protected from spoofed poisoning. >> >> This protection also avoids issuing large responses toward spoofed >> addresses, either as a set of pages or as large packets. > > I think we've just arrived at over my dead body.... You provided a good review of problems facing SCTP. IMHO, these are not fatal, nor does everything need to transition to SCTP immediately and work for everyone. How would you view SCTP if it proved to provide lower latency, and greater reliability for enterprise and ISP uses. What would you say if SCTP avoid risks related to the high levels of amplification created by jumbo packet UDP responses? > [remainder of message elided] > > We in the networking and security world have been waiting for > widespread deployment of a workable DNSsec for many, many years. It > finally seems within reach, and that got me interested here again. > > It should work through many/most IPv4 SOHO boxen. SCTP does not. While I understand this view, having an alternative ready when problems occur does not seem to be a bad approach. There remains the fallbacks where those working over broken legacy equipment might suffer some degraded service. > Looks to me like a badly designed solution looking for a problem. While it is not perfect, persistent associations and the ability to frame separate DNS messages offers unappreciated advantages and quick integration with DNS. Perhaps you are now viewing the solution as using UDP jumbo frames. IMHO, this would be a problem looking for victims. :^( -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 Aug 11 22:11: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 D2A673A68D5; Tue, 11 Aug 2009 22:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 ihYL86TMEh6L; Tue, 11 Aug 2009 22:11:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B0B03A6855; Tue, 11 Aug 2009 22:11:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb627-0000xF-7R for namedroppers-data0@psg.com; Wed, 12 Aug 2009 05:05:55 +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 1Mb621-0000wd-BD for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 05:05:51 +0000 Received: from dul1mcmlarson-l1-2.local (localhost.localdomain [127.0.0.1]) by mail.kahlerlarson.org (Postfix) with ESMTP id 36AB737CE5 for ; Wed, 12 Aug 2009 01:05:47 -0400 (EDT) Date: Wed, 12 Aug 2009 01:05:46 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: Re: [dnsext] NSEC3 confusion (in .org) Message-ID: <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> <200908110010.n7B0AvDR060945@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908110010.n7B0AvDR060945@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 11 Aug 2009, Mark Andrews wrote: > In message <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com>, bert hubert writes: > > When I query .org for a non-existent delegation, I get three NSEC3's > > returned. Wouter Wijngaards helped me understand why three are > > required (thanks!), but what I don't get is how two of these three > > NSEC records appear to start from an A RRSET. As far as I know, there > > are no non-glue A records in ORG? > > No. Just your assumption is false. NS RRsets are removed > by registrars without the glue records beneath them also > being removed for spam and other network abuse issues. This > causes the glue to become authoritative data. > > The same thing happens in COM, NET and I presume all other > zones with a registry/registrar model. The registrars > really should be pulling the glue records as well. It's > up to the registry enforce this however. That is not correct. At least in .com and .net, the registry business logic prevents a domain from being deleted if name servers (i.e., host objects in the registry database that result in glue A or AAAA RRs in the zone) under that domain still exist. E.g., a registrar must first delete the name server "ns.foo.com" before deleting the domain "foo.com". Authoritative A and AAAA records do appear in .com/.net, however, when a domain goes on a hold status (there are various kinds), which causes the domain's NS RRs to be removed from the zone. In this case, any name servers (A and AAAA RRs) below it are not removed. Since they are now no longer below a delegation, they become authoritative data. Note that this behavior is changing soon for DNSSEC reasons: in the future, when a domain goes on hold, all A/AAAA RRs below it will be removed along with the NS RRs for the duration of the hold status. This change obviates the need to sign what would then become authoritatve data and, in my opinion, conforms better with the principle of least astonishment. I can't speak for .org's business logic, so I don't know under what circumstances authoritative A/AAAA RRs appear in that zone. 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 Aug 11 22:41: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 8789C3A6B23; Tue, 11 Aug 2009 22:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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 yvkP0ZwzK0uT; Tue, 11 Aug 2009 22:41:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06B5D3A692A; Tue, 11 Aug 2009 22:41:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb6VY-0004Bf-Mq for namedroppers-data0@psg.com; Wed, 12 Aug 2009 05:36:20 +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 1Mb6VQ-0004BC-2S for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 05:36:16 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 24D04E609A; Wed, 12 Aug 2009 05:36: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 n7C5a79k091897; Wed, 12 Aug 2009 15:36:08 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908120536.n7C5a79k091897@drugs.dv.isc.org> To: Matt Larson Cc: Namedroppers Mailing List From: Mark Andrews References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> <200908110010.n7B0AvDR060945@drugs.dv.isc.org> <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> Subject: Re: [dnsext] NSEC3 confusion (in .org) In-reply-to: Your message of "Wed, 12 Aug 2009 01:05:46 -0400." <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> Date: Wed, 12 Aug 2009 15:36:07 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090812050546.GJ1348@dul1mcmlarson-l1-2.local>, Matt Larson writes : > On Tue, 11 Aug 2009, Mark Andrews wrote: > > In message <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com>, b > ert hubert writes: > > > When I query .org for a non-existent delegation, I get three NSEC3's > > > returned. Wouter Wijngaards helped me understand why three are > > > required (thanks!), but what I don't get is how two of these three > > > NSEC records appear to start from an A RRSET. As far as I know, there > > > are no non-glue A records in ORG? > > > > No. Just your assumption is false. NS RRsets are removed > > by registrars without the glue records beneath them also > > being removed for spam and other network abuse issues. This > > causes the glue to become authoritative data. > > > > The same thing happens in COM, NET and I presume all other > > zones with a registry/registrar model. The registrars > > really should be pulling the glue records as well. It's > > up to the registry enforce this however. > > That is not correct. At least in .com and .net, the registry business > logic prevents a domain from being deleted if name servers (i.e., host > objects in the registry database that result in glue A or AAAA RRs in > the zone) under that domain still exist. E.g., a registrar must first > delete the name server "ns.foo.com" before deleting the domain > "foo.com". I wasn't talking about a delegation being deleted. Note I qualified the removal based on "spam and other network abuse issues". > Authoritative A and AAAA records do appear in .com/.net, however, when > a domain goes on a hold status (there are various kinds), including spam and other network abuse issues > which causes > the domain's NS RRs to be removed from the zone. In this case, any > name servers (A and AAAA RRs) below it are not removed. Since they > are now no longer below a delegation, they become authoritative data. We both said the same thing. The NS RRsets is pulled from the zone without the glue records being pulled. > Note that this behavior is changing soon for DNSSEC reasons: in the > future, when a domain goes on hold, all A/AAAA RRs below it will be > removed along with the NS RRs for the duration of the hold status. > This change obviates the need to sign what would then become > authoritatve data and, in my opinion, conforms better with the > principle of least astonishment. Agreed. > I can't speak for .org's business logic, so I don't know under what > circumstances authoritative A/AAAA RRs appear in that zone. > > 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 Tue Aug 11 23: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 7FB0C3A68BE; Tue, 11 Aug 2009 23:15:14 -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 S5Ep2THXjee6; Tue, 11 Aug 2009 23:15:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 103483A67F6; Tue, 11 Aug 2009 23:15:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb72J-0007gX-55 for namedroppers-data0@psg.com; Wed, 12 Aug 2009 06:10:11 +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 1Mb72E-0007ev-P8 for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 06:10:08 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5DE91AC7E8 for ; Wed, 12 Aug 2009 06:10:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Namedroppers Mailing List Subject: Re: [dnsext] NSEC3 confusion (in .org) In-Reply-To: Your message of "Wed, 12 Aug 2009 01:05:46 -0400." <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> <200908110010.n7B0AvDR060945@drugs.dv.isc.org> <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 12 Aug 2009 06:10:06 +0000 Message-ID: <6146.1250057406@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Wed, 12 Aug 2009 01:05:46 -0400 > From: Matt Larson > ... > Note that this behavior is changing soon for DNSSEC reasons: in the > future, when a domain goes on hold, all A/AAAA RRs below it will be > removed along with the NS RRs for the duration of the hold status. This > change obviates the need to sign what would then become authoritatve data > and, in my opinion, conforms better with the principle of least > astonishment. so if VIX.COM goes on hold then NS-EXT.VIX.COM's A RR will no longer be queriable at the COM servers even if other zone cuts (either under COM or elsewhere including TLD zone cuts in the root zone) still reference 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 Tue Aug 11 23:34: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 DF8CE3A6801; Tue, 11 Aug 2009 23:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLYdUn7sJrWT; Tue, 11 Aug 2009 23:34:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AE033A67D8; Tue, 11 Aug 2009 23:34:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb7Mc-000ANv-9b for namedroppers-data0@psg.com; Wed, 12 Aug 2009 06:31: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 1Mb7MY-000ANS-TI for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 06:31:08 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 96648AC7F0 for ; Wed, 12 Aug 2009 06:31:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice In-Reply-To: Your message of "Mon, 10 Aug 2009 14:21:42 MST." References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 12 Aug 2009 06:31:06 +0000 Message-ID: <6969.1250058666@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Nicholas Weaver > Date: Mon, 10 Aug 2009 14:21:42 -0700 > > Stupid question: > > This is intended primarily as a fallback position for those EDNS0 capable > resolvers who find themselves behind a middlebox which blocks either > EDNS0 responses, responses >512B or fragmented responses, correct? incorrect. whatever transport we add should be the first one tried, with existing transports pushed down (just as edns pushed down non-edns.) > What suggestion is there that for such a middlebox will allow SCTP > unmolested without needing it to be tunneled over UDP? none. but when it doesn't work, the failure is unambiguous, which is 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 Tue Aug 11 23:58: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 A52A63A6AE1; Tue, 11 Aug 2009 23:58:48 -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 xcxQYkfnnkh6; Tue, 11 Aug 2009 23:58:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C17143A6A78; Tue, 11 Aug 2009 23:58:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb7iG-000CiX-4G for namedroppers-data0@psg.com; Wed, 12 Aug 2009 06:53:32 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb7iB-000Chs-84 for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 06:53:29 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 62319C2DA3; Wed, 12 Aug 2009 07:53:25 +0100 (BST) Date: Wed, 12 Aug 2009 07:54:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , William Allen Simpson cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Message-ID: <1B6540C99B25F4995938FACE@nimrod.local> In-Reply-To: <87474.1250029811@nsa.vix.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 11 August 2009 22:30:11 +0000 Paul Vixie wrote: > a horrific number of badly implemented middleboxes think UDP/53 is fair > game and thus rewrite messages according to policy. This suggests another fallback policy: fall back to (e.g.) UDP/54 (yes, I know that's XNS Clearinghouse or something, but I'm sure we can find another well known port number). The spec for this port would be "DNS that's not broken" (i.e. EDNS0 support compulsory, "MUST NOT" on interfering middleboxen, etc.). Any middlebox is going to do one of three things: pass the packets through verbatim (fine), drop the packets entirely (in which case SCTP etc. would be unlikely to get through either), or drop only fragments (still a problem). What they wouldn't do is pretend to be a UDP/54 DNS server when they aren't, or mangle the packets. -- 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 Aug 12 00:07: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 5E98D3A6AAE; Wed, 12 Aug 2009 00:07: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=[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 Z+zUDnCZQ8gm; Wed, 12 Aug 2009 00:07:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF6813A63D3; Wed, 12 Aug 2009 00:07:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb7sB-000DqD-RX for namedroppers-data0@psg.com; Wed, 12 Aug 2009 07:03: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 1Mb7s8-000Dpj-47 for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 07:03:45 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D896FAC7FD for ; Wed, 12 Aug 2009 07:03:43 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Wed, 12 Aug 2009 09:50:28 +1000." <200908112350.n7BNoSY7089617@drugs.dv.isc.org> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <200908112350.n7BNoSY7089617@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 12 Aug 2009 07:03:43 +0000 Message-ID: <8207.1250060623@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Wed, 12 Aug 2009 09:50:28 +1000 > ... > > none of us consider these badly implemented middleboxes to be > > repairable since they are all over the internet now and many of their > > manufacturers are out of business and many of their original > > installers/operators are retired or dead. > > We don't need to repair them. The net can cope with the what is already > out there. We just need to make sure new boxes being installed are not > defective in particular all the IPv6 capable CPE equipement that will > need to start rolling out the door in the next couple of years. there is nothing we can do to stop new bad middleboxes from being bad, either because they'll inherit codebases from bad ones, or because being bad increases a few revenue opportunities. i am particularly worried about stateless firewalls that don't remember the of first fragments they forward, and thus cannot tell the difference between a non-first fragment (having no UDP port numbers) they ought to forward vs. one that they ought not forward. i don't see firewalls become more stateful, it's a hell of a lot of state and the only folks clamouring for it are DNSSEC pushers who might sound insane. > The problem with CPE equipement is that it pretends to be a DNS > server without fulfilling enough of the requirements of a DNS server. i'd say the problem with CPE equipment is that it was tested only against current traffic, not against theoretical traffic, and so stuff that wasn't in the test dataset usually didn't get implemented. since initial revenue didn't suffer, everybody moved up or moved on or cashed out and were heroes, so stories from namedroppers@ about how these products are somehow bad, are completely off-topic for most product designers. -- to unsubscribe send a message to namedroppers-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 Aug 12 00: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 CB7B73A6A38; Wed, 12 Aug 2009 00:08:02 -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 8f0553PI6pbU; Wed, 12 Aug 2009 00:08:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF83D3A63D3; Wed, 12 Aug 2009 00:08:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb7u2-000E5c-I0 for namedroppers-data0@psg.com; Wed, 12 Aug 2009 07:05: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 1Mb7tu-000E4f-Ov for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 07:05:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7D115AC7E4 for ; Wed, 12 Aug 2009 07:05:33 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Wed, 12 Aug 2009 07:54:25 +0100." <1B6540C99B25F4995938FACE@nimrod.local> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 12 Aug 2009 07:05:33 +0000 Message-ID: <8241.1250060733@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Wed, 12 Aug 2009 07:54:25 +0100 > From: Alex Bligh > > This suggests another fallback policy: fall back to (e.g.) UDP/54 (yes, I > know that's XNS Clearinghouse or something, but I'm sure we can find > another well known port number). The spec for this port would be "DNS > that's not broken" (i.e. EDNS0 support compulsory, "MUST NOT" on > interfering middleboxen, etc.). i don't really see a way to enforce rules on third parties like middlebox product designers. but if i could i would still want something other than UDP because firewalls aren't stateful and non-first fragments don't have port numbers. TCP is fragmentation-aware and thus many successful products can stomp all over fragmentation and feel no market/revenue pain, and 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 Wed Aug 12 00:59: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 A0DD73A6918; Wed, 12 Aug 2009 00:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-1.775, 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 93mRZQjQocLR; Wed, 12 Aug 2009 00:59:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F5CB3A67C2; Wed, 12 Aug 2009 00:59:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb8gF-000JhZ-7E for namedroppers-data0@psg.com; Wed, 12 Aug 2009 07:55:31 +0000 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb8fG-000JYC-AZ for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 07:54:33 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id CA82D131464 for ; Wed, 12 Aug 2009 09:54:27 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 485FFCF9B0 for ; Wed, 12 Aug 2009 09:54:31 +0200 (CEST) Message-ID: <4A827535.9060400@NLnetLabs.nl> Date: Wed, 12 Aug 2009 09:54:29 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] experimental/testing DNSSEC algorithm identifiers X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, when working towards adding a new signing algorithm for DNSSEC, we want to test interoperability. To do that in any reasonable kind of way, we need to have an algorithm number before it is allocated. Recent experience has taught us that guessing the number has its dangers; when these temporary algorithm ids 'leak' into deployed implementations, it could cause unexpected problems if the ids end up being used for another algorithm. We have 'private', but that's only one number, and currently there are multiple algorithm proposals. Besides, it might clash with actual privates that are used. So I would like to propose reserving a few identifiers for testing purposes. Say the numbers 245-250, or even 240-250. While working towards an rfc, drafts could use one of these so implementers can have an agreed-upon number for interop testing, and if they end up being seen in the wild, at least we know right away what the problem is. And perhaps do the same for DS and NSEC3 algorithms. Given the current policy, this needs a wg draft, which i'm willing to write, and no i can't believe i'm actually proposing more work for the wg :p Any thoughts? Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqCdTUACgkQ4nZCKsdOncX93gCgiNp51uqyjOUcFVS8A749DneO XPIAoLEovrIjkSMjQg7edKpM0DDGzk7F =Qm2J -----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 Aug 12 00:59:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD1C3A67C2; Wed, 12 Aug 2009 00:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=0.6, J_CHICKENPOX_81=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 zwIoRTiyjhSm; Wed, 12 Aug 2009 00:59:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AF933A6918; Wed, 12 Aug 2009 00:59:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb8eu-000JVt-QR for namedroppers-data0@psg.com; Wed, 12 Aug 2009 07:54:08 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb8er-000JV6-4W for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 07:54:07 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 5094BC2DA3; Wed, 12 Aug 2009 08:54:03 +0100 (BST) Date: Wed, 12 Aug 2009 08:55:03 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Message-ID: <617024FFDB8A38B36B2EE21D@nimrod.local> In-Reply-To: <8241.1250060733@nsa.vix.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 12 August 2009 07:05:33 +0000 Paul Vixie wrote: > i don't really see a way to enforce rules on third parties like middlebox > product designers. I meant "MUST NOT" in an RFC sense. I am of the impression that many middleboxen do not intend to be obnoxious. They are either making a misguided attempt to be helpful (e.g. proxying UDP/53 apparently transparently) or are just importing code that was used in the previous^n release. This cruft would be blown away on UDP/54. Middlebox designers can always deliberately interfere with UDP/54, with SCTP or with indeed anything else which isn't cryptographically signed. So short of HTTPS+XML / IPsec type solutions, I can't see how anything solves this at the transport layer. However, the original problem space that we concerned about is that DNSSEC is likely to make packets larger (and thus run into problems). If it's DNSSEC packets we are talking about, they will themselves be a lot harder to /productively/ interfere with, as the records themselves will be signed. Protecting against such interference was, after all, one of the design goals of DNSSEC. I agree UDP/54 would give no protection to vanilla DNS, but I wasn't really proposing it for that. > but if i could i would still want something other than > UDP because firewalls aren't stateful and non-first fragments don't have > port numbers. TCP is fragmentation-aware and thus many successful > products can stomp all over fragmentation and feel no market/revenue > pain, and have. Indeed, it doesn't solve the fragmentation problem. BTW I think it's not just firewalls, but also NAT boxes. However, most firewalls/NATs (at least on the middleboxen currently causing us pain) don't appear to pass anything other than UDP, TCP and ICMP, so we are stuck with choosing between them if the goal is to traverse existing middleboxen better (I recommend not using ICMP...). -- 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 Aug 12 01:19:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9566C3A68DD; Wed, 12 Aug 2009 01:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 Psv89EFl6Wn0; Wed, 12 Aug 2009 01:19:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCD953A681D; Wed, 12 Aug 2009 01:19:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb90E-000MZG-Fq for namedroppers-data0@psg.com; Wed, 12 Aug 2009 08:16:10 +0000 Received: from [209.85.218.213] (helo=mail-bw0-f213.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb909-000MYh-R6 for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 08:16:08 +0000 Received: by bwz9 with SMTP id 9so3803031bwz.41 for ; Wed, 12 Aug 2009 01:16:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.10 with SMTP id a10mr723100fas.5.1250064962179; Wed, 12 Aug 2009 01:16:02 -0700 (PDT) In-Reply-To: <4A827535.9060400@NLnetLabs.nl> References: <4A827535.9060400@NLnetLabs.nl> From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Wed, 12 Aug 2009 10:15:42 +0200 Message-ID: Subject: Re: [dnsext] experimental/testing DNSSEC algorithm identifiers To: Jelte Jansen Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Aug 12, 2009 at 9:54 AM, Jelte Jansen wrote: > > So I would like to propose reserving a few identifiers for testing purpos= es. Say > the numbers 245-250, or even 240-250. While working towards an rfc, draft= s could > use one of these so implementers can have an agreed-upon number for inter= op > testing, and if they end up being seen in the wild, at least we know righ= t away > what the problem is. And perhaps do the same for DS and NSEC3 algorithms. > > Any thoughts? Seems reasonable and I am willing to review the draft. Ondrej. -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. =C2=A0-- =C2=A0.cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz =C2=A0http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 =C2=A0 =C2=A0 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 Aug 12 01: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 4157B3A68DD; Wed, 12 Aug 2009 01:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsGi3Zru0Fuo; Wed, 12 Aug 2009 01:34:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 704E33A67C2; Wed, 12 Aug 2009 01:34:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9EX-000OOJ-Mw for namedroppers-data0@psg.com; Wed, 12 Aug 2009 08:30:57 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9ET-000ONn-Sz for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 08:30:55 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by gromit.rfc1035.com (Postfix) with ESMTP id B1DB1577BC5 for ; Wed, 12 Aug 2009 09:30:51 +0100 (BST) Message-Id: From: Jim Reid To: Namedroppers In-Reply-To: <1B6540C99B25F4995938FACE@nimrod.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] middleboxes and an alternate port number Date: Wed, 12 Aug 2009 09:30:50 +0100 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 12 Aug 2009, at 07:54, Alex Bligh wrote: > Any middlebox is going to do one of three things: pass the packets > through verbatim (fine), drop the packets entirely (in which case > SCTP etc. would be unlikely to get through either), or drop only > fragments (still a problem). What they wouldn't do is pretend to be a > UDP/54 DNS server when they aren't, or mangle the packets. I wouldn't want to rely on that assumption. If/when DNS uses an alternate or fallback port as you suggest, new middleboxes will almost certainly get firmware which breaks packets to that port number in the same way they break stuff to port 53. The same will no doubt hold if/ when an alternate transport is used for DNS 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 Wed Aug 12 01:49: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 2089F3A695D; Wed, 12 Aug 2009 01:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.501, 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 T5U77V4M6AQX; Wed, 12 Aug 2009 01:49:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 457E83A6B50; Wed, 12 Aug 2009 01:49:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9S9-00002D-6q for namedroppers-data0@psg.com; Wed, 12 Aug 2009 08:45:01 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9S2-000Q0g-Ly; Wed, 12 Aug 2009 08:44:57 +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=FcVX37/APcfILJJDIZ3U24ZTXxWPqh8KyE7dqAAzwETei3R6qpf3y6iM YsNM4/uyJoNKrbERMJ/WA7E9p2WqpKT7Yjora1icf5gztsS5htWdlOcjY ub859IoWntUF9Zb; 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=1250066694; x=1281602694; 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]=20DNS=20over=20SCTP=20problems,=20part=201,=20theory |Date:=20Wed,=2012=20Aug=202009=2009:44:46=20+0100 |Message-ID:=20|To:=20Paul=20Vixie=20|Cc:=20namedroppers@ops.ietf.org,=0D=0A=09own er-namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<8241.1250060733@nsa.vix.com>|References: =20<4A80453B.1000203@gmail.com>=20<8560.1249922543@nsa.vi x.com>=20<4A80685A.1080104@gmail.com>=20=20<4A817D6E.9 040202@gmail.com>=20<87474.1250029811@nsa.vix.com>=20=20< 1B6540C99B25F4995938FACE@nimrod.local>=20<8241.1250060733 @nsa.vix.com>; bh=iN+BirP9hNmsiZZlwYwNI6ZM54QgeXcT4bzOrPPtIEY=; b=re0IJa02wKGpfcc7CAUZ8qCCSglqknxyTykCxJpdIK0EUz+K3i22E34D jYpwy/cbLXPbUeNRZC3HpBnNgRYnKIBOsiqHsXI8i/63Acns4vjvbg5ad 2p/hT2ktav8D69F; X-IronPort-AV: E=Sophos;i="4.43,365,1246834800"; d="scan'208";a="16630894" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 12 Aug 2009 09:44:47 +0100 In-Reply-To: <8241.1250060733@nsa.vix.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 12 Aug 2009 09:44:46 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/08/2009 09:44:51 AM, Serialize complete at 12/08/2009 09:44:51 AM Content-Type: multipart/alternative; boundary="=_alternative 00300B5280257610_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 00300B5280257610_= Content-Type: text/plain; charset="US-ASCII" > i don't really see a way to enforce rules on third parties like middlebox > product designers. but if i could i would still want something other than > UDP because firewalls aren't stateful and non-first fragments don't have > port numbers. TCP is fragmentation-aware and thus many successful products > can stomp all over fragmentation and feel no market/revenue pain, and have. Paul, Please note that in the testing for SAC035 we experienced no significant issues with _routing_ fragmented DNS packets through any of the middleboxes[*]. All of them were able to forward fragmented responses to the original client. FWIW - NAT and firewalling was enabled for every test - the state simply wasn't a problem for them. The fragmentation problems were with the _proxies_ in those boxes, where those proxies were only used because that's what their DHCP servers offered. So, in the SOHO case, yes, there are potential problems, but most of them will only be evident iff an end user box is requesting large responses (e.g. for DNSSEC validation) and the requests are directed at their local SOHO gateway. If the end user is sending their DNS requests directly to their ISP resolver they won't normally have _any_ problems with UDP or EDNS0/4096. Since I did my research Eric Osterweil has shown that there are apparently also fragmentation related problems on the recursor -> authority path. However I for one would like to know what the specific network architecture was for each test site so that we can tell what class of device actually caused the problems and whether in effect he's just found the same problems that I did. kind regards, Ray [*] I'm only aware of a couple of rare cases where SOHO middleboxes _transparently_ modify DNS traffic. Specifically on Zyxel DSL routers their zero-configuration logic spoofs a specific A record such that end-user HTTP requests go to a "your internet connection is offline" page when the DSL WAN port is down. There was also one router which would only permit outbound DNS traffic if it was to the same DNS servers that were in the ISP's DHCP offer. That was fixed in a subsequent firmware update. -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 00300B5280257610_= Content-Type: text/html; charset="US-ASCII"
> i don't really see a way to enforce rules on third parties like middlebox
> product designers.  but if i could i would still want something other than
> UDP because firewalls aren't stateful and non-first fragments don't have
> port numbers.  TCP is fragmentation-aware and thus many successful products
> can stomp all over fragmentation and feel no market/revenue pain, and have.
Paul,

Please note that in the testing for SAC035 we experienced no significant issues with _routing_ fragmented DNS packets through any of the middleboxes[*].  All of them were able to forward fragmented responses to the original client.  FWIW - NAT and firewalling was enabled for every test - the state simply wasn't a problem for them.

The fragmentation problems were with the _proxies_ in those boxes, where those proxies were only used because that's what their DHCP servers offered.

So, in the SOHO case, yes, there are potential problems, but most of them will only be evident iff an end user box is requesting large responses (e.g. for DNSSEC validation) and the requests are directed at their local SOHO gateway.  If the end user is sending their DNS requests directly to their ISP resolver they won't normally have _any_ problems with UDP or EDNS0/4096.

Since I did my research Eric Osterweil has shown that there are apparently also fragmentation related problems on the recursor -> authority path.  However I for one would like to know what the specific network architecture was for each test site so that we can tell what class of device actually caused the problems and whether in effect he's just found the same problems that I did.

kind regards,

Ray

[*] I'm only aware of a couple of rare cases where SOHO middleboxes
 _transparently_ modify DNS traffic.  Specifically on Zyxel DSL routers
 their zero-configuration logic spoofs a specific A record such that
 end-user HTTP requests go to a "your internet connection is offline"
 page when the DSL WAN port is down.

 There was also one router which would only permit outbound DNS traffic
 if it was to the same DNS servers that were in the ISP's DHCP offer.
 That was fixed in a subsequent firmware update.

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


 --=_alternative 00300B5280257610_=-- -- to unsubscribe send a message to namedroppers-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 Aug 12 01: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 D7AB73A686E; Wed, 12 Aug 2009 01:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.711 X-Spam-Level: X-Spam-Status: No, score=-4.711 tagged_above=-999 required=5 tests=[AWL=-1.413, 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 sqNBa9xcHE2q; Wed, 12 Aug 2009 01:59:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9CB73A698B; Wed, 12 Aug 2009 01:59:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9cF-0001If-2B for namedroppers-data0@psg.com; Wed, 12 Aug 2009 08:55:27 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9cA-0001Hf-1O; Wed, 12 Aug 2009 08:55:24 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=EqKgjIlHu6u4+iwExGI4Z/HdDbXd4jceqRUxCr4pX7XgGPSaQRPc1GHS TpHgZ88geaVVnSBCoectT4tkM+Yck3VRWR8cHmLq49AfqJNB0kM3A9IeK JtvUprlaVouyNsa; 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=1250067322; x=1281603322; 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]=20middleboxes=20and=20an=20alternate=20port=20number |Date:=20Wed,=2012=20Aug=202009=2009:53:22=20+0100 |Message-ID:=20|To:=20Jim=20Reid=20|Cc:=20Namedroppers=20,=0D=0A=09owner-namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20|References:=20<4A80453B.100 0203@gmail.com>=20<8560.1249922543@nsa.vix.com>=20<4A8068 5A.1080104@gmail.com>=20=20=20<4A817D6E.9040202@gmail. com>=20=20<87474.1250029811@nsa.vix.com>=20<1B6540C99B25F 4995938FACE@nimrod.local>=20; bh=1NOBkcb4n7Mp6EEYjoLcSGU4uBk/TUSzVyW1w/hJ4/c=; b=3hXGVXkA2iNlOqqA1G/XdyV5QYrUjExD6Kuczxo2BUuvXdo7zGgxEuPv U+b8n8CSttzuro2cD+veTJxryveuIHpx21PzB2pnMDkOrMMrMbktMgL+E xBO5fm4EMN6nQZ+; X-IronPort-AV: E=Sophos;i="4.43,365,1246834800"; d="scan'208";a="16631066" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 12 Aug 2009 09:55:15 +0100 In-Reply-To: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> To: Jim Reid Cc: Namedroppers , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] middleboxes and an alternate port number MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 12 Aug 2009 09:53:22 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/08/2009 09:55:19 AM, Serialize complete at 12/08/2009 09:55:19 AM Content-Type: multipart/alternative; boundary="=_alternative 0030D50480257610_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0030D50480257610_= Content-Type: text/plain; charset="US-ASCII" > I wouldn't want to rely on that assumption. If/when DNS uses an > alternate or fallback port as you suggest, new middleboxes will almost > certainly get firmware which breaks packets to that port number in the > same way they break stuff to port 53. The same will no doubt hold if/ > when an alternate transport is used for DNS traffic. To re-iterate what I just wrote to Paul: The overwhelming majority of middleboxes *DO NOT* break DNS traffic that's _routed_ through them. However most SOHO boxes *DO* break DNS requests that are _directed_ at them, particularly those with "large" responses. Unfortunately that's a very common case because that's the "standard" DHCP offer from their built-in DHCP servers, as apparently recommended by the Broadband Forum. What's really needed is a better way to bootstrap end-device DNS settings so that clients can find their *real* upstream recursive servers and not send queries to their SOHO gateway's proxy. Ray --=_alternative 0030D50480257610_= Content-Type: text/html; charset="US-ASCII"
> I wouldn't want to rely on that assumption. If/when DNS uses an  
> alternate or fallback port as you suggest, new middleboxes will almost  
> certainly get firmware which breaks packets to that port number in the  
> same way they break stuff to port 53. The same will no doubt hold if/
> when an alternate transport is used for DNS traffic.
To re-iterate what I just wrote to Paul:

The overwhelming majority of middleboxes *DO NOT* break DNS traffic that's _routed_ through them.

However most SOHO boxes *DO* break DNS requests that are _directed_ at them, particularly those with "large" responses.

Unfortunately that's a very common case because that's the "standard" DHCP offer from their built-in DHCP servers, as apparently recommended by the Broadband Forum.

What's really needed is a better way to bootstrap end-device DNS settings so that clients can find their *real* upstream recursive servers and not send queries to their SOHO gateway's proxy.

Ray
--=_alternative 0030D50480257610_=-- -- to unsubscribe send a message to namedroppers-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 Aug 12 02: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 265EB3A68BE; Wed, 12 Aug 2009 02:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 x0UYqlQ-0sqf; Wed, 12 Aug 2009 02:11:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4DC43A683B; Wed, 12 Aug 2009 02:11:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mb9oJ-0003A3-RZ for namedroppers-data0@psg.com; Wed, 12 Aug 2009 09:07: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 1Mb9oG-00039F-74 for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 09:07:53 +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=diIx1ZYNi0fdw1/7eWTbVDPcBBzJSRvhQ88T8eyArOcD/FOVnGvvnXUC MISVX87nEFpA3V1mmLhUASKc8Tn1yiOVjP/qORy4cUX+A9CHAagHhRRbv /rLReZa6A7wR1l8; 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=1250068072; x=1281604072; 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]=20DNS=20over=20SCTP=20problems,=20part=201,=20theory |Date:=20Wed,=2012=20Aug=202009=2010:07:46=20+0100 |Message-ID:=20|To:=20Alex=20Bligh=20|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<617024FFDB8A38B36B2E E21D@nimrod.local>|References:=20<4A80453B.1000203@gmail. com>=20<8560.1249922543@nsa.vix.com>=20<4A80685A.1080104@ gmail.com>=20=20<4A817D6E.9040202@gmail.com>=20<87474. 1250029811@nsa.vix.com>=20=20<1B6540C99B25F4995938FACE@ni mrod.local>=20=20<8241.1250060733@nsa.vix.com>=20<617024F FDB8A38B36B2EE21D@nimrod.local>; bh=uuR5Lt9oTl2pKP6a4aeGCV0EUs7/ai+9Mmx4t+V/c7Q=; b=kglLVVF3Ww2W4yiASSKbn6b9GyxNaN4ZIsfMUNmPtVNc8rgWT4OdN8R7 RD91l9HAGwzJZgCJCjEDLvqRpf/Acyr+Vg9JJ88fkv8pOXnfkZJi/7ok7 GV8WerynxhGj8a4; X-IronPort-AV: E=Sophos;i="4.43,365,1246834800"; d="scan'208";a="16631407" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 12 Aug 2009 10:07:48 +0100 In-Reply-To: <617024FFDB8A38B36B2EE21D@nimrod.local> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 12 Aug 2009 10:07:46 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/08/2009 10:07:50 AM, Serialize complete at 12/08/2009 10:07:50 AM Content-Type: multipart/alternative; boundary="=_alternative 003226A180257610_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 003226A180257610_= Content-Type: text/plain; charset="US-ASCII" > I meant "MUST NOT" in an RFC sense. I am of the impression that many > middleboxen do not intend to be obnoxious. They are either making > a misguided attempt to be helpful (e.g. proxying UDP/53 apparently > transparently) or are just importing code that was used in the > previous^n release. Alex, What sort of boxes are you talking about? Don't forget that the sort of breakage I found and reported on was not caused by "transparent proxying". Sure, there's the "helpful" PIX configuration that says all DNS is <= 512B, but that's comparatively rare. Ray --=_alternative 003226A180257610_= Content-Type: text/html; charset="US-ASCII" > I meant "MUST NOT" in an RFC sense. I am of the impression that many
> middleboxen do not intend to be obnoxious. They are either making
> a misguided attempt to be helpful (e.g. proxying UDP/53 apparently
> transparently) or are just importing code that was used in the
> previous^n release.

Alex,

What sort of boxes are you talking about?

Don't forget that the sort of breakage I found and reported on was not caused by "transparent proxying".

Sure, there's the "helpful" PIX configuration that says all DNS is <= 512B, but that's comparatively rare.

Ray
--=_alternative 003226A180257610_=-- -- to unsubscribe send a message to namedroppers-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 Aug 12 02:45: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 541223A6977; Wed, 12 Aug 2009 02:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_81=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 n0qzQlTpnD6Y; Wed, 12 Aug 2009 02:45:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B6063A635F; Wed, 12 Aug 2009 02:45:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbAL1-0007gu-Mn for namedroppers-data0@psg.com; Wed, 12 Aug 2009 09:41:43 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbAKx-0007gH-GK for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 09:41:41 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id AEE6CC2DA3; Wed, 12 Aug 2009 10:41:37 +0100 (BST) Date: Wed, 12 Aug 2009 10:39:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Message-ID: In-Reply-To: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 12 August 2009 10:07:46 +0100 Ray.Bellis@nominet.org.uk wrote: >> I meant "MUST NOT" in an RFC sense. I am of the impression that many >> middleboxen do not intend to be obnoxious. They are either making >> a misguided attempt to be helpful (e.g. proxying UDP/53 apparently >> transparently) or are just importing code that was used in the >> previous^n release. > > Alex, > > What sort of boxes are you talking about? > > Don't forget that the sort of breakage I found and reported on was not > caused by "transparent proxying". Sorry, slack terminology. I am including (a) the case where they advertise themselves as the DNS server through DHCP, to the local LAN, then one way or another handle packets addressed to them (I recognise there are various ways they can do that), (b) the "transparent proxy" case, which as I understand it happens in some WiFi hotspot / hotel room configurations, at least until authentication has been performed (that's the "e.g." case above) and (c) firewalls which appear to proxy at the DNS layer (they appear to work as forwarders, decoding the query etc.) (from another mail) > Please note that in the testing for SAC035 we experienced no significant > issues with _routing_ fragmented DNS packets through any of the > middleboxes So to be clear, passing fragmented UDP packets through NAT/PNAT is not in general a problem (whether on UDP/53 or otherwise)? (from a third email) > What's really needed is a better way to bootstrap end-device DNS settings > so that clients can find their *real* upstream recursive servers and not > send queries to their SOHO gateway's proxy. The problem appears to have been framed in terms where modifying the middleboxen (at least those in case (a) above) is difficult to impossible. Given that this iteration of the problem appears to be addressed at solving the problem of large DNS answers to DNSSEC queries, we can I suppose assume that the client software is being updated, or it would be asking for DNSSEC records at all. If what you are saying is correct (i.e. the problem only arises when the queries are addressed to the router as per a DHCP response), then perhaps the answer is for the client stub resolver to make some early query (when it receives the DHCP option) for a well known A record (that ISPs could anycast), from which they'd either pull the addresses of "proper" name-servers directly, or perhaps more secure pull them over https from one the A records provided. -- 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 Aug 12 03:01: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 57B753A683B; Wed, 12 Aug 2009 03:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.546 X-Spam-Level: X-Spam-Status: No, score=-4.546 tagged_above=-999 required=5 tests=[AWL=-1.248, 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 305qFGHw2WzY; Wed, 12 Aug 2009 03:01:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 91A6C3A67AD; Wed, 12 Aug 2009 03:01:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbAZj-0009hK-Hy for namedroppers-data0@psg.com; Wed, 12 Aug 2009 09:56:55 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbAZd-0009gT-4j for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 09:56:52 +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=bPS8MdH3ki+Ide0SbrKQeST4oUAZHC1bGn/O8SEFtnToC7IjUcJ78KJ4 a6QIYw5Xdjbi8pdPuG9qFlJEq4WGFJEwQew0W8+y/ZFGv9FAEtmFAg65S WKIivoZeAot4EBh; 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=1250071009; x=1281607009; 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]=20DNS=20over=20SCTP=20problems,=20part=201,=20theory |Date:=20Wed,=2012=20Aug=202009=2010:56:40=20+0100 |Message-ID:=20|To:=20Alex=20Bligh=20|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20|References:=20<4A80453B.1000203@gmail .com>=20<8560.1249922543@nsa.vix.com>=20<4A80685A.1080104 @gmail.com>=20=20<4A817D6E.9040202@gmail.com>=20<87474 .1250029811@nsa.vix.com>=20=20<1B6540C99B25F4995938FACE@n imrod.local>=20=20<8241.1250060733@nsa.vix.com>=20<617024 FFDB8A38B36B2EE21D@nimrod.local>=20=20; bh=fK6Qz9bLMdRDsJ/J54MB1OTXFH7KW4V5KSI8YX1imQU=; b=nYMVEQAHcY9AA55Iancc1PSQCVMWQv4QY7rGSfr6uwKpQxYTCpWsIBld tqXY1eUVbiV3Vmpi5+IRaUcl/l75uTXfXR6ioI1Gt9o9TLW9fxsfTfKBB Cgx/Q1v5F00wJAd; X-IronPort-AV: E=Sophos;i="4.43,366,1246834800"; d="scan'208";a="12167404" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 12 Aug 2009 10:56:42 +0100 In-Reply-To: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 12 Aug 2009 10:56:40 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/08/2009 10:56:45 AM, Serialize complete at 12/08/2009 10:56:45 AM Content-Type: multipart/alternative; boundary="=_alternative 0036A0C880257610_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0036A0C880257610_= Content-Type: text/plain; charset="US-ASCII" > Sorry, slack terminology. I am including (a) the case where they > advertise themselves as the DNS server through DHCP, to the local LAN, then > one way or another handle packets addressed to them (I recognise there are > various ways they can do that), (b) the "transparent proxy" case, which as > I understand it happens in some WiFi hotspot / hotel room configurations, > at least until authentication has been performed (that's the "e.g." case > above) and (c) firewalls which appear to proxy at the DNS layer (they > appear to work as forwarders, decoding the query etc.) OK, So, case (a) is what I tested. All bets are off in case (b), but as I understand it this sort of DNS interception is generally being phased out in favour of HTTP interception because of the client cacheing problem. I don't have hard data on case (c), but I believe it's relatively uncommon. > So to be clear, passing fragmented UDP packets through NAT/PNAT is > not in general a problem (whether on UDP/53 or otherwise)? In my experience, that's correct, there's no problem with fragmentation and NAT/PNAT. > If what you are saying is correct (i.e. the problem only arises when the > queries are addressed to the router as per a DHCP response), then perhaps > the answer is for the client stub resolver to make some early query (when > it receives the DHCP option) for a well known A record (that ISPs could > anycast), from which they'd either pull the addresses of "proper" > name-servers directly, or perhaps more secure pull them over https from one > the A records provided. I've previously had discussions with Wouter about how a smart stub might try and find the address of the local recursive servers instead of using those from DHCP. Part of the solution might be an authoritative DNS server that returns the IP address of the recursive server that sent the query. Funnily enough, there's one of those in my recently published evldns software ;-) (see http://code.google.com/p/evldns/) Ray --=_alternative 0036A0C880257610_= Content-Type: text/html; charset="US-ASCII"
> Sorry, slack terminology. I am including (a) the case where they
> advertise themselves as the DNS server through DHCP, to the local LAN, then
> one way or another handle packets addressed to them (I recognise there are
> various ways they can do that), (b) the "transparent proxy" case, which as
> I understand it happens in some WiFi hotspot / hotel room configurations,
> at least until authentication has been performed (that's the "e.g." case
> above) and (c) firewalls which appear to proxy at the DNS layer (they
> appear to work as forwarders, decoding the query etc.)

OK,

So, case (a) is what I tested.

All bets are off in case (b), but as I understand it this sort of DNS interception is generally being phased out in favour of HTTP interception because of the client cacheing problem.
I don't have hard data on case (c), but I believe it's relatively uncommon.

> So to be clear, passing fragmented UDP packets through NAT/PNAT is
> not in general a problem (whether on UDP/53 or otherwise)?
In my experience, that's correct, there's no problem with fragmentation and NAT/PNAT.
 
> If what you are saying is correct (i.e. the problem only arises when the
> queries are addressed to the router as per a DHCP response), then perhaps
> the answer is for the client stub resolver to make some early query (when
> it receives the DHCP option) for a well known A record (that ISPs could
> anycast), from which they'd either pull the addresses of "proper"
> name-servers directly, or perhaps more secure pull them over https from one
> the A records provided.
I've previously had discussions with Wouter about how a smart stub might try and find the address of the local recursive servers instead of using those from DHCP.

Part of the solution might be an authoritative DNS server that returns the IP address of the recursive server that sent the query.  Funnily enough, there's one of those in my recently published evldns software ;-)

(see http://code.google.com/p/evldns/)

Ray
--=_alternative 0036A0C880257610_=-- -- to unsubscribe send a message to namedroppers-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 Aug 12 04:31: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 926893A6A5E; Wed, 12 Aug 2009 04:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-0.172, 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 DRFaSNYgL5xx; Wed, 12 Aug 2009 04:31:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 731D53A6805; Wed, 12 Aug 2009 04:31:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbByd-000JTA-Cf for namedroppers-data0@psg.com; Wed, 12 Aug 2009 11:26:43 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbByZ-000JSZ-1J for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 11:26:40 +0000 Received: by gxk1 with SMTP id 1so5965712gxk.17 for ; Wed, 12 Aug 2009 04:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=8X8hOciTIP8i2SEF9N9/6cKTXTHdpPaFDpPzfGDPnuc=; b=eG492iRJbp0dqpjwpJhf09MdvIoakxFd/oCoWnb8arWKZv0o8fSupmpRNyqvAfSwmP R1zEDIHuVRkdaF5hDEbewBaMkFOYmMfycGTAj3LltkV8Cq8HK8cOGJAmG5q968iYmxHQ YzHa+dnrJ1oJMMRDT+emi5Hurt9D3yO0BKshE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Wx/kykJy587isLMEXNuG8yEm10vOV8URxzm+aTmOF8XKW3V9TiOi6Nk6TsBJXEl8n1 pbSway++hdZ5LncJvJExSf02FQj1x0NSoRZsyS7+vwVaUmUEkk848FHODVskB5pK09NA u8g+k7g25bqrlCrWH52EIyyUtxtazhlx06ack= Received: by 10.90.188.17 with SMTP id l17mr58429agf.30.1250076397361; Wed, 12 Aug 2009 04:26:37 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 4sm2264713aga.53.2009.08.12.04.26.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 04:26:36 -0700 (PDT) Message-ID: <4A82A6EA.3040105@gmail.com> Date: Wed, 12 Aug 2009 07:26:34 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] middleboxes and an alternate port number Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Everything old is new again. I'm fairly sure this was proposed more than a decade ago.... Jim Reid wrote: # I wouldn't want to rely on that assumption. If/when DNS uses an # alternate or fallback port as you suggest, new middleboxes will almost # certainly get firmware which breaks packets to that port number in the # same way they break stuff to port 53. The same will no doubt hold if/ # when an alternate transport is used for DNS traffic. # I'd prefer that both protocol and port be returned. The protocol would provide the upgrade path, and the port could be randomized to prevent "smart" boxes from interfering, probably greater than 4096. Every installation would select the random port to listen. Ray.Bellis@nominet.org.uk wrote: > The overwhelming majority of middleboxes *DO NOT* break DNS traffic > that's _routed_ through them. > > However most SOHO boxes *DO* break DNS requests that are _directed_ at > them, particularly those with "large" responses. > That's been my unfortunate experience, too. > Unfortunately that's a very common case because that's the "standard" > DHCP offer from their built-in DHCP servers, as apparently recommended > by the Broadband Forum. > And IETF NAS requirements WG, and many others. I probably helped build a half dozen of these in the '90s, too. Arguably, it helped cache and reduce the load on the TLD and root servers. But they complied with the standard, full caching resolvers, handling fragmentation and everything else. As Paul Vixie pointed out, many of these companies have long since died circa 2000, and there's no way to upgrade them to DNSsec. Even companies still in business don't offer upgrades, they want you to buy new product. > What's really needed is a better way to bootstrap end-device DNS > settings so that clients can find their *real* upstream recursive > servers and not send queries to their SOHO gateway's proxy. > We know how to do that. An EDNS0 option that returns an alternate protocol and port pair. Then, the resolver send out a second query to the authoritative server, assuming the middlebox passes Authority and Additional (EDNS0) sections. -- to unsubscribe send a message to namedroppers-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 Aug 12 06:18: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 AFED03A6B7F; Wed, 12 Aug 2009 06:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 Ig+ivuCB+CBT; Wed, 12 Aug 2009 06:18:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B13BE3A6B7B; Wed, 12 Aug 2009 06:18:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbDcf-0007n5-O6 for namedroppers-data0@psg.com; Wed, 12 Aug 2009 13:12:09 +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 1MbDcb-0007m8-Nh for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 13:12:07 +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 n7CDB9hC002636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 06:11:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A827535.9060400@NLnetLabs.nl> References: <4A827535.9060400@NLnetLabs.nl> Date: Wed, 12 Aug 2009 06:11:08 -0700 To: Jelte Jansen , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] experimental/testing DNSSEC algorithm identifiers Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:54 AM +0200 8/12/09, Jelte Jansen wrote: >when working towards adding a new signing algorithm for DNSSEC, we want to test >interoperability. To do that in any reasonable kind of way, we need to have an >algorithm number before it is allocated. Recent experience has taught us that >guessing the number has its dangers; when these temporary algorithm ids 'leak' >into deployed implementations, it could cause unexpected problems if the ids end >up being used for another algorithm. > >We have 'private', but that's only one number, and currently there are multiple >algorithm proposals. Besides, it might clash with actual privates that are used. > >So I would like to propose reserving a few identifiers for testing purposes. Say >the numbers 245-250, or even 240-250. While working towards an rfc, drafts could >use one of these so implementers can have an agreed-upon number for interop >testing, and if they end up being seen in the wild, at least we know right away >what the problem is. And perhaps do the same for DS and NSEC3 algorithms. > >Given the current policy, this needs a wg draft, which i'm willing to write, and >no i can't believe i'm actually proposing more work for the wg :p At the Stockholm meeting, I volunteered to write the draft revising the algorithm allocation rules. The topic of "experimental" allocations was not brought up, but could be considered in the draft. I'm hoping to have the first draft out later this week. Having said that, the IETF has a long and painful history of protocols with identifiers reserved for testing. If the WG wants to have such identifiers, the wording in the document about what they mean will be very important. --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 Aug 12 07:33: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 94AE83A6AE0; Wed, 12 Aug 2009 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 lDPDuH0ti6uu; Wed, 12 Aug 2009 07:33:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9108A3A6A6C; Wed, 12 Aug 2009 07:33:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbEov-000IPP-8R for namedroppers-data0@psg.com; Wed, 12 Aug 2009 14: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 1MbEoq-000IOT-0V for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 14:28:51 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7CERsMu013952; Wed, 12 Aug 2009 10:27:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A827535.9060400@NLnetLabs.nl> References: <4A827535.9060400@NLnetLabs.nl> Date: Wed, 12 Aug 2009 10:26:34 -0400 To: Jelte Jansen From: Edward Lewis Subject: Re: [dnsext] experimental/testing DNSSEC algorithm identifiers 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 9:54 +0200 8/12/09, Jelte Jansen wrote: >Any thoughts? In summary - I have doubts about the future of this proposal, no matter how worthy it is. Why I am being a grump: We (DNSIND/DNSEXT WGs)'ve had a bad experience with proposals to allocate "general pool" numbers. There is the Kitchen SINK RR (RRType = 40, http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02) and a generic key application for the old KEY RR (http://tools.ietf.org/html/draft-lewis-dnsext-key-genprot-00). (Okay, those both wanted a number for general purpose use. But the pool could have been greater than "one" in size.) The dynamic in the development process is this. (Assuming the goal is to get something on the standards track.) First you want initial development you need to plug in a number. You then need to produce a document to get the idea out. Following this you want there to be some wide spread experimentation, which often borders on initial deployment. With this you are prepared for standards vetting and then initial deployment. The snag in this process is that your experimental deployment will use value 243 but IANA will give you the value 93. You then need to uproot all the early adopters. This problem is what has driven many applications to use the TXT record - in the case when the number in question is the RR type. The difference here is that you are talking about a different protocol parameter, one that is more obscure. But you will have the same issue when you do from -draft-" to RFC/PS and then DS. Another problem is the documentation issue. Look at SINK. Yes, there's no RFC because the WG lost it's will to finish off the experiment. On the one hand, we have the number burned into the registry and a way to find information about SINK. Yes, it says "Eastlake" and if you know him, you can reach him. You can also search for the draft in many repositories, now even the IETF has one. If SINK had used an experimental value, you couldn't even do that. You might tcpdump and see something using value 243 - but until you fingerprinted the source IP address you might not be able tell if that was Jelte's bad idea of 2009 or Blacka's bad idea of 2003 (or even Jelte's bad idead of 2010, 2011, ...). Reused numbers make it hard to do a text search for "what's happening?" (Recall the question of "where are all the A6 queries coming from?" asked in 2007. Many of knew right away - BIND - because A6 was a specific allocation, fully documented, moved to experimental and recognized as a truly had idea by all sane people. I said "sane.") The only place that allocating numbers for "private use" that has worked is in IPv4 because we have NAT. (Which everyone "hates" to some extent.) I know there's a call for them in IPv6 because we are used to them in IP address management. Reusable numbers work in IP because we control them with the routing system, we don't have a similar scoping mechanism available for an application protocol. I wish that I could be more optimistic about this effort. I wanted to do it once too (for the KEY RR). But it never seems to work. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Aug 12 07:40: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 4B4693A6BAB; Wed, 12 Aug 2009 07:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 mbMI5igSUs3K; Wed, 12 Aug 2009 07:40:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25C2A3A67D9; Wed, 12 Aug 2009 07:40:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbExY-000Ja3-Qu for namedroppers-data0@psg.com; Wed, 12 Aug 2009 14:37:48 +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 1MbExQ-000JZA-Rk for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 14:37:46 +0000 Received: from dul1mcmlarson-l1-2.local (localhost.localdomain [127.0.0.1]) by mail.kahlerlarson.org (Postfix) with ESMTP id 6421737CE5 for ; Wed, 12 Aug 2009 10:37:38 -0400 (EDT) Date: Wed, 12 Aug 2009 10:37:38 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: Re: [dnsext] NSEC3 confusion (in .org) Message-ID: <20090812143737.GB1960@dul1mcmlarson-l1-2.local> References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> <200908110010.n7B0AvDR060945@drugs.dv.isc.org> <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> <200908120536.n7C5a79k091897@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200908120536.n7C5a79k091897@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 12 Aug 2009, Mark Andrews wrote: > In message <20090812050546.GJ1348@dul1mcmlarson-l1-2.local>, Matt Larson = writes > > On Tue, 11 Aug 2009, Mark Andrews wrote: > > > No. Just your assumption is false. NS RRsets are removed > > > by registrars without the glue records beneath them also > > > being removed for spam and other network abuse issues. This > > > causes the glue to become authoritative data. > > >=20 > > > The same thing happens in COM, NET and I presume all other > > > zones with a registry/registrar model. The registrars > > > really should be pulling the glue records as well. It's > > > up to the registry enforce this however. > >=20 > > That is not correct. At least in .com and .net, the registry business > > logic prevents a domain from being deleted if name servers (i.e., host > > objects in the registry database that result in glue A or AAAA RRs in > > the zone) under that domain still exist. E.g., a registrar must first > > delete the name server "ns.foo.com" before deleting the domain > > "foo.com". >=20 > I wasn't talking about a delegation being deleted. Note I qualified > the removal based on "spam and other network abuse issues". Hold statuses are administrative and are most often used for non-technical reasons. Domains go on hold for "spam and other network abuse issues" rarely, if ever, in .com/.net. (But note that putting a domain on hold for that reason would have to be initiated by the registrar.) I took issue with your ascribing fault to the registrars and the registries for the glue remaining in the zone. This issue is out of control of the registrars, who would be unable to remove the name servers of a domain on hold because of another business rule: a name server can't be removed if it is associated with any domains, i.e., has a non-zero reference count. So it's not realistic to expect that registrars could ensure no authoritative glue remained of on-hold domains. =46rom the registry perspective, it's not a clear-cut issue: there is a good case to be made either way for promoting name servers (A/AAAA RRs) of on-hold domains to authoritative data (or not). I think the current .com/.net behavior of promotion is reasonable, but I also think DNSSEC is a good justification for changing the behavior. The dwindling DNS protocol content in this thread probably puts it out of scope soon (if not already)... 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 Wed Aug 12 08:39: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 021153A6B61; Wed, 12 Aug 2009 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.656 X-Spam-Level: X-Spam-Status: No, score=0.656 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=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 Ua8pU1wnLbET; Wed, 12 Aug 2009 08:39:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27AC43A69EE; Wed, 12 Aug 2009 08:39:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbFpw-00008G-2H for namedroppers-data0@psg.com; Wed, 12 Aug 2009 15:34: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 1MbFps-00007r-FR for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 15:33: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 n7CFXsnb014526 for ; Wed, 12 Aug 2009 11:33:54 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n7CFXsjh014525 for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 11:33:54 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaZ9S-000Ka7-0D for namedroppers@ops.ietf.org; Mon, 10 Aug 2009 17:59:19 +0000 Received: by ewy28 with SMTP id 28so185103ewy.41 for ; Mon, 10 Aug 2009 10:59:16 -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=ezMtN2lVzgdDoxO39EInYRhkwRZGKHDh/ki/MCEJzZ8=; b=RExyiRn8vBA6S4XK0krenh/oaj7S8dxmqH/sQQxGFkVMNFJTk3CV8Pw6F/+1b5A/+D XzHM5f/o7AQiNOUplep4GoXwxSUWK0FjE/qPVpsTTF8rJYwnCzt9pRGUKJq/T1sUhn3J X9+G/kGrHwzLINflpZoODvtvexwjG6r32aHUU= 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=ite0BnSZCeCZfxkMbiSlcrpdS9JhMboT/AqsTOcipR6AwkHQvIRbAJaE2Ycx7TXxrM acVScf7twMnHIhXtHAQdVlXM39I4gB8EfVL/28s+YUudL6Qd6wUZs9I/UmCQ2sipq2Tf MoANeNSMajKt4q7qAP0gALjtI5gIAyTu+Lc3E= MIME-Version: 1.0 Received: by 10.210.137.14 with SMTP id k14mr3099992ebd.95.1249927156107; Mon, 10 Aug 2009 10:59:16 -0700 (PDT) In-Reply-To: References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> From: bert hubert Date: Mon, 10 Aug 2009 19:58:56 +0200 X-Google-Sender-Auth: bef094dbbfddd501 Message-ID: <3efd34cc0908101058o7d51bda5i5af6b8a4556eed59@mail.gmail.com> Subject: Re: [dnsext] NSEC3 confusion (in .org) To: Edward Lewis Cc: "namedroppers@ops.ietf.org 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 Mon, Aug 10, 2009 at 7:29 PM, Edward Lewis wrote: > Just to make sure, the "error" is in "powerdnssecc.org" and the www.123.4= 55 > is just a red herring here. The thing I wonder about is how two of the NSEC3s can claim to have an A in its type-set, since .org is 'delegation only'. The rest of your analysis looks sound (thanks), even though I continue to have a very hard time grasping the finer details of NSEC3. Not looking forward to the empty non-terminals bit either. > Does that make sense? =A0NSEC3 #1 says the QNAME isn't here, NSEC3 #2 > identifies the closest encloser (by denying their is a closer name to > QNAME), and NSEC3 #3 reports that there's no source of synthesis. It is all incredibly clever. 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 Aug 12 08:41: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 C18833A6AE0; Wed, 12 Aug 2009 08:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 uUsdLC5CRQPw; Wed, 12 Aug 2009 08:41:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7114A3A6803; Wed, 12 Aug 2009 08:41:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbFuj-0000ka-Ba for namedroppers-data0@psg.com; Wed, 12 Aug 2009 15:38:57 +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 1MbFuf-0000jv-KG for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 15:38:55 +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 n7CFckDK015548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 08:38:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4A827535.9060400@NLnetLabs.nl> Date: Wed, 12 Aug 2009 08:38:46 -0700 To: Edward Lewis , Jelte Jansen From: Paul Hoffman Subject: Re: [dnsext] experimental/testing DNSSEC algorithm identifiers Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:26 AM -0400 8/12/09, Edward Lewis wrote: >In summary - I have doubts about the future of this proposal, no matter how worthy it is. > >Why I am being a grump: +1 to what Ed said. But I'll include a straw man in the -00 of the draft and see what others think. --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 Aug 12 08:52: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 10F033A6AE0; Wed, 12 Aug 2009 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqjXcFnypBQ1; Wed, 12 Aug 2009 08:52:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B4133A6803; Wed, 12 Aug 2009 08:52:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbG52-0002LQ-Q3 for namedroppers-data0@psg.com; Wed, 12 Aug 2009 15:49: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 1MbG4z-0002Kk-9f for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 15:49:35 +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 n7CFnUM2014742; Wed, 12 Aug 2009 11:49:30 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200908121549.n7CFnUM2014742@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Aug 2009 11:49:25 -0400 To: Doug Otis , William Allen Simpson From: Olafur Gudmundsson Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice Cc: namedroppers@ops.ietf.org In-Reply-To: <4A81A69D.1060103@gmail.com> References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> <4A81A69D.1060103@gmail.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:13 11/08/2009, Doug Otis wrote: >>>When SCTP is not supported, the fallback would be to UDP and then TCP. >> >>Actually, since SCTP would only be the fallback from UDP, that would only >>leave TCP. > >The goal would be to have SCTP support all DNS traffic and have it >attempted first. Delays caused by timeouts due to blocked UDP >responses are avoided, as are spoofed reflected attacks. SCTP also >better ensures responses are protected from spoofed poisoning. Who's goal? IMHO SCTP is being proposed as an alternative to TCP not UDP. 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 Aug 12 08:54: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 D14D83A6A5D; Wed, 12 Aug 2009 08:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 OgUv7qEZXVV2; Wed, 12 Aug 2009 08:54:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45FB43A6803; Wed, 12 Aug 2009 08:54:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbG6l-0002W4-IF for namedroppers-data0@psg.com; Wed, 12 Aug 2009 15:51:23 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:918c] (helo=out-66.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbG6h-0002Va-9J for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 15:51:21 +0000 Received: from smtp-13.smtp.ucla.edu (smtp-13.smtp.ucla.edu [169.232.46.249]) by out-66.smtp.ucla.edu with ESMTP id n7CFoihX008422; Wed, 12 Aug 2009 08:50:48 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-13.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7CFoihX008422; Wed, 12 Aug 2009 08:50:44 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7CFoffb004158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 08:50:43 -0700 Cc: Paul Vixie , William Allen Simpson , namedroppers@ops.ietf.org Message-Id: <17E79345-9F95-4673-8B02-D6F9EF04CE24@cs.ucla.edu> From: Eric Osterweil To: Mark Andrews In-Reply-To: <200908112350.n7BNoSY7089617@drugs.dv.isc.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15--945383664" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Wed, 12 Aug 2009 09:50:39 -0600 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <200908112350.n7BNoSY7089617@drugs.dv.isc.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.249 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-15--945383664 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 11, 2009, at 5:50 PM, Mark Andrews wrote: > > In message <87474.1250029811@nsa.vix.com>, Paul Vixie writes: >> >> >> none of us consider these badly implemented middleboxes to be =20 >> repairable sinc >> e >> they are all over the internet now and many of their manufacturers =20= >> are out of >> business and many of their original installers/operators are =20 >> retired or dead. > > > The client advertises a 4096 byte EDNS UDP size option, the CPE the > advertises a 1460 byte EDNS UDP size option when it "forwards" the > packet. The reply with a 4096 byte EDNS UDP size will then be able > to be processed by the CPE equipment, when the reply is forwarded > to the original client the CPE will put the miniumum of the received > EDNS UDP size and its buffer size in the EDNS UDP size returned to > the original client. You know, rather than trying to imagine how middleboxes can be made to =20= help, we could just talk about the relatively simple fix of letting =20 resolvers discover the buffer size that works for them. afaict, we =20 still have control over resolver software ("we" meaning those resolver =20= maintainers on the list). This would allow resolvers to advertise the =20= proper sizes and it would allow _them_ to keep state if different =20 buffer sizes were needed for different paths. This ought to be =20 possible with fewer RTTs than TCP and certainly fewer than SCTP. Hop-by-hop rewrite is a slippery slope. If we really needed it, that =20= would be one thing, but I think it's quite unnecessary here, and =20 likely infeasible anyway. Eric =E9 --Apple-Mail-15--945383664 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 v2.0.9 (Darwin) iEYEARECAAYFAkqC5M8ACgkQK/tq6CJjZQLy5QCeIT+Ei9CrIigFgejsAQRwG/ot pxwAoJja+g4jmex5zDObgnvxk6yuNbIx =c/7n -----END PGP SIGNATURE----- --Apple-Mail-15--945383664-- -- to unsubscribe send a message to namedroppers-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 Aug 12 09:21: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 088B63A6AE0; Wed, 12 Aug 2009 09:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[AWL=-1.186, 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 9RB4qTtAvTzh; Wed, 12 Aug 2009 09:21:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B95463A6A2B; Wed, 12 Aug 2009 09:21:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbGUh-0005sq-Un for namedroppers-data0@psg.com; Wed, 12 Aug 2009 16:16:07 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbGUc-0005pR-7C for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 16:16:05 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=J7ZlxRwBQcBy7sheB1UZ+S9qOLDVl5Xwx0PSV0xZVpMTku2MHhYkZfQk cQQ/hmxf612MP7eyNvOV+bQHVJPw3w5D5OplHktxYwRoKJpaPmFCLVesC uclR7ERNEhl5mGP; 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=1250093762; x=1281629762; 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]=20DNS=20over=20SCTP=20problems,=20part=201,=20theory |Date:=20Wed,=2012=20Aug=202009=2017:15:54=20+0100 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0|In-Reply-To:=20|References:=20<4A804 53B.1000203@gmail.com>=20<8560.1249922543@nsa.vix.com>=20 <4A80685A.1080104@gmail.com>=20=20<4A817D6E.9040202@gm ail.com>=20<87474.1250029811@nsa.vix.com>=20=20<1B6540C99 B25F4995938FACE@nimrod.local>=20<8241.1250060733@nsa.vix. com>=20=20; bh=WspngrCJ0637qL5DY7Hzd/Q6Mms+fczCNdnUDRImQ2g=; b=obA9KxMbW4hYgQgI4wUJLC5ykXcW3tMNwZ6U1M3T7YlgjOKI8LO3Qtti Jhjnmg2uyrF/HAQgTMg85Y+l23QvhaRJKeh5WiY47xlvl8jnkw9mKOrex X33pa208LQSxmI0; X-IronPort-AV: E=Sophos;i="4.43,368,1246834800"; d="scan'208";a="16653482" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 12 Aug 2009 17:15:57 +0100 In-Reply-To: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 12 Aug 2009 17:15:54 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/08/2009 05:15:59 PM, Serialize complete at 12/08/2009 05:15:59 PM Content-Type: multipart/alternative; boundary="=_alternative 005958A280257610_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 005958A280257610_= Content-Type: text/plain; charset="US-ASCII" > I'm not 100% clear on what you're asking, so please let me know if > this is helpful. > > The testing we do is from each of our 8 pollers. Each of these is > hosted in someone else's network. The list can be found at > http://secspider.cs.ucla.edu/clients.html > > I am not familiar with the actual architecture of each network. Hi Eric, What I'm hoping to establish is whether at each probe site the DNS queries are sent: 1. directly to each zone's authoritative servers, or 2. directly to specified recursive servers, or 3. to whatever recursive servers the local site offered by DHCP (where option 3 in some cases may be a local device's DNS proxy). > I was curious if you think there is some merit to doing some additional > forensics from those pollers when we get a failure, and if you have > any thoughts there? We currently to not catch any ICMP responses, so > that has been an idea we've kicked around to help with correlating > failures. We didn't look for ICMP responses either. What we did do was look at packet traces either side of the the proxy to determine whether it was the request or (fragments of) the response being dropped. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 005958A280257610_= Content-Type: text/html; charset="US-ASCII"
> I'm not 100% clear on what you're asking, so please let me know if  
> this is helpful.
>
> The testing we do is from each of our 8 pollers.  Each of these is  
> hosted in someone else's network.  The list can be found at
>    http://secspider.cs.ucla.edu/clients.html
>
> I am not familiar with the actual architecture of each network.  
Hi Eric,

What I'm hoping to establish is whether at each probe site the DNS queries are sent:

1.  directly to each zone's authoritative servers, or
2.  directly to specified recursive servers, or
3.  to whatever recursive servers the local site offered by DHCP

(where option 3 in some cases may be a local device's DNS proxy).

> I was curious if you think there is some merit to doing some additional  
> forensics from those pollers when we get a failure, and if you have  
> any thoughts there?  We currently to not catch any ICMP responses, so  
> that has been an idea we've kicked around to help with correlating  
> failures.

We didn't look for ICMP responses either.  What we did do was look at packet traces either side of the the proxy to determine whether it was the request or (fragments of) the response being dropped.

kind regards,

Ray

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

--=_alternative 005958A280257610_=-- -- to unsubscribe send a message to namedroppers-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 Aug 12 09:33: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 295553A6B3A; Wed, 12 Aug 2009 09:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 XHxWxVfkL6NX; Wed, 12 Aug 2009 09:33:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AE173A698E; Wed, 12 Aug 2009 09:33:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbGiB-0007rS-Al for namedroppers-data0@psg.com; Wed, 12 Aug 2009 16:30:03 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febf:cfa7] (helo=out-56.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbGi6-0007ov-7y for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 16:30:00 +0000 Received: from smtp-11.smtp.ucla.edu (smtp-11.smtp.ucla.edu [169.232.46.244]) by out-56.smtp.ucla.edu with ESMTP id n7CGTVDU007946; Wed, 12 Aug 2009 09:29:37 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.145]) by smtp-11.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7CGTVDU007946; Wed, 12 Aug 2009 09:29:31 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7CGTTGU002110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 09:29:30 -0700 Cc: namedroppers@ops.ietf.org Message-Id: <1B5B5E62-21F3-465B-AC39-341F985FF1F6@cs.ucla.edu> From: Eric Osterweil To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-19--943057476" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Wed, 12 Aug 2009 10:29:25 -0600 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.244 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-19--943057476 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 12, 2009, at 10:15 AM, Ray.Bellis@nominet.org.uk wrote: > > > I'm not 100% clear on what you're asking, so please let me know if > > this is helpful. > > > > The testing we do is from each of our 8 pollers. Each of these is > > hosted in someone else's network. The list can be found at > > http://secspider.cs.ucla.edu/clients.html > > > > I am not familiar with the actual architecture of each network. > > Hi Eric, > > What I'm hoping to establish is whether at each probe site the DNS =20 > queries are sent: > > 1. directly to each zone's authoritative servers, or Yes. > > 2. directly to specified recursive servers, or > > 3. to whatever recursive servers the local site offered by DHCP Only for NS+A. After that, the DNSSEC queries are sent to auth name =20 servers only. > > > (where option 3 in some cases may be a local device's DNS proxy). > > > I was curious if you think there is some merit to doing some =20 > additional > > forensics from those pollers when we get a failure, and if you have > > any thoughts there? We currently to not catch any ICMP responses, =20= > so > > that has been an idea we've kicked around to help with correlating > > failures. > > We didn't look for ICMP responses either. What we did do was look =20 > at packet traces either side of the the proxy to determine whether =20 > it was the request or (fragments of) the response being dropped. Then, this should be an illuminating extension I hope. :) Eric =E9 --Apple-Mail-19--943057476 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 v2.0.9 (Darwin) iEYEARECAAYFAkqC7eUACgkQK/tq6CJjZQL1uQCeLsKgsGzIGcuRUpRfzcYRD093 xI0An1PI2cX29Uin06tMMIIiy8n14I9p =c9bD -----END PGP SIGNATURE----- --Apple-Mail-19--943057476-- -- to unsubscribe send a message to namedroppers-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 Aug 12 09:46: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 E1DD73A6C02; Wed, 12 Aug 2009 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bdCh57QMbGW; Wed, 12 Aug 2009 09:46:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA68B3A68BE; Wed, 12 Aug 2009 09:46:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbGtz-0009fi-Ni for namedroppers-data0@psg.com; Wed, 12 Aug 2009 16:42:15 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbGtu-0009fA-VG for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 16:42:13 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 16AE2327A92; Wed, 12 Aug 2009 16:42:10 +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 462ED327A78; Wed, 12 Aug 2009 16:42:09 +0000 (UTC) Message-ID: <4A82F0E0.8040702@isc.org> Date: Wed, 12 Aug 2009 11:42:08 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Olafur Gudmundsson CC: Doug Otis , William Allen Simpson , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> <4A81A69D.1060103@gmail.com> <200908121549.n7CFnUM2014742@stora.ogud.com> In-Reply-To: <200908121549.n7CFnUM2014742@stora.ogud.com> 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 Olafur Gudmundsson wrote: > At 13:13 11/08/2009, Doug Otis wrote: >> The goal would be to have SCTP support all DNS traffic and have it >> attempted first. Delays caused by timeouts due to blocked UDP >> responses are avoided, as are spoofed reflected attacks. SCTP also >> better ensures responses are protected from spoofed poisoning. > > > Who's goal? > IMHO SCTP is being proposed as an alternative to TCP not UDP. Additionally, who has done the study to see which middleware boxes and firewalls will allow SCTP though? Really, are we deciding that it is more likely that these broken things will pass unknown IP protocols when they won't pass fragments? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqC8OAACgkQ+NNi0s9NRJ2YNgCggMkvEvbDtj/M7nZDZsxRn4aA pwkAnAlKYlIWA+iXm2fQXNiKQV0n9Jc0 =zBlc -----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 Aug 12 11:25: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 3787928C0D9; Wed, 12 Aug 2009 11:25:12 -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 EPfsP-lcp98d; Wed, 12 Aug 2009 11:25:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0468D28C0E2; Wed, 12 Aug 2009 11:25:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbIQv-000N23-Lp for namedroppers-data0@psg.com; Wed, 12 Aug 2009 18:20:21 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:918c] (helo=out-66.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbIQq-000N0g-JH for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 18:20:18 +0000 Received: from smtp-13.smtp.ucla.edu (smtp-13.smtp.ucla.edu [169.232.46.240]) by out-66.smtp.ucla.edu with ESMTP id n7CIJZgE030841; Wed, 12 Aug 2009 11:19:35 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-13.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7CIJZgE030841; Wed, 12 Aug 2009 11:19:35 -0700 Received: from dhcp35.cs.colostate.edu (dhcp35.cs.colostate.edu [129.82.44.235]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7CIJYKE021172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 11:19:34 -0700 Cc: Olafur Gudmundsson , Doug Otis , William Allen Simpson , namedroppers@ops.ietf.org Message-Id: From: Eric Osterweil To: Michael Graff In-Reply-To: <4A82F0E0.8040702@isc.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25--936452801" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice Date: Wed, 12 Aug 2009 12:19:30 -0600 References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> <4A81A69D.1060103@gmail.com> <200908121549.n7CFnUM2014742@stora.ogud.com> <4A82F0E0.8040702@isc.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25--936452801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 12, 2009, at 10:42 AM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Olafur Gudmundsson wrote: >> At 13:13 11/08/2009, Doug Otis wrote: >>> The goal would be to have SCTP support all DNS traffic and have it >>> attempted first. Delays caused by timeouts due to blocked UDP >>> responses are avoided, as are spoofed reflected attacks. SCTP also >>> better ensures responses are protected from spoofed poisoning. >> >> >> Who's goal? >> IMHO SCTP is being proposed as an alternative to TCP not UDP. > > Additionally, who has done the study to see which middleware boxes and > firewalls will allow SCTP though? > > Really, are we deciding that it is more likely that these broken =20 > things > will pass unknown IP protocols when they won't pass fragments? fwiw, Michael sounds exactly right to me. I think the SCTP discussion =20= could very likely cause more unforeseen problems than anyone is =20 anticipating. It's a very dramatic change that involves a huge number =20= of unknown quantities for DNS. Eric =E9 --Apple-Mail-25--936452801 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 v2.0.9 (Darwin) iEYEARECAAYFAkqDB7IACgkQK/tq6CJjZQLCCACfZnB3mJOlcacLU4Z5kmWjrg+s wWIAn1YPBi1pvDQ0dh75ZsuYs0wFtfl4 =xudZ -----END PGP SIGNATURE----- --Apple-Mail-25--936452801-- -- to unsubscribe send a message to namedroppers-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 Aug 12 12:16: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 8810E3A6AA3; Wed, 12 Aug 2009 12:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=-1.563, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEVf8QHXlXNX; Wed, 12 Aug 2009 12:16:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B5F73A6942; Wed, 12 Aug 2009 12:16:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbJFN-0005br-Ov for namedroppers-data0@psg.com; Wed, 12 Aug 2009 19:12:29 +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 1MbJFK-0005bT-Bh for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 19:12:27 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CFD8CA94453; Wed, 12 Aug 2009 19:12:23 +0000 (UTC) Message-ID: <4A831417.2050307@mail-abuse.org> Date: Wed, 12 Aug 2009 12:12:23 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Olafur Gudmundsson CC: Doug Otis , William Allen Simpson , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 2, practice References: <4A805F92.4060703@gmail.com> <4A80744E.5080400@gmail.com> <4A808820.7010205@gmail.com> <4A81A69D.1060103@gmail.com> <200908121549.n7CFnUM2014742@stora.ogud.com> In-Reply-To: <200908121549.n7CFnUM2014742@stora.ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8/12/09 8:49 AM, Olafur Gudmundsson wrote: > At 13:13 11/08/2009, Doug Otis wrote: > >>>> When SCTP is not supported, the fallback would be to UDP and then TCP. >>> >>> Actually, since SCTP would only be the fallback from UDP, that would >>> only leave TCP. >> >> The goal would be to have SCTP support all DNS traffic and have it >> attempted first. Delays caused by timeouts due to blocked UDP >> responses are avoided, as are spoofed reflected attacks. SCTP also >> better ensures responses are protected from spoofed poisoning. > > > Who's goal? > IMHO SCTP is being proposed as an alternative to TCP not UDP. In general, concerns related to UDP EDNS0@4096 are in regard to network amplification, timeouts due to transit failures, and perhaps increased poisoning risks. When a path does not support requisite PMTUs, there could be issues related to overwhelming reassembly during DoS events or increased glue exposure, since fragments are easier to spoof. Advantages envisioned for SCTP over TCP is an ability to automatically manage persistent associations effectively, which minimizes initialization and PMTU overheads. This transport can also efficiently handle multiple DNS messages without significant change to DNS. SCTP is not expected to initially provide comprehensive solutions for everyone. By attempting SCTP first, customers of the providers that offer this transport can then improve service latency and security from out-of-path poisoning, while also better protecting their networks from congestion. SCTP also support TLS. Caching non-support of SCTP should allow reversion to legacy behaviors that immediately attempt UDP, and fallback to TCP. While SCTP may not have been implemented equally in every case, it should compare well with TCP in respect to initial exchanges. When TCP's sequence number contains a secret hash validation, this also means TCP options can not be accepted and where server secrets therefore impact SCTP equally. The multi-homing feature of SCTP should not be used with DNS in general deployments. This could lead to vulnerabilities within environments where IP addresses are reassigned for mobility, for example. Proper support for multi-homing suggests one-way hashes of tie-tags should be exchanged within the Cookie State, instead of actual tie-tags. Tie-tags are mandated by SCTP to resolve race conditions, but the RFC, as yet, does not recommend obscuring tie-tags, nor offer a method for doing so. Multi-homing also mandates common port assignments which is problematic within IPv4. For general deployment of SCTP, multi-homing should not be used. In effect, this means calling bind() before sendmsg(). BTW. This should eliminate William's concern related to INIT or INIT-ACK exceeding PMTUs. The SCTP socket API does not appear to specify an error, which makes William's complaint valid, but this should not impact DNS. -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 Aug 12 14:54: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 E001F3A6ECE; Wed, 12 Aug 2009 14:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 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 lTpN+iCnSUc9; Wed, 12 Aug 2009 14:54:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4EE53A6EB3; Wed, 12 Aug 2009 14:54:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbLgS-000NHV-W1 for namedroppers-data0@psg.com; Wed, 12 Aug 2009 21:48: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 1MbLgI-000NGz-Ll for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 21:48: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 B41DCE609B; Wed, 12 Aug 2009 21:48: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 n7CLmMU1003203; Thu, 13 Aug 2009 07:48:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908122148.n7CLmMU1003203@drugs.dv.isc.org> To: Matt Larson Cc: Namedroppers Mailing List From: Mark Andrews References: <3efd34cc0908100952j442b7650t3231553004c21dd5@mail.gmail.com> <200908110010.n7B0AvDR060945@drugs.dv.isc.org> <20090812050546.GJ1348@dul1mcmlarson-l1-2.local> <200908120536.n7C5a79k091897@drugs.dv.isc.org> <20090812143737.GB1960@dul1mcmlarson-l1-2.local> Subject: Re: [dnsext] NSEC3 confusion (in .org) In-reply-to: Your message of "Wed, 12 Aug 2009 10:37:38 -0400." <20090812143737.GB1960@dul1mcmlarson-l1-2.local> Date: Thu, 13 Aug 2009 07:48:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090812143737.GB1960@dul1mcmlarson-l1-2.local>, Matt Larson writes : > On Wed, 12 Aug 2009, Mark Andrews wrote: > > In message <20090812050546.GJ1348@dul1mcmlarson-l1-2.local>, Matt Larson = > writes > > > On Tue, 11 Aug 2009, Mark Andrews wrote: > > > > No. Just your assumption is false. NS RRsets are removed > > > > by registrars without the glue records beneath them also > > > > being removed for spam and other network abuse issues. This > > > > causes the glue to become authoritative data. > > > >=20 > > > > The same thing happens in COM, NET and I presume all other > > > > zones with a registry/registrar model. The registrars > > > > really should be pulling the glue records as well. It's > > > > up to the registry enforce this however. > > >=20 > > > That is not correct. At least in .com and .net, the registry business > > > logic prevents a domain from being deleted if name servers (i.e., host > > > objects in the registry database that result in glue A or AAAA RRs in > > > the zone) under that domain still exist. E.g., a registrar must first > > > delete the name server "ns.foo.com" before deleting the domain > > > "foo.com". > >=20 > > I wasn't talking about a delegation being deleted. Note I qualified > > the removal based on "spam and other network abuse issues". > > Hold statuses are administrative and are most often used for > non-technical reasons. Domains go on hold for "spam and other network > abuse issues" rarely, if ever, in .com/.net. (But note that putting a > domain on hold for that reason would have to be initiated by the > registrar.) > > I took issue with your ascribing fault to the registrars and the > registries for the glue remaining in the zone. This issue is out of > control of the registrars, who would be unable to remove the name > servers of a domain on hold because of another business rule: a name > server can't be removed if it is associated with any domains, i.e., > has a non-zero reference count. So it's not realistic to expect that > registrars could ensure no authoritative glue remained of on-hold > domains. > > =46rom the registry perspective, it's not a clear-cut issue: there is a > good case to be made either way for promoting name servers (A/AAAA > RRs) of on-hold domains to authoritative data (or not). I think the > current .com/.net behavior of promotion is reasonable, but I also > think DNSSEC is a good justification for changing the behavior. > > The dwindling DNS protocol content in this thread probably puts it out > of scope soon (if not already)... Yep. It doesn't really matter why, just acknowledging that it occurs is enough for this answering the original question. Mark > 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 runyont5@pousadacanoeiros.com.br Wed Aug 12 15:55: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 71BF528C139; Wed, 12 Aug 2009 15:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, 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, 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 jlw++2zYaj+8; Wed, 12 Aug 2009 15:55:29 -0700 (PDT) Received: from ppp079166239117.dsl.hol.gr (ppp079166239117.dsl.hol.gr [79.166.239.117]) by core3.amsl.com (Postfix) with ESMTP id B028E28C136; Wed, 12 Aug 2009 15:55:28 -0700 (PDT) Received: from 79.166.239.117 by mx.cluster001.whservidor.com; Thu, 13 Aug 2009 01:54:37 +0200 Message-ID: <000d01ca1b9f$de063820$6400a8c0@runyont5> From: Esperanza Cowan To: Subject: Acai Berry fights Cancer , Increases energy and burns fat. Date: Thu, 13 Aug 2009 01:54:37 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1B9F.DE063820" 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_01CA1B9F.DE063820 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 Can't see=20 this email? VIEW IN BROWSER =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Threat Information and=20 Product News for Customers =20 =20 =20 =20 =20 =20 =20 =20 =20 In this Issue: =20   =20 =20 Product=20 NewsLose Weight and Feel Great Free =A0 Click doubtless =20 =20 =20 =20 =20 We appreciate your interest in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to = our mailing=20 list. =20 =20 =A0 =20 Copyright=20 2009 Oswejf, Incorporated. All rights reserved. All other product=20 orcompany names may be trademarks or registered trademarks of their=20 owners. =A0 ------=_NextPart_000_0007_01CA1B9F.DE063820 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ca= n't see=20 this email? VIEW IN BROWSER
=
Threat Information an= d=20 Product News for Customers
In this Issue:<= /TD>
 
Product=20 News

Lose Weight and Feel Great Fre= e
=A0
Click doubtless
<= /TD>
We appreciate your inter= est in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to our mailing=20 list.
=A0
Copyright=20 2009 Oswejf, Incorporated. All rights reserved. All other product=20 or
company names may be trademarks or registered trademarks of the= ir=20 owners.
=A0
------=_NextPart_000_0007_01CA1B9F.DE063820-- From owner-namedroppers@ops.ietf.org Wed Aug 12 16:38: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 C87913A6AE9; Wed, 12 Aug 2009 16:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, J_CHICKENPOX_53=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 95ePo1-UyEEQ; Wed, 12 Aug 2009 16:38:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF9F83A6900; Wed, 12 Aug 2009 16:38:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbNIh-0007eO-Ko for namedroppers-data0@psg.com; Wed, 12 Aug 2009 23:32:11 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbNIc-0007d8-Ha for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 23:32: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 42D8AE606E; Wed, 12 Aug 2009 23: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 n7CNVxpY004298; Thu, 13 Aug 2009 09:32:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908122332.n7CNVxpY004298@drugs.dv.isc.org> To: Eric Osterweil Cc: Paul Vixie , William Allen Simpson , namedroppers@ops.ietf.org From: Mark Andrews References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <200908112350.n7BNoSY7089617@drugs.dv.isc.org> <17E79345-9F95-4673-8B02-D6F9EF04CE24@cs.ucla.edu> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-reply-to: Your message of "Wed, 12 Aug 2009 09:50:39 CST." <17E79345-9F95-4673-8B02-D6F9EF04CE24@cs.ucla.edu> Date: Thu, 13 Aug 2009 09:31:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <17E79345-9F95-4673-8B02-D6F9EF04CE24@cs.ucla.edu>, Eric Osterweil writes: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --Apple-Mail-15--945383664 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > Content-Transfer-Encoding: quoted-printable > > > On Aug 11, 2009, at 5:50 PM, Mark Andrews wrote: > > > > > In message <87474.1250029811@nsa.vix.com>, Paul Vixie writes: > >> > > > > >> > >> none of us consider these badly implemented middleboxes to be =20 > >> repairable sinc > >> e > >> they are all over the internet now and many of their manufacturers =20= > > >> are out of > >> business and many of their original installers/operators are =20 > >> retired or dead. > > > > > > > > > The client advertises a 4096 byte EDNS UDP size option, the CPE the > > advertises a 1460 byte EDNS UDP size option when it "forwards" the > > packet. The reply with a 4096 byte EDNS UDP size will then be able > > to be processed by the CPE equipment, when the reply is forwarded > > to the original client the CPE will put the miniumum of the received > > EDNS UDP size and its buffer size in the EDNS UDP size returned to > > the original client. > > You know, rather than trying to imagine how middleboxes can be made to =20= > help, we could just talk about the relatively simple fix of letting =20 > resolvers discover the buffer size that works for them. afaict, we =20 > still have control over resolver software ("we" meaning those resolver =20= > maintainers on the list). This would allow resolvers to advertise the =20= > proper sizes and it would allow _them_ to keep state if different =20 > buffer sizes were needed for different paths. This ought to be =20 > possible with fewer RTTs than TCP and certainly fewer than SCTP. > > Hop-by-hop rewrite is a slippery slope. If we really needed it, that =20= > would be one thing, but I think it's quite unnecessary here, and =20 > likely infeasible anyway. So you don't think we should log bug reports with the vendors of products which advertise themselves as being recursive DNS servers but fail to perform correctly in that role? How about those that don't support DNS over TCP? Fixing the resolver to use optimal UDP sizes won't fix that problem. If I remember Ray's report there were a number of vendors that stuffed up TCP. The vendors of these boxes need to be held accountable. I've got a NETGEAR WGR614v6 (firmware V2.0.19_1.0.19NA) wireless router which doesn't do either of these things correctly. Should I log a fault report or not? For the record the EDNS problem is logged as case 9937612 and the TCP problem is logged as case 9937776. Mark > Eric -- 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 Aug 12 17:51: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 1975E3A6B07; Wed, 12 Aug 2009 17:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 meM64x-GiKKz; Wed, 12 Aug 2009 17:51:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0F813A67F3; Wed, 12 Aug 2009 17:51:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbORX-000Fim-Mr for namedroppers-data0@psg.com; Thu, 13 Aug 2009 00:45:23 +0000 Received: from [2607:f010:3fe:302:1013:72ff:fe5b:6032] (helo=out-31.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbORP-000Fi7-84 for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 00:45:21 +0000 Received: from smtp-6.smtp.ucla.edu (smtp-6.smtp.ucla.edu [169.232.48.241]) by out-31.smtp.ucla.edu with ESMTP id n7D0j3Oh029661; Wed, 12 Aug 2009 17:45:04 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-6.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7D0j3Oh029661; Wed, 12 Aug 2009 17:45:03 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7D0j0sc020249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 17:45:01 -0700 Cc: Paul Vixie , William Allen Simpson , namedroppers@ops.ietf.org Message-Id: From: Eric Osterweil To: Mark Andrews In-Reply-To: <200908122332.n7CNVxpY004298@drugs.dv.isc.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-14--913327252" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Wed, 12 Aug 2009 18:44:55 -0600 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <200908112350.n7BNoSY7089617@drugs.dv.isc.org> <17E79345-9F95-4673-8B02-D6F9EF04CE24@cs.ucla.edu> <200908122332.n7CNVxpY004298@drugs.dv.isc.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.241 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-14--913327252 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 12, 2009, at 5:31 PM, Mark Andrews wrote: > > In message <17E79345-9F95-4673-8B02-D6F9EF04CE24@cs.ucla.edu>, Eric =20= > Osterweil writes: >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --Apple-Mail-15--945383664 >> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed; =20 >> delsp=3Dyes >> Content-Transfer-Encoding: quoted-printable >> >> >> On Aug 11, 2009, at 5:50 PM, Mark Andrews wrote: >> >>> >>> In message <87474.1250029811@nsa.vix.com>, Paul Vixie writes: >>>> >> >> >> >>>> >>>> none of us consider these badly implemented middleboxes to be =3D20 >>>> repairable sinc >>>> e >>>> they are all over the internet now and many of their =20 >>>> manufacturers =3D20=3D >> >>>> are out of >>>> business and many of their original installers/operators are =3D20 >>>> retired or dead. >>> >> >> >> >>> >>> The client advertises a 4096 byte EDNS UDP size option, the CPE the >>> advertises a 1460 byte EDNS UDP size option when it "forwards" the >>> packet. The reply with a 4096 byte EDNS UDP size will then be able >>> to be processed by the CPE equipment, when the reply is forwarded >>> to the original client the CPE will put the miniumum of the received >>> EDNS UDP size and its buffer size in the EDNS UDP size returned to >>> the original client. >> >> You know, rather than trying to imagine how middleboxes can be made =20= >> to =3D20=3D >> help, we could just talk about the relatively simple fix of letting =20= >> =3D20 >> resolvers discover the buffer size that works for them. afaict, we =20= >> =3D20 >> still have control over resolver software ("we" meaning those =20 >> resolver =3D20=3D >> maintainers on the list). This would allow resolvers to advertise =20= >> the =3D20=3D >> proper sizes and it would allow _them_ to keep state if different =3D20= >> buffer sizes were needed for different paths. This ought to be =3D20 >> possible with fewer RTTs than TCP and certainly fewer than SCTP. >> >> Hop-by-hop rewrite is a slippery slope. If we really needed it, =20 >> that =3D20=3D >> would be one thing, but I think it's quite unnecessary here, and =3D20 >> likely infeasible anyway. > > So you don't think we should log bug reports with the vendors of > products which advertise themselves as being recursive DNS servers > but fail to perform correctly in that role? Hey Mark, I don't think namedroppers is a bug-report list... is it? ;) Of course you should report these things, but I don't think that =20 holding one's breath for a flag-day when everyone patches is a good =20 plan. > > > How about those that don't support DNS over TCP? Fixing the resolver > to use optimal UDP sizes won't fix that problem. If I remember > Ray's report there were a number of vendors that stuffed up TCP. If you don't fallback to TCP because of overzealous 512 queries, you =20 might be just fine. If a middlebox doesn't support TCP it should be =20 fixed. In the meantime, the e2e argument would seem to indicate that =20= the _ends_ should try to look after themselves. There's growing =20 evidence (which I'm happy to rehash here for the `n'th time if u =20 really want) that this is not only possible, but reasonably =20 straightforward in many cases. A few well chosen UDP queries (once =20 per name server at the cost of a little state), and often times you're =20= all set. > > > The vendors of these boxes need to be held accountable. Sure, but that is very clearly a separate argument. One which I do =20 not in any way object to. > > > I've got a NETGEAR WGR614v6 (firmware V2.0.19_1.0.19NA) wireless > router which doesn't do either of these things correctly. Should > I log a fault report or not? Nice flame bait. > > > For the record the EDNS problem is logged as case 9937612 and the > TCP problem is logged as case 9937776. Great, so are the fixes being belayed until the middleboxes are =20 fixed? I think _that_ would be a shame. Eric =E9 --Apple-Mail-14--913327252 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 v2.0.9 (Darwin) iEYEARECAAYFAkqDYgsACgkQK/tq6CJjZQJVOACgn5eupwMUJ9F/ph9NCa5hkYbz NLYAmgNP9RtNh8eIDI51px7WY1xjMTF2 =PzP6 -----END PGP SIGNATURE----- --Apple-Mail-14--913327252-- From owner-namedroppers@ops.ietf.org Thu Aug 13 06:02: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 139883A6A8F; Thu, 13 Aug 2009 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=-0.736, 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 KtfqbFuxp2G9; Thu, 13 Aug 2009 06:02:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA4443A68CD; Thu, 13 Aug 2009 06:02:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbZr0-000NuD-RI for namedroppers-data0@psg.com; Thu, 13 Aug 2009 12:56: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 1MbZqu-000Ntb-S3 for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 12:56: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 n7DCuImq024075 for ; Thu, 13 Aug 2009 08:56:18 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n7DCuI4U024074 for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 08:56:18 -0400 (EDT) (envelope-from namedroppers) Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbJoP-0009x0-VN for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 19:48:44 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MbJoG-00045w-1E for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 19:48:32 +0000 Received: from desk.marajade.sandelman.ca ([209.87.252.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Aug 2009 19:48:32 +0000 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Aug 2009 19:48:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Michael Richardson Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Wed, 12 Aug 2009 15:48:19 -0400 Lines: 27 Message-ID: <4A831C83.7030904@sandelman.ca> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) In-Reply-To: X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Ray.Bellis@nominet.org.uk wrote: > Paul, > > Please note that in the testing for SAC035 we experienced no significant > issues with _routing_ fragmented DNS packets through any of the > middleboxes[*]. All of them were able to forward fragmented responses > to the original client. FWIW - NAT and firewalling was enabled for > every test - the state simply wasn't a problem for them. > > The fragmentation problems were with the _proxies_ in those boxes, where > those proxies were only used because that's what their DHCP servers > offered. By "proxy", you mean the sort-a recursive resolvers that their DHCP servers offered? (some of them aren't really recursive resolvers, they just punt to the ISP, some of them can answer queries about ".local" though, ...) > So, in the SOHO case, yes, there are potential problems, but most of > them will only be evident iff an end user box is requesting large > responses (e.g. for DNSSEC validation) and the requests are directed at > their local SOHO gateway. If the end user is sending their DNS requests > directly to their ISP resolver they won't normally have _any_ problems > with UDP or EDNS0/4096. That is an interesting case of yet-again, the middle box is too smart for anyone's good. From owner-namedroppers@ops.ietf.org Thu Aug 13 08:14: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 4C0253A6ADA; Thu, 13 Aug 2009 08:14: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=[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 n50LZeWttzLf; Thu, 13 Aug 2009 08:14:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E5663A6AA4; Thu, 13 Aug 2009 08:14:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbbuz-000HST-7Z for namedroppers-data0@psg.com; Thu, 13 Aug 2009 15:08:41 +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 1Mbbuu-000HRX-Ae for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 15:08:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E0C63B28DC for ; Thu, 13 Aug 2009 15:08:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Wed, 12 Aug 2009 08:55:03 +0100." <617024FFDB8A38B36B2EE21D@nimrod.local> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 13 Aug 2009 15:08:35 +0000 Message-ID: <83721.1250176115@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: none of the analyses or even theories shown on this thread explain why edns0@4096 fails often enough that we have to fall back to edns0@1420 or even edns@512, except to bolster the case for "fragmentation is broken in a lot of places, and edns0 should not have depended on it." whether it's firewalls who can only forward udp first-frags that have port numbers, or proxies who don't speak edns at all, or IDS boxes who won't forward udp/53 if the payload size is larger than 512 or has a non-empty additional data section, doesn't matter as much as the basic fact that edns0's large-response mechanism isn't working. some folks who want dnssec are now proposing a way to make responses smaller, and this isn't because they want to save bytes on the wire, it's because large responses basically don't work. noting that there are other reasons why large responses could be valuable, i prefer another approach. but the need these folks feel further bolsters the case that edns0's large response mechanism isn't working. i'm not going to wade back in right now on why i don't consider tcp/53 a solution. i just thought i'd better summarize this thread in my own eyes which is to say, edns0's large-response mechanism isn't working, often enough that TLD operators who turn on dnssec see a surge in tcp traffic, often enough that some dnssec folks are trying to find ways to make their messages smaller. none of these problems are in the endpoints, it's all boxes in the middle who are causing these problems. From owner-namedroppers@ops.ietf.org Thu Aug 13 08:42: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 EFF713A6968; Thu, 13 Aug 2009 08:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-1.035, 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 3t4k4jINPPRc; Thu, 13 Aug 2009 08:42:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB5D93A6AA4; Thu, 13 Aug 2009 08:42:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbcKz-000Kbl-Jw for namedroppers-data0@psg.com; Thu, 13 Aug 2009 15:35:33 +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 1MbcKu-000Kb3-AY for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 15:35:30 +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 1MbcKq-0001AH-Os; Thu, 13 Aug 2009 17:35:24 +0200 Received: by bfk.de with local id 1MbcKq-0002lU-Lj; Thu, 13 Aug 2009 15:35:24 +0000 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> From: Florian Weimer Date: Thu, 13 Aug 2009 15:35:24 +0000 In-Reply-To: <83721.1250176115@nsa.vix.com> (Paul Vixie's message of "Thu\, 13 Aug 2009 15\:08\:35 +0000") Message-ID: <82eirfsp4z.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Paul Vixie: > i'm not going to wade back in right now on why i don't consider tcp/53 a > solution. i just thought i'd better summarize this thread in my own eyes > which is to say, edns0's large-response mechanism isn't working, often > enough that TLD operators who turn on dnssec see a surge in tcp traffic, This is just based on a single TLD's experience which had implemented not one, but two peculiar configuration choices, right? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Thu Aug 13 08: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 07D313A6968; Thu, 13 Aug 2009 08: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=[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 MPrmM+tG201v; Thu, 13 Aug 2009 08:44:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 049463A6882; Thu, 13 Aug 2009 08:44:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbcOt-000L4g-7h for namedroppers-data0@psg.com; Thu, 13 Aug 2009 15:39:35 +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 1MbcOp-000L4B-0M for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 15:39:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AA146B2905; Thu, 13 Aug 2009 15:39:30 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Thu, 13 Aug 2009 15:35:24 GMT." <82eirfsp4z.fsf@mid.bfk.de> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <82eirfsp4z.fsf@mid.bfk.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 13 Aug 2009 15:39:30 +0000 Message-ID: <85064.1250177970@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Florian Weimer > Date: Thu, 13 Aug 2009 15:35:24 +0000 > > > i'm not going to wade back in right now on why i don't consider tcp/53 > > a solution. i just thought i'd better summarize this thread in my own > > eyes which is to say, edns0's large-response mechanism isn't working, > > often enough that TLD operators who turn on dnssec see a surge in tcp > > traffic, > > This is just based on a single TLD's experience which had implemented > not one, but two peculiar configuration choices, right? dunno. can we get summaries of tld experiences posted here? From owner-namedroppers@ops.ietf.org Thu Aug 13 09:03: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 505CD3A6A76; Thu, 13 Aug 2009 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 8HDFoh3EikBd; Thu, 13 Aug 2009 09:03:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E8AB3A69E9; Thu, 13 Aug 2009 09:03:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbchP-000NyH-2j for namedroppers-data0@psg.com; Thu, 13 Aug 2009 15:58:43 +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 1MbchL-000NxS-4o for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 15:58: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 640A02FE9634 for ; Thu, 13 Aug 2009 15:58:37 +0000 (UTC) Date: Thu, 13 Aug 2009 11:58:35 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Message-ID: <20090813155835.GM18463@shinkuro.com> References: <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <82eirfsp4z.fsf@mid.bfk.de> <85064.1250177970@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85064.1250177970@nsa.vix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 13, 2009 at 03:39:30PM +0000, Paul Vixie wrote: > > dunno. can we get summaries of tld experiences posted here? Your friendly neighbourhodd moderator notes that this (like some other recent threads) is drifting precariously close to discussions of operations, and there is another working group to discuss those issues. In this case, I don't object because it's desirable input to discussions of whether we need protocol work to add a transport option for DNS. Just let's please not drift too far from protocol changes, ok? Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 13 09:20: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 99A843A69A3; Thu, 13 Aug 2009 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[AWL=-1.129, 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 6+bsFCQUJJVe; Thu, 13 Aug 2009 09:20:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6066E3A696D; Thu, 13 Aug 2009 09:20:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbcxj-000Q05-DJ for namedroppers-data0@psg.com; Thu, 13 Aug 2009 16:15:35 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbcxe-000PzY-1L; Thu, 13 Aug 2009 16:15:32 +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=q/gWf2C6IdRDUJ/MFe4CRqSTetGlTF7cRqJ5kx9CuglxPLSmWhcdRSzK wIVK//EyHPJGJjEowa+UzmrVXHvvaq7ybjvN5/bxqdPAqwU/LmpAIOfzd 6xf3l80bVJNTxzP; 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=1250180130; x=1281716130; 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]=20DNS=20over=20SCTP=20problems,=20part=201,=20theory |Date:=20Thu,=2013=20Aug=202009=2017:15:22=20+0100 |Message-ID:=20|To:=20Paul=20Vixie=20|Cc:=20namedroppers@ops.ietf.org,=0D=0A=09own er-namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<83721.1250176115@nsa.vix.com> |References:=20<4A80453B.1000203@gmail.com>=20<8560.12499 22543@nsa.vix.com>=20<4A80685A.1080104@gmail.com>=20 =20<4A817D6E.9040202@gmail.com>=20<87474.1250029811@nsa.v ix.com>=20<1B6540C99B25F4995938FACE@nimrod.local>=20<8241 .1250060733@nsa.vix.com>=20=20<617024FFDB8A38B36B2EE21D@n imrod.local>=20<83721.1250176115@nsa.vix.com>; bh=IwFa1uSw+3vN4Mv1mpLXblnGsWGcohm2w55YHGbZaJk=; b=r7griAGDDt6CsnfNAah+DZvviCxyYLnfrfmLv00gUCaQp788fTxkrEqj RkBQtCVckutSxXhqrvNhlTEZLIKEaYReVw2+xa8KUBk7NNuvtAhkziXWG CW7wRaEfHEL0pWO; X-IronPort-AV: E=Sophos;i="4.43,375,1246834800"; d="scan'208";a="12197958" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 13 Aug 2009 17:15:25 +0100 In-Reply-To: <83721.1250176115@nsa.vix.com> References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 13 Aug 2009 17:15:22 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 13/08/2009 05:15:27 PM, Serialize complete at 13/08/2009 05:15:27 PM Content-Type: multipart/alternative; boundary="=_alternative 00594BAD80257611_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 00594BAD80257611_= Content-Type: text/plain; charset="US-ASCII" > none of the analyses or even theories shown on this thread explain why > edns0@4096 fails often enough that we have to fall back to edns0@1420 > or even edns@512, except to bolster the case for "fragmentation is > broken in a lot of places, and edns0 should not have depended on it." I for one really would like to know why EDNS0 @ 4096 apparently doesn't work in same cases (per Eric's research) and be able to explain it. I already know why for the SOHO middlebox case, but to be honest that's not really a big problem (IMHO) for most DNS packets. Those users can probably bypass their SOHO DNS proxies without too much effort. what we don't have is an explanation for the potential causes further inside the enterprise / ISP network. If anyone would like to help me research that (Eric, Nick W ?) I'm up for it. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 00594BAD80257611_= Content-Type: text/html; charset="US-ASCII"
> none of the analyses or even theories shown on this thread explain why
> edns0@4096 fails often enough that we have to fall back to edns0@1420
> or even edns@512, except to bolster the case for "fragmentation is
> broken in a lot of places, and edns0 should not have depended on it."
I for one really would like to know why EDNS0 @ 4096 apparently doesn't work in same cases (per Eric's research) and be able to explain it.

I already know why for the SOHO middlebox case, but to be honest that's not really a big problem (IMHO) for most DNS packets.  Those users can probably bypass their SOHO DNS proxies without too much effort.

what we don't have is an explanation for the potential causes further inside the enterprise / ISP network.

If anyone would like to help me research that (Eric, Nick W ?) I'm up for it.

Ray

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


 --=_alternative 00594BAD80257611_=-- From owner-namedroppers@ops.ietf.org Thu Aug 13 09:22: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 1975B3A6B0D; Thu, 13 Aug 2009 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 l1WGMBb0CmKw; Thu, 13 Aug 2009 09:22:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D80A13A6804; Thu, 13 Aug 2009 09:22:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbd2M-0000Zg-2o for namedroppers-data0@psg.com; Thu, 13 Aug 2009 16:20:22 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:956f] (helo=out-71.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbd2F-0000YB-Mw for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 16:20:18 +0000 Received: from smtp-14.smtp.ucla.edu (smtp-14.smtp.ucla.edu [169.232.46.241]) by out-71.smtp.ucla.edu with ESMTP id n7DGJkAC014343; Thu, 13 Aug 2009 09:19:50 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.158]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7DGJkAC014343; Thu, 13 Aug 2009 09:19:46 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7DGJiCC024023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2009 09:19:46 -0700 Cc: namedroppers@ops.ietf.org Message-Id: From: Eric Osterweil To: Paul Vixie In-Reply-To: <83721.1250176115@nsa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-17--857243131" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Thu, 13 Aug 2009 10:19:39 -0600 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.241 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-17--857243131 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 13, 2009, at 9:08 AM, Paul Vixie wrote: > none of the analyses or even theories shown on this thread explain why > edns0@4096 fails often enough that we have to fall back to edns0@1420 > or even edns@512, except to bolster the case for "fragmentation is > broken in a lot of places, and edns0 should not have depended on it." > > > whether it's firewalls who can only forward udp first-frags that =20 > have port > numbers, or proxies who don't speak edns at all, or IDS boxes who =20 > won't > forward udp/53 if the payload size is larger than 512 or has a non-=20 > empty > additional data section, doesn't matter as much as the basic fact that > edns0's large-response mechanism isn't working. Hey Paul, I've previously mentioned my analyses that directly speak to this. =20 Rather than rehash them all, take a look at this one figure (as the =20 most concise example I can think of to make): http://secspider.cs.ucla.edu/doc/pmtu-poller.pdf This is one figure from the presentation I gave at RIPE 58. This =20 shows (among other things), that EDNS0 is (in fact) working. Many of =20= the queries that fail w/ buffer sizes of 4096 would work just fine =20 with EDNS0 over UDP if the buffer size were more cluefully set. There =20= are, of course, some that don't. These numbers do vary by location, =20 and some locations show far less trouble than others. So, I don't =20 think it's reasonable or even true to say "none of the analyses" have =20= addressed this. Further, this single graph refutes the absolute =20 statement that EDNS0 is broken. There is a path to addressing this problem, and it doesn't have to be =20= anywhere near as drastic as starting with SCTP. > > > > some folks who want dnssec are now proposing a way to make responses > smaller, and this isn't because they want to save bytes on the wire, =20= > it's > because large responses basically don't work. Not true. Sometimes there are problems, but often it is possible to =20 overcome them. > noting that there are other > reasons why large responses could be valuable, i prefer another =20 > approach. > but the need these folks feel further bolsters the case that edns0's =20= > large > response mechanism isn't working. I strongly disagree based on what I've said above. > > > i'm not going to wade back in right now on why i don't consider tcp/=20= > 53 a > solution. i just thought i'd better summarize this thread in my own =20= > eyes > which is to say, edns0's large-response mechanism isn't working, often > enough that TLD operators who turn on dnssec see a surge in tcp =20 > traffic, I suspect (and would love to try and verify with data) that this has =20 something to do with an overly aggressive fallback to 512. This does =20= not have to happen, and can (likely) be addresses on the resolver side. > > often enough that some dnssec folks are trying to find ways to make =20= > their > messages smaller. none of these problems are in the endpoints, it's =20= > all > boxes in the middle who are causing these problems. The same could be said for network congestion, but the endpoints have =20= been pretty successful addressing it with back-offs. I mention this =20 only cite precedence for successfully addressing path problems at the =20= ends. Eric =E9 --Apple-Mail-17--857243131 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 v2.0.9 (Darwin) iEYEARECAAYFAkqEPR8ACgkQK/tq6CJjZQKcpACffz3cCHr9bxZRTv6A71X63re9 SlAAn03ZvxhC+H744QC+5us+1xQtmE2Q =0eVx -----END PGP SIGNATURE----- --Apple-Mail-17--857243131-- From owner-namedroppers@ops.ietf.org Thu Aug 13 09:58: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 3FC913A693F; Thu, 13 Aug 2009 09:58:52 -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 2udE3QSfgHnp; Thu, 13 Aug 2009 09:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E1323A6A71; Thu, 13 Aug 2009 09:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbdZG-0004gR-Iy for namedroppers-data0@psg.com; Thu, 13 Aug 2009 16:54:22 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbdZC-0004fy-4M for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 16:54:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A6221B2923 for ; Thu, 13 Aug 2009 16:54:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-Reply-To: Your message of "Thu, 13 Aug 2009 10:19:39 CST." References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 13 Aug 2009 16:54:17 +0000 Message-ID: <88219.1250182457@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Eric Osterweil > Date: Thu, 13 Aug 2009 10:19:39 -0600 > ... > http://secspider.cs.ucla.edu/doc/pmtu-poller.pdf > > This is one figure from the presentation I gave at RIPE 58. This shows > (among other things), that EDNS0 is (in fact) working. Many of the > queries that fail w/ buffer sizes of 4096 would work just fine with EDNS0 > over UDP if the buffer size were more cluefully set. "more cluefully"? if edns0 at 4096 is not working, then is fragmentation at fault? if there's a "more cluefully" that would make it all work, then shouldn't we be working on 2671-bis rather than dnssec-algo-signal? > There is a path to addressing this problem, and it doesn't have to be > anywhere near as drastic as starting with SCTP. based on florian's and william's explainations i now understand that sctp has too many moving parts, is not mature, and may not be secure by design. > Sometimes there are problems, but often it is possible to overcome them. is this a recommendation that work be done on 2671-bis rather than on alternative transports or dnssec-algo-signal? From owner-namedroppers@ops.ietf.org Thu Aug 13 10:08: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 F356628C118; Thu, 13 Aug 2009 10:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5dqjRomj-8d; Thu, 13 Aug 2009 10:08:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B37A428C11A; Thu, 13 Aug 2009 10:08:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbdjO-0005tW-00 for namedroppers-data0@psg.com; Thu, 13 Aug 2009 17:04:50 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbdjK-0005sy-7I for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 17:04:48 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 841B0327A7C for ; Thu, 13 Aug 2009 17:04:45 +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 ADD77327A3B for ; Thu, 13 Aug 2009 17:04:44 +0000 (UTC) Message-ID: <4A8447AC.5080108@isc.org> Date: Thu, 13 Aug 2009 12:04:44 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] Soft Packet Size Limit (was: DNS over SCTP problems, part 1, theory) References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.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: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've always thought the edns0 buffer size option was in fact too limiting. It's a single hard limit. What I mean is, if a client says "I can handle 4096 bytes" the server feels this is great, and will happily add all glue and other bits in to make it as large as it can given data it knows. This seems OK from a protocol point of view, but I think it makes some analysis of what is currently seen "in the wild" suspect. For instance, suppose a query to a ORG server resulted in a 3000 byte packet. The question I have here is what is the SMALLEST size this response would have fit into, if only the data essential to the query at hand were included? I think we can all agree that smaller means "more likely to make it to the client." Perhaps a lot of this packet size issue can be solved by better responder behavior. A server might consider the ENDS0 as the upper bounds, but try to keep the response below some soft threshold, say 1400 bytes. The number is not critical for this discussion, just that there is a number. This means the server might need to decide between different types of additional data to include rather than just "first-found." Some glue is necessary for certain queries, for instance, but the associated A records for the query name might not be quite as urgent. The goal here is to make it more likely to get stuff through. If this were done, an EDNS0 option could be added to say "I know I have a clean path, set my soft limit to 4096, really." This would be used for people who really know what they are doing, and really do have things set up properly and are willing to ensure it remains working. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqER6wACgkQ+NNi0s9NRJ28hACeNTiZlzEjE8dH4msm4UL8LnIf QooAmQGySDIq2AcixAKLKmjtQjt5bkvY =ZCpq -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 13 10: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 6BD4928C152; Thu, 13 Aug 2009 10:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.119 X-Spam-Level: X-Spam-Status: No, score=-5.119 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 PqXJ05694fha; Thu, 13 Aug 2009 10:26:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4422F28C151; Thu, 13 Aug 2009 10:26:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbdzy-0007iH-RR for namedroppers-data0@psg.com; Thu, 13 Aug 2009 17:21:58 +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 1Mbdzv-0007hh-3w; Thu, 13 Aug 2009 17:21: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 n7DHLlgJ021492; Thu, 13 Aug 2009 10:21:48 -0700 (PDT) Cc: Nicholas Weaver , Paul Vixie , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Message-Id: 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 v936) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Thu, 13 Aug 2009 13:21:47 -0400 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 13, 2009, at 12:15 PM, Ray.Bellis@nominet.org.uk wrote: > > > none of the analyses or even theories shown on this thread explain > why > > edns0@4096 fails often enough that we have to fall back to > edns0@1420 > > or even edns@512, except to bolster the case for "fragmentation is > > broken in a lot of places, and edns0 should not have depended on > it." > > I for one really would like to know why EDNS0 @ 4096 apparently > doesn't work in same cases (per Eric's research) and be able to > explain it. > > I already know why for the SOHO middlebox case, but to be honest > that's not really a big problem (IMHO) for most DNS packets. Those > users can probably bypass their SOHO DNS proxies without too much > effort. Not if you want DNSSEC to really work, since DNSSEC really working requires that the validation occur at the stub resolver. > what we don't have is an explanation for the potential causes > further inside the enterprise / ISP network. > > If anyone would like to help me research that (Eric, Nick W ?) I'm > up for it. There are the following possible failure cases: 1) A middlebox or firewall blocks UDP fragments. 1') A middlebox or firewall which is active on DNS does not reassemble fragments. 2) A middlebox or firewall which is active on DNS assumes that DNS <= 512B 3) A middlebox or firewall which is active on DNS does not understand and blocks EDNS Testing in Netalyzr showed that for recursive resolvers which claim EDNS and support for EDNS>2000B, case 1 or 1' (we can't tell the difference [1]) occurs on the path between the recursive resolver and UC Berkeley for roughly 15% of the tested recursive resolvers, with case 2 or 3 being a very slim minority. For end users, its still roughly 15% failure, but 2/3rds are 1 or 1', 1/3rd is case 2 or 3, well, roughly speaking. [1] We could theoretically tell the difference between 1 and 1' for the end user if we added a test for generic UDP fragments, but this would not work for the resolver themselves as we can't test the resolver's ability to process arbitrary UDP, only DNS packets. From owner-namedroppers@ops.ietf.org Thu Aug 13 11:18: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 F164F3A6CFE; Thu, 13 Aug 2009 11:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 8MpkK8oY2tuo; Thu, 13 Aug 2009 11:18:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC4043A67AA; Thu, 13 Aug 2009 11:18:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbepF-000ENO-4b for namedroppers-data0@psg.com; Thu, 13 Aug 2009 18:14:57 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:956f] (helo=out-71.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbep8-000EMI-Pb for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 18:14:54 +0000 Received: from smtp-14.smtp.ucla.edu (smtp-14.smtp.ucla.edu [169.232.46.241]) by out-71.smtp.ucla.edu with ESMTP id n7DIEFwD017264; Thu, 13 Aug 2009 11:14:15 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.158]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7DIEFwD017264; Thu, 13 Aug 2009 11:14:15 -0700 Received: from [192.168.0.3] (c-98-245-169-210.hsd1.co.comcast.net [98.245.169.210]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7DIEEdq003556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2009 11:14:15 -0700 Cc: namedroppers@ops.ietf.org Message-Id: <0BB96977-4DB8-488E-88C0-95B3D24D6185@cs.ucla.edu> From: Eric Osterweil To: Michael Graff In-Reply-To: <4A8447AC.5080108@isc.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-21--850373422" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Soft Packet Size Limit (was: DNS over SCTP problems, part 1, theory) Date: Thu, 13 Aug 2009 12:14:09 -0600 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <4A8447AC.5080108@isc.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.241 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-21--850373422 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 13, 2009, at 11:04 AM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've always thought the edns0 buffer size option was in fact too > limiting. It's a single hard limit. What I mean is, if a client says > "I can handle 4096 bytes" the server feels this is great, and will > happily add all glue and other bits in to make it as large as it can > given data it knows. > > This seems OK from a protocol point of view, but I think it makes some > analysis of what is currently seen "in the wild" suspect. For =20 > instance, > suppose a query to a ORG server resulted in a 3000 byte packet. The > question I have here is what is the SMALLEST size this response would > have fit into, if only the data essential to the query at hand were > included? I think we can all agree that smaller means "more likely to > make it to the client." > > Perhaps a lot of this packet size issue can be solved by better > responder behavior. A server might consider the ENDS0 as the upper > bounds, but try to keep the response below some soft threshold, say =20= > 1400 > bytes. The number is not critical for this discussion, just that =20 > there > is a number. > > This means the server might need to decide between different types of > additional data to include rather than just "first-found." Some =20 > glue is > necessary for certain queries, for instance, but the associated A > records for the query name might not be quite as urgent. The goal =20 > here > is to make it more likely to get stuff through. > > If this were done, an EDNS0 option could be added to say "I know I =20 > have > a clean path, set my soft limit to 4096, really." This would be used > for people who really know what they are doing, and really do have > things set up properly and are willing to ensure it remains working. Or the resolver could just more accurately represent what buffer size =20= is likely to make it, and the name server can continue to be simple/=20 fast. Rather than have the name server guess what might fit, it might be =20 better to keep the protocol's current expressiveness, but teach =20 resolvers not to false-advertise to the name severs. Again, this =20 ought to be doable in a very few RTTs and a small constant increase in =20= the state that resolvers currently keep. Eric =E9 --Apple-Mail-21--850373422 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 v2.0.9 (Darwin) iEYEARECAAYFAkqEV/UACgkQK/tq6CJjZQI5hACdE9tFQiAu2IWe470DcP1/t1ty VEkAoIgj+qWTk20D0N4MpkdC0gQlH8M7 =Icw6 -----END PGP SIGNATURE----- --Apple-Mail-21--850373422-- From owner-namedroppers@ops.ietf.org Thu Aug 13 11:20: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 453E928C149; Thu, 13 Aug 2009 11:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.180, 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 w2lBnvTVXLVo; Thu, 13 Aug 2009 11:20:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D845D3A6D2A; Thu, 13 Aug 2009 11:20:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbes1-000Eil-6R for namedroppers-data0@psg.com; Thu, 13 Aug 2009 18:17:49 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mberx-000EiG-7T; Thu, 13 Aug 2009 18:17:46 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id DC9A0C2DA3; Thu, 13 Aug 2009 19:17:42 +0100 (BST) Date: Thu, 13 Aug 2009 19:15:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ray.Bellis@nominet.org.uk, Paul Vixie cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Message-ID: In-Reply-To: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 13 August 2009 17:15:22 +0100 Ray.Bellis@nominet.org.uk wrote: >> none of the analyses or even theories shown on this thread explain why >> edns0@4096 fails often enough that we have to fall back to edns0@1420 >> or even edns@512, except to bolster the case for "fragmentation is >> broken in a lot of places, and edns0 should not have depended on it." > > I for one really would like to know why EDNS0 @ 4096 apparently doesn't > work in same cases (per Eric's research) and be able to explain it. I'm guessing the /real/ question is why EDNS0@4096 apparently doesn't work but EDNS@1420 does. That goes to large packet support. EDNS@4096 might just fail through lack of EDNS support. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 13 12:05: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 E97243A6D07; Thu, 13 Aug 2009 12:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urcG7S-v6ngv; Thu, 13 Aug 2009 12:05:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12C33A6B9A; Thu, 13 Aug 2009 12:05:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbfWf-000JNC-En for namedroppers-data0@psg.com; Thu, 13 Aug 2009 18:59:49 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbfWb-000JMs-R8 for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 18:59:47 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 27A6F327A9B; Thu, 13 Aug 2009 18:59:45 +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 96C32327A96; Thu, 13 Aug 2009 18:59:44 +0000 (UTC) Message-ID: <4A8462A0.4070305@isc.org> Date: Thu, 13 Aug 2009 13:59:44 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Eric Osterweil CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Soft Packet Size Limit References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <4A8447AC.5080108@isc.org> <0BB96977-4DB8-488E-88C0-95B3D24D6185@cs.ucla.edu> In-Reply-To: <0BB96977-4DB8-488E-88C0-95B3D24D6185@cs.ucla.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: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Osterweil wrote: > Or the resolver could just more accurately represent what buffer size is > likely to make it, and the name server can continue to be simple/fast. Which is likely to happen this month, I wonder? :) - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqEYqAACgkQ+NNi0s9NRJ0hWQCeLAol+SaO4k748f202mwHKsil afwAnAjcEQeyOj5VpuI4MGItxRHL/xvG =UXdX -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 13 13:57: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 CF75D28C20D; Thu, 13 Aug 2009 13:57:37 -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 o5dpVWPBvWOU; Thu, 13 Aug 2009 13:57:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C479828C0E2; Thu, 13 Aug 2009 13:57:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbhG2-0004OF-Ez for namedroppers-data0@psg.com; Thu, 13 Aug 2009 20:50:46 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbhFy-0004Np-OC for namedroppers@ops.ietf.org; Thu, 13 Aug 2009 20:50:44 +0000 Received: (qmail 11497 invoked by uid 399); 13 Aug 2009 20:50:38 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 13 Aug 2009 20:50:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A847C98.4010302@dougbarton.us> Date: Thu, 13 Aug 2009 13:50:32 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> In-Reply-To: <83721.1250176115@nsa.vix.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Subscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Subscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Vixie wrote: > none of the analyses or even theories shown on this thread explain why > edns0@4096 fails often enough that we have to fall back to edns0@1420 > or even edns@512, except to bolster the case for "fragmentation is > broken in a lot of places, and edns0 should not have depended on it." My understanding for why 1420 might work when 4096 doesn't is that one or both of (bad) PMTUD or tunneling is the culprit. My understanding of why 512 works when nothing bigger works is that there are still a lot of legacy "firewalls" and/or nat devices that don't believe any answer coming back with greater than 512 bytes can be valid. I know we ran into this a lot when I was at Yahoo! to the extent that we hacked BIND to make sure our answers fit into 512 bytes. Not sure either of these issues are "news" (although I don't think anyone has mentioned PMTUD problems yet) but I mention them both to indicate why I am opposed to "solving" the "problem" with a new transport protocol. I don't see any chance that adding a new form of DNS transport will solve any of the existing problems given the origin of those problems. Before going any further though I would like to see a clear statement of the problem we're trying to solve. I've heard some vague references to "fallback to tcp is a problem" without data to back it up. That said, my past experience tells me that when deployment of DNSSEC becomes more widespread we _will_ see problems of a "packet too big" nature, at least partly because so many dns and/or network "administrators" have foolishly closed off tcp access for their name servers in spite of the efforts of those of us who are now blue in the face from telling people why that's a bad idea. My argument in response to that is that this is an _existing_ problem that will simply be made worse by DNSSEC, and needs to be solved anyway. More than 80% of the problem exists on the client/configuration side, and needs to be solved on the client side without any protocol changes. In regards to actual protocol stuff, I agree with those who have said that making EDNS packet size backoff more intelligent is the way to move forward NOW, regardless of how large the tcp fallback problem turns out to be (or how long it takes to get data on it). Since we already know that EDNS isn't working as we had hoped, and since I imagine there would be general agreement that we would like to keep as much traffic on udp as we can, making EDNS work better solves both problems we can see, and ones we can't (yet). In the absence of anything more specific on either end, some sort of process like: 1. Try 4096, if that doesn't work 2. Try 2048, if that doesn't work 3. Try 1420, if that doesn't work 4. Stick with 512 The number for 2 is arbitrarily proposed at 4096/2 for strawman purposes. It would be interesting to see how large a "larger than average" packet is really going to be in the DNSSEC world, and if there is a more intelligent value between 4096 and 1420 that really is useful. If not, we could eliminate step 2 altogether. The 1420 number is my understanding of the largest number that will safely avoid problems with both PMTUD and tunnels. Those more knowledgeable about those topics are welcome to suggest a different number. hope this helps, Doug From owner-namedroppers@ops.ietf.org Thu Aug 13 16:57: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 D9FB428C1A3; Thu, 13 Aug 2009 16:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.376 X-Spam-Level: X-Spam-Status: No, score=-4.376 tagged_above=-999 required=5 tests=[AWL=-1.078, 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 DL98RtzYf7PY; Thu, 13 Aug 2009 16:57:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B835528C1AC; Thu, 13 Aug 2009 16:57:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbk3c-0000Wc-NB for namedroppers-data0@psg.com; Thu, 13 Aug 2009 23:50:08 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbk3W-0000Vl-Ig; Thu, 13 Aug 2009 23:50:04 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=IgsKiam3emovOiYT31xCATjsNJnu2Zkt+Kj4mAg6CrmYEO9J/h3p7GBS 69M9SvbzamzPHuzDmTeZKMAt8tfL1xhAsd71WGYq2X1I4r+bxgplG0tFC ijC9kIOGhk3nBHW; 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=1250207402; x=1281743402; 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]=20DNS=20over=20SCTP=20problems,=20part=201,=20theory |Date:=20Fri,=2014=20Aug=202009=2000:49:52=20+0100 |Message-ID:=20|To:=20Nicholas=20Weaver =20|Cc:=20namedroppers@ops.iet f.org,=0D=0A=09Nicholas=20Weaver=20,=0D=0A=09owner-namedroppers@ops.ietf.org,=0D=0A=09P aul=20Vixie=20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20<4A80453B.1000203@gmail.com >=20<8560.1249922543@nsa.vix.com>=20<4A80685A.1080104@gma il.com>=20=20<4A817D6E.9040202@gmail.com>=20<87474.125 0029811@nsa.vix.com>=20<1B6540C99B25F4995938FACE@nimrod.l ocal>=20<8241.1250060733@nsa.vix.com>=20=20<617024FFDB8A3 8B36B2EE21D@nimrod.local>=20<83721.1250176115@nsa.vix.com >=20=20; bh=Vv/xdmUQbTtn0n4Bbp608jwXwgRg3J53OhMTgfJYhDw=; b=3CW9Ks7wfa3Uri9lZHA35+Ja6kNU5bPzXnxZwfK7CQfZCZZ2zgarkVkD jPpXuRVK1wd5Gs3h4Srvkd4aPlsB2Mxk9uUOrIMNU+Bqk2zIjYkR53hk4 gJk30nqzN3+7GWD; X-IronPort-AV: E=Sophos;i="4.43,377,1246834800"; d="scan'208";a="12202329" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 14 Aug 2009 00:49:54 +0100 In-Reply-To: References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> To: Nicholas Weaver Cc: namedroppers@ops.ietf.org, Nicholas Weaver , owner-namedroppers@ops.ietf.org, Paul Vixie Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 14 Aug 2009 00:49:52 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 14/08/2009 12:49:59 AM, Serialize complete at 14/08/2009 12:49:59 AM Content-Type: multipart/alternative; boundary="=_alternative 0082E87780257611_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0082E87780257611_= Content-Type: text/plain; charset="US-ASCII" > Not if you want DNSSEC to really work, since DNSSEC really working > requires that the validation occur at the stub resolver. Agreed. > There are the following possible failure cases: > > 1) A middlebox or firewall blocks UDP fragments. > > 1') A middlebox or firewall which is active on DNS does not reassemble > fragments. > > 2) A middlebox or firewall which is active on DNS assumes that DNS <= > 512B > > 3) A middlebox or firewall which is active on DNS does not understand > and blocks EDNS > > .... > > [1] We could theoretically tell the difference between 1 and 1' for > the end user if we added a test for generic UDP fragments, but this > would not work for the resolver themselves as we can't test the > resolver's ability to process arbitrary UDP, only DNS packets. SAC035 results were 100% success for 1, and ~50% for 1', admittedly only on a sample of 24 SOHO units. Ray --=_alternative 0082E87780257611_= Content-Type: text/html; charset="US-ASCII"
> Not if you want DNSSEC to really work, since DNSSEC really working  
> requires that the validation occur at the stub resolver.

Agreed.

> There are the following possible failure cases:
>
> 1) A middlebox or firewall blocks UDP fragments.
>
> 1') A middlebox or firewall which is active on DNS does not reassemble  
> fragments.
>
> 2) A middlebox or firewall which is active on DNS assumes that DNS <=  
> 512B
>
> 3) A middlebox or firewall which is active on DNS does not understand  
> and blocks EDNS
>
> ....
>
> [1] We could theoretically tell the difference between 1 and 1' for  
> the end user if we added a test for generic UDP fragments, but this  
> would not work for the resolver themselves as we can't test the  
> resolver's ability to process arbitrary UDP, only DNS packets.
SAC035 results were 100% success for 1, and ~50% for 1', admittedly only on a sample of 24 SOHO units.

Ray

--=_alternative 0082E87780257611_=-- From owner-namedroppers@ops.ietf.org Thu Aug 13 17:38: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 164D43A6976; Thu, 13 Aug 2009 17:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 R1O1YbUqJ8w3; Thu, 13 Aug 2009 17:37:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3018A3A67B8; Thu, 13 Aug 2009 17:37:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbkkW-0004ps-W2 for namedroppers-data0@psg.com; Fri, 14 Aug 2009 00:34:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbkkT-0004pY-4a for namedroppers@ops.ietf.org; Fri, 14 Aug 2009 00:34: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 3744FE606E; Fri, 14 Aug 2009 00:34:24 +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 n7E0YKKR061830; Fri, 14 Aug 2009 10:34:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908140034.n7E0YKKR061830@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-reply-to: Your message of "Thu, 13 Aug 2009 17:15:22 +0100." Date: Fri, 14 Aug 2009 10:34:19 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Ray.Bellis@nominet.org.uk writes: > > none of the analyses or even theories shown on this thread explain why > > edns0@4096 fails often enough that we have to fall back to edns0@1420 > > or even edns@512, except to bolster the case for "fragmentation is > > broken in a lot of places, and edns0 should not have depended on it." > > I for one really would like to know why EDNS0 @ 4096 apparently doesn't > work in same cases (per Eric's research) and be able to explain it. > > I already know why for the SOHO middlebox case, but to be honest that's > not really a big problem (IMHO) for most DNS packets. Those users can > probably bypass their SOHO DNS proxies without too much effort. > > what we don't have is an explanation for the potential causes further > inside the enterprise / ISP network. > > If anyone would like to help me research that (Eric, Nick W ?) I'm up for > it. Overly conservative or not conservative enough firewall vendors basically explain the firewall things. If firewall vendors examined the queries then EDNS would not have passed out through the firewall and there would be no problem with EDNS replies. Firewall vendors would have had presure put on them to support EDNS and it would have been planned support. Instead firewall vendors only examined the replies which is what caused the problems. The allowed EDNS out without allowing EDNS in. Now we are in the state were that lack of checking is causing issues and everyone want the issues resolved *NOW*. If we (resolver vendors) just leave this alone the middleware (SOHO and Firewall) vendors will fix their boxes or have new boxes without the problem. The problem boxes will be upgraded/replaced. Yes it will take a few years. EDNS hasn't failed. It just hasn't been on the middle box verdors radar up until now. We just need to make it more present on their radar. We (IETF) needs to start dialogs with the DSL and Cable Forums, as most of the vendors involved here will be members of one or other of those forums, to point out how a common faults in their products are causing real problems. Mark > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Aug 13 18:00: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 85D043A6C90; Thu, 13 Aug 2009 18:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 VDe8ed8B5gga; Thu, 13 Aug 2009 18:00:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 949A43A6BB0; Thu, 13 Aug 2009 18:00:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbl5D-0006eP-95 for namedroppers-data0@psg.com; Fri, 14 Aug 2009 00:55:51 +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 1Mbl59-0006du-LO for namedroppers@ops.ietf.org; Fri, 14 Aug 2009 00:55:49 +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 C65F5E609B; Fri, 14 Aug 2009 00:55: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 n7E0thmc061957; Fri, 14 Aug 2009 10:55:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908140055.n7E0thmc061957@drugs.dv.isc.org> To: Eric Osterweil Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-reply-to: Your message of "Thu, 13 Aug 2009 10:19:39 CST." Date: Fri, 14 Aug 2009 10:55:42 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Eric Osterweil w rites: > I suspect (and would love to try and verify with data) that this has > something to do with an overly aggressive fallback to 512. This does > not have to happen, and can (likely) be addresses on the resolver side. There isn't time to add more fallback steps to recursive servers as they need to do all this probing within the stub resolver timeout. For stub resolvers there should be the ability to try EDNS@1400 and EDNS@1200 as the stub resolver controls the timeout. Note servers can also impose their own limits on the EDNS response sizes. Cable and DSL vendors could configure their recursive servers to not send answers that exceed the ethernet sizes to their recursive clients. This is really a workaround until CPE equipment is upgraded. With a bit more intelligence they could use a IDS and tune this on a per customer basis. They already do this sort of thing for other services by looking at the vendor codes in the ethernet MAC. They get it wrong sometimes which is how I know they do this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Aug 13 18:03:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C061F3A6C90; Thu, 13 Aug 2009 18:03:28 -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 ELiU6YvBZEtM; Thu, 13 Aug 2009 18:03:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0A263A6C6F; Thu, 13 Aug 2009 18:03:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MblAE-0007FJ-7y for namedroppers-data0@psg.com; Fri, 14 Aug 2009 01:01: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 1MblAA-0007Eq-FY for namedroppers@ops.ietf.org; Fri, 14 Aug 2009 01:01:00 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n7E10miY002617; Thu, 13 Aug 2009 18:00:52 -0700 (PDT) Cc: Nicholas Weaver , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <60725924-FFF6-416F-8C7B-5EE6D81C865E@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Doug Barton In-Reply-To: <4A847C98.4010302@dougbarton.us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Thu, 13 Aug 2009 21:00:49 -0400 References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <4A847C98.4010302@dougbarton.us> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 13, 2009, at 4:50 PM, Doug Barton wrote: > Paul Vixie wrote: >> none of the analyses or even theories shown on this thread explain >> why >> edns0@4096 fails often enough that we have to fall back to edns0@1420 >> or even edns@512, except to bolster the case for "fragmentation is >> broken in a lot of places, and edns0 should not have depended on it." > > My understanding for why 1420 might work when 4096 doesn't is that one > or both of (bad) PMTUD or tunneling is the culprit. > > My understanding of why 512 works when nothing bigger works is that > there are still a lot of legacy "firewalls" and/or nat devices that > don't believe any answer coming back with greater than 512 bytes can > be valid. I know we ran into this a lot when I was at Yahoo! to the > extent that we hacked BIND to make sure our answers fit into 512 > bytes. Its not PMTUD, its "inability to handle fragments". DNS UDP is generally not sent with DF set, so it will fragment just fine, just as soon as it hits the ethernet. And 85% of the measured cases will reassemble the fragments quite happily. Its just some device in path either can't handle fragments at all, or wants to handle DNS but can't handle fragmented DNS packets. > In the absence of anything more specific on either end, some sort of > process like: > 1. Try 4096, if that doesn't work > 2. Try 2048, if that doesn't work Skip this. If 4096 fails, it is because of SOME process that won't like anything bigger than the de-facto Internet MTU defined by Ethernet. The problem in most cases (for resolvers) occurs when packet fragmentation begins. > 3. Try 1420, if that doesn't work > 4. Stick with 512 > > The number for 2 is arbitrarily proposed at 4096/2 for strawman > purposes. It would be interesting to see how large a "larger than > average" packet is really going to be in the DNSSEC world, and if > there is a more intelligent value between 4096 and 1420 that really is > useful. If not, we could eliminate step 2 altogether. The 1420 number > is my understanding of the largest number that will safely avoid > problems with both PMTUD and tunnels. Those more knowledgeable about > those topics are welcome to suggest a different number. > > > hope this helps, > > Doug > From owner-namedroppers@ops.ietf.org Thu Aug 13 18:30: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 6D95328C135; Thu, 13 Aug 2009 18:30:42 -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 sui+nD4yPVPc; Thu, 13 Aug 2009 18:30:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 995C628C0FF; Thu, 13 Aug 2009 18:30:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MblZP-0009wk-Ce for namedroppers-data0@psg.com; Fri, 14 Aug 2009 01:27:03 +0000 Received: from [209.85.146.178] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MblZK-0009vd-Gr for namedroppers@ops.ietf.org; Fri, 14 Aug 2009 01:27:00 +0000 Received: by wa-out-1112.google.com with SMTP id j37so172291waf.9 for ; Thu, 13 Aug 2009 18:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+C5RYFGSOudwMYAVYAtfbCX4aoZpo4BRiZ+iec306o4=; b=H2+XJDUy9xvPXqvFN3QsT0zEbw+Ho3o0+ncMUSCQjicnkCKKEsuywGnjEztckzjMeg q+0jDybfAZrnzrnL8H42sVb2R41GL4zT+dwW1t5o/Cjd2Egb2zuTIxCXI6Bnlv1W5JTQ 1sGvbD+633rj83JyAdv+/mF5RtDj/tof5l9RY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dvBjMWTP23ZbSsicrYY0OpJs5C4FdprDVDbfSomPeVuEL12Ha7iW0k4qFL2rRuYmOH +4U+XMczobLCWqQC6FQk95/598kPri9ocZCSXeODUzhJFmhyeK2o6TqwTyb00unmOxwi OJSOmXsMpqVtZkSmNGHPN1M0QyzDneUscg42s= Received: by 10.115.117.13 with SMTP id u13mr1424004wam.150.1250213217252; Thu, 13 Aug 2009 18:26:57 -0700 (PDT) Received: from SJC-Office-NAT-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id j15sm1285209waf.16.2009.08.13.18.26.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Aug 2009 18:26:56 -0700 (PDT) Message-ID: <4A84BD5D.5030202@gmail.com> Date: Thu, 13 Aug 2009 18:26:53 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <200908140034.n7E0YKKR061830@drugs.dv.isc.org> In-Reply-To: <200908140034.n7E0YKKR061830@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/13/09 5:34 PM, Mark Andrews wrote: > If firewall vendors examined the queries then EDNS would not have > passed out through the firewall and there would be no problem with > EDNS replies. Firewall vendors would have had presure put on them > to support EDNS and it would have been planned support. > > Instead firewall vendors only examined the replies which is what > caused the problems. The allowed EDNS out without allowing EDNS > in. > > Now we are in the state were that lack of checking is causing issues > and everyone want the issues resolved *NOW*. If we (resolver > vendors) just leave this alone the middleware (SOHO and Firewall) > vendors will fix their boxes or have new boxes without the problem. > The problem boxes will be upgraded/replaced. Yes it will take a > few years. > > EDNS hasn't failed. It just hasn't been on the middle box verdors > radar up until now. We just need to make it more present on their > radar. Middleware with EDNS0@4096 is not only a problem. There are issues related to network amplifications, and whether fragmentation reassembly can endure potential abuses caused by UDP's lack of PMTU. In other words, EDNS0@4096 is not inherently safe, in addition to problems created by dependence upon the acceptance of jumbo frames. Ethernet frame size maximum is 1522 per IEEE 802.Q where the CRC polynomial suffers reduced error detection rates beyond this limit. Use of the CRC32c polynomial in SCTP restores detection rates for jumbo frames, while also ensuring detection is end-to-end, rather than NIC TO NIC where systems might inject errors caused by faulty bus drivers or memory modules. Lacking end-to-end protection leaves just the TCP or UDP checksums which fail to detect as much as 2% of the bus (bit specific) errors since they tend to self cancel. -Doug From listgreggregk@amsassociates.us Thu Aug 13 23:39: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 147833A6CDE for ; Thu, 13 Aug 2009 23:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.028 X-Spam-Level: X-Spam-Status: No, score=-22.028 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17pERHPpmAuG for ; Thu, 13 Aug 2009 23:39:30 -0700 (PDT) Received: from 242674hfc136.tampabay.res.rr.com (242674hfc136.tampabay.res.rr.com [24.26.74.136]) by core3.amsl.com (Postfix) with SMTP id 1630E3A69EC for ; Thu, 13 Aug 2009 23:39:28 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090814063929.1630E3A69EC@core3.amsl.com> Date: Thu, 13 Aug 2009 23:39:28 -0700 (PDT) Click here to view as a webpage. From owner-namedroppers@ops.ietf.org Fri Aug 14 13:52: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 145E03A67D2; Fri, 14 Aug 2009 13:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[AWL=-1.349, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwHiagLsOKKS; Fri, 14 Aug 2009 13:52:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B56D3A67D3; Fri, 14 Aug 2009 13:52:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mc3f4-0004Mm-Sa for namedroppers-data0@psg.com; Fri, 14 Aug 2009 20:46:06 +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 1Mc3f0-0004Ly-SV for namedroppers@ops.ietf.org; Fri, 14 Aug 2009 20:46:04 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Mc3et-0000O9-Rn; Fri, 14 Aug 2009 22:45:55 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Mc3et-0007V1-Cz; Fri, 14 Aug 2009 22:45:55 +0200 From: Florian Weimer To: Nicholas Weaver Cc: Doug Barton , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <4A847C98.4010302@dougbarton.us> <60725924-FFF6-416F-8C7B-5EE6D81C865E@ICSI.Berkeley.EDU> Date: Fri, 14 Aug 2009 22:45:55 +0200 In-Reply-To: <60725924-FFF6-416F-8C7B-5EE6D81C865E@ICSI.Berkeley.EDU> (Nicholas Weaver's message of "Thu, 13 Aug 2009 21:00:49 -0400") Message-ID: <87eire2kfw.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Nicholas Weaver: > DNS UDP is generally not sent with DF set, The picture is mixed. There's a lost of DF at the TLD and root level. End users typically use mainstream systems in more recent versions which generally don't set DF anymore. From owner-namedroppers@ops.ietf.org Fri Aug 14 15:35: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 AE36D3A6953; Fri, 14 Aug 2009 15:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 zCEvCRgctDE9; Fri, 14 Aug 2009 15:35:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4FDD3A682F; Fri, 14 Aug 2009 15:35:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mc5Hu-000GT8-Tu for namedroppers-data0@psg.com; Fri, 14 Aug 2009 22:30: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 1Mc5Hr-000GSY-8R for namedroppers@ops.ietf.org; Fri, 14 Aug 2009 22:30:17 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 98302E609C; Fri, 14 Aug 2009 22:30:13 +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 n7EMU9eg026329; Sat, 15 Aug 2009 08:30:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908142230.n7EMU9eg026329@drugs.dv.isc.org> To: Florian Weimer Cc: Nicholas Weaver , Doug Barton , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <4A847C98.4010302@dougbarton.us> <60725924-FFF6-416F-8C7B-5EE6D81C865E@ICSI.Berkeley.EDU> <87eire2kfw.fsf@mid.deneb.enyo.de> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory In-reply-to: Your message of "Fri, 14 Aug 2009 22:45:55 +0200." <87eire2kfw.fsf@mid.deneb.enyo.de> Date: Sat, 15 Aug 2009 08:30:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <87eire2kfw.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Nicholas Weaver: > > > DNS UDP is generally not sent with DF set, > > The picture is mixed. There's a lost of DF at the TLD and root level. > End users typically use mainstream systems in more recent versions > which generally don't set DF anymore. Only because OS vendors turned it on without thinking about the applications. Named turns it off it if can on a per socket basis. The only OS where it is on for UDP and named can't turn it off on a per socket basis that I am aware of is Solaris. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Sat Aug 15 00:09: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 807CA3A696F; Sat, 15 Aug 2009 00:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.005 X-Spam-Level: **** X-Spam-Status: No, score=4.005 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1M90i8kjk-5; Sat, 15 Aug 2009 00:09:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9E183A67E6; Sat, 15 Aug 2009 00:09:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McDGc-000L6I-4J for namedroppers-data0@psg.com; Sat, 15 Aug 2009 07:01:30 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McDGY-000L5y-EW for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 07:01:28 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1McDGW-0002mE-Od for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 08:01:24 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1McDGW-0003Lm-B2 for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 08:01:24 +0100 Message-ID: From: "George Barwood" To: Subject: [dnsext] Fragmentation undesirable Date: Sat, 15 Aug 2009 08:01:20 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: It seems to me that relying on IP fragmentation is undesirable, because it places unreasonable demands on low level infrastructure. To explain: when a computer receieves a message ( IP packet ), we want to be able to either process it, or reject it as bogus. It's undesirable to have to hold onto it until other messages arrive, as this will consume resources, which makes the computer vulnerable to denial of service (DoS) attacks. As far as I can see, fragmented IP packets inevitably consume resources, because low level infrastructure cannot determine if a fragment is valid or bogus. It's best to have protocols that do not imply a high level of resources to stop DoS attacks. Hence I suggest the IETF / IAB should consider deprecating the use of IP fragmentation in protocols when low level validation is not possible. This has implications for EDNS @ 4096. Note: in IPv6, the minimum MTU is 1280 bytes. George From owner-namedroppers@ops.ietf.org Sat Aug 15 05:29: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 95A383A6889; Sat, 15 Aug 2009 05:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.237 X-Spam-Level: **** X-Spam-Status: No, score=4.237 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W45hd6ZGFSJ0; Sat, 15 Aug 2009 05:29:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84D913A6E5B; Sat, 15 Aug 2009 05:29:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McIHL-00044Q-7V for namedroppers-data0@psg.com; Sat, 15 Aug 2009 12:22:35 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McIHE-00043b-Tk for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 12:22:32 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1McIHD-00070M-U6 for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 13:22:27 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1McIHA-0008UH-3R for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 13:22:24 +0100 Message-ID: <5722A99A87EA478BAC81D71ED194B500@localhost> From: "George Barwood" To: Subject: [dnsext] EDNS Page Option draft Date: Sat, 15 Aug 2009 13:22:19 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have submitted an internet draft http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-00.txt Abstract Describes an EDNS option to allow large DNS responses to be sent using small UDP packets. It differs from my original informal proposal: (1) An authentication mechanism is included. (2) A server cookie is used to pass process state information, giving maximum flexibility on the server side, and simplifying the client side. I hope this may be a basis for solving many of the DNS transport issues that have recently been discussed here. You comments would be very much apprciated. George From owner-namedroppers@ops.ietf.org Sat Aug 15 06:35: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 D9D693A6B65; Sat, 15 Aug 2009 06:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6ihvS7gfJff; Sat, 15 Aug 2009 06:35:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F8E23A6A61; Sat, 15 Aug 2009 06:35:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McJKg-000Bk7-81 for namedroppers-data0@psg.com; Sat, 15 Aug 2009 13:30:06 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McJKc-000BjH-8K for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 13:30:04 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id AF8D7C2DA5; Sat, 15 Aug 2009 14:29:59 +0100 (BST) Date: Sat, 15 Aug 2009 14:27:48 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <9FFAC887CC6EF10139B3044E@Ximines.local> In-Reply-To: <5722A99A87EA478BAC81D71ED194B500@localhost> References: <5722A99A87EA478BAC81D71ED194B500@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 15 August 2009 13:22:19 +0100 George Barwood wrote: > Describes an EDNS option to allow large DNS responses to be sent > using small UDP packets. ... > You comments would be very much apprciated. The data that the server would put in a reply may change between the initial request and the first followup request, and between each subsequent followup request. I presume the idea is that when the server issues a cookie, it also might memorise a snapshot of the response to be issued (or use some other cookie indexed mechanism to reconstruct it). That is going to use some memory on the server end, so there should be some indication how long it must keep possible responses to cookies, i.e. how long the cookie should be valid for. For instance, it is unreasonable to expect that a cookie should continue to work after 24 hours. Is there a possible DoS vector where application state memory is used up by issuing many initial requests (possibly with forged source addresses)? Latency of a query would be increased from RTT (for fragmented responses) to n x RTT, where n is the number of pages. I don't think that you avoid amplification DoS attacks in any case (except to the extent responses would be larger than 4096 bytes), as any server must support EDNS0@4096 as well as this, and a miscreant would simply make an EDNS0@4096 query without the page option. If it is the case that a resolver is going to ask for all the pages anyway (and I think this must be the most likely scenario), is there not a far simpler solution? The querying client provides a secret key (per your draft) which also indicates that it can accept paged replies, and the resolved sends all the pages back as a set of UDP packets, each with a page number, the total number of pages, and the secret key. The secret key retains the protection against blind spoofing, each looking like a DNS response packet. Yes, in an environment with p% packet loss, you end up with 1-(1-p)^n packet loss for n pages, (i.e. approximately n x p packet loss for small p); however n should hopefully not be large (to reach 4096 bytes anyway), and retries are possible. No state is kept on the server, and no cookies are necessary. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sat Aug 15 07:06: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 DD65A3A691A; Sat, 15 Aug 2009 07:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 3cpwrsm6XOkB; Sat, 15 Aug 2009 07:06:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E449F3A69FA; Sat, 15 Aug 2009 07:06:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McJq9-000Ejp-Dh for namedroppers-data0@psg.com; Sat, 15 Aug 2009 14:02: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 1McJq5-000EjH-M8 for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 14:02: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 n7FE2GTP015989; Sat, 15 Aug 2009 07:02:17 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , namedroppers@ops.ietf.org Message-Id: <283378D8-912F-4F42-9C66-C457305D7F4B@icsi.berkeley.edu> From: Nicholas Weaver To: Alex Bligh In-Reply-To: <9FFAC887CC6EF10139B3044E@Ximines.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Sat, 15 Aug 2009 07:02:16 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <9FFAC887CC6EF10139B3044E@Ximines.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 15, 2009, at 6:27 AM, Alex Bligh wrote: > > > --On 15 August 2009 13:22:19 +0100 George Barwood > wrote: > >> Describes an EDNS option to allow large DNS responses to be sent >> using small UDP packets. > ... >> You comments would be very much apprciated. > > The data that the server would put in a reply may change between the > initial request and the first followup request, and between each > subsequent > followup request. I presume the idea is that when the server issues a > cookie, it also might memorise a snapshot of the response to be > issued (or > use some other cookie indexed mechanism to reconstruct it). That is > going > to use some memory on the server end, so there should be some > indication > how long it must keep possible responses to cookies, i.e. how long the > cookie should be valid for. For instance, it is unreasonable to > expect that > a cookie should continue to work after 24 hours. Is there a possible > DoS > vector where application state memory is used up by issuing many > initial > requests (possibly with forged source addresses)? This does not have to be. There are two reasons the response could change: a) The data itself changed (in which case, the cookie is a timestamp on data freshness) b) The server deliberately gives out partial/different information each time because of a randomized algorithm. In this case, the cookie represents the seed state for the pRNG used to give out this particular instance of a response, which allows the server to reconstruct things comptelety. > Latency of a query would be increased from RTT (for fragmented > responses) > to n x RTT, where n is the number of pages. This I think is a mistake. Rather, there should be an EDNS0/EDNS1 where you have TWO parameters: the size of the response receivable (the current EDNS0 size) and the size of the PACKET receivable, and just fragment the response at user-level by splitting it into multiple UDP packets. And if you lose any single packet, oh well, you don't try for reliability and you'd conclude you need reliability so you fall back to TCP anyway. I agree that the paging strategy doesn't buy you anything over a UDP user-level fragmentation with one-shot delivery. From owner-namedroppers@ops.ietf.org Sat Aug 15 09:06: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 64A623A6DE1; Sat, 15 Aug 2009 09:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.053 X-Spam-Level: *** X-Spam-Status: No, score=3.053 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHlOsgCBcBUx; Sat, 15 Aug 2009 09:06:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CE453A68B6; Sat, 15 Aug 2009 09:06:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McLgY-0002g4-T9 for namedroppers-data0@psg.com; Sat, 15 Aug 2009 16:00:50 +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 1McLgU-0002cp-PB for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 16:00:48 +0000 Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1McLgT-0005bB-Lu; Sat, 15 Aug 2009 17:00:45 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1McLgT-0003oa-4E; Sat, 15 Aug 2009 17:00:45 +0100 Message-ID: <390B2BEE5A894828A2C75BAAC50D409A@localhost> From: "George Barwood" To: Cc: "Alex Bligh" References: <5722A99A87EA478BAC81D71ED194B500@localhost> <9FFAC887CC6EF10139B3044E@Ximines.local> Subject: Re: [dnsext] EDNS Page Option draft Date: Sat, 15 Aug 2009 17:00:40 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Alex Bligh" To: "George Barwood" ; Cc: "Alex Bligh" Sent: Saturday, August 15, 2009 2:27 PM Subject: Re: [dnsext] EDNS Page Option draft > > > --On 15 August 2009 13:22:19 +0100 George Barwood > wrote: > >> Describes an EDNS option to allow large DNS responses to be sent >> using small UDP packets. > ... >> You comments would be very much apprciated. > > The data that the server would put in a reply may change between the > initial request and the first followup request, and between each > subsequent > followup request. I presume the idea is that when the server issues a > cookie, it also might memorise a snapshot of the response to be issued That's one possibility, but there are others, e.g. reconstructing the response each time, and all sorts of hybrid strategies. > (or use some other cookie indexed mechanism to reconstruct it). That is > going > to use some memory on the server end, so there should be some indication > how long it must keep possible responses to cookies, i.e. how long the > cookie should be valid for. It's up to the server, however the cookie need not be valid for more than a few seconds, and if some event occurs, the server can restart the transfer. > For instance, it is unreasonable to expect that > a cookie should continue to work after 24 hours. Is there a possible DoS > vector where application state memory is used up by issuing many initial > requests (possibly with forged source addresses)? Yes, the server needs to guard against that, as mentioned in the Security section. "Servers should seek to minimise or eliminate per-client state, to mitigate DoS attacks." > Latency of a query would be increased from RTT (for fragmented responses) > to n x RTT, where n is the number of pages. I expect "n" not to exceed 2 in normal operation. That is, provided servers are sensible about sending unrequested NS RRsets - my suggestion is not to perform additional section processing for these. > I don't think that you avoid amplification DoS attacks in any case (except > to the extent responses would be larger than 4096 bytes), as any server > must support EDNS0@4096 as well as this, and a miscreant would simply make > an EDNS0@4096 query without the page option. A server under heavy attack may choose to not respond to such queries, that is to queries that do not have an EDNS Page option. That encourages clients to implement the EDNS Page option :) > If it is the case that a resolver is going to ask for all the pages anyway > (and I think this must be the most likely scenario), is there not a far > simpler solution? The querying client provides a secret key (per your > draft) which also indicates that it can accept paged replies, and the > resolved sends all the pages back as a set of UDP packets, each with a > page > number, the total number of pages, and the secret key. The secret key > retains the protection against blind spoofing, each looking like a DNS > response packet. Yes, in an environment with p% packet loss, you end up > with 1-(1-p)^n packet loss for n pages, (i.e. approximately n x p packet > loss for small p); however n should hopefully not be large (to reach 4096 > bytes anyway), and retries are possible. No state is kept on the server, > and no cookies are necessary. > > -- > Alex Bligh > From owner-namedroppers@ops.ietf.org Sat Aug 15 14:58: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 310433A6A2C; Sat, 15 Aug 2009 14:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.129, 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 p2oK5KLHEOS3; Sat, 15 Aug 2009 14:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 532DC3A6838; Sat, 15 Aug 2009 14:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McRBE-000NYw-8k for namedroppers-data0@psg.com; Sat, 15 Aug 2009 21:52:52 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McRBA-000NYB-J2 for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 21:52:50 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 78638C2DA5; Sat, 15 Aug 2009 22:52:46 +0100 (BST) Date: Sat, 15 Aug 2009 22:52:48 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , George Barwood , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <6E8FF2FD39404617F51D2230@nimrod.local> In-Reply-To: <283378D8-912F-4F42-9C66-C457305D7F4B@icsi.berkeley.edu> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <9FFAC887CC6EF10139B3044E@Ximines.local> <283378D8-912F-4F42-9C66-C457305D7F4B@icsi.berkeley.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 15 August 2009 07:02:16 -0700 Nicholas Weaver wrote: > This does not have to be. There are two reasons the response could > change: > > a) The data itself changed (in which case, the cookie is a timestamp on > data freshness) > > b) The server deliberately gives out partial/different information each > time because of a randomized algorithm. In this case, the cookie > represents the seed state for the pRNG used to give out this particular > instance of a response, which allows the server to reconstruct things > comptelety. I suppose the worst possible case is either the secondary of a large zone with a constant trickle of IXFR, or a TLD zone (or similar) built real time from a database, in each case where the average interval between changes is smaller than a reasonable maximum for RTT x 2 x a reasonable maximum of pages (i.e. where a change is likely across the few seconds it might take to sample). Clearly the cookie could be used as a timestamp here, but in order for a deterministic answer to be present, there is going to have to be a substantial change to the way the nameserver works. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sat Aug 15 16:52: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 EB21D3A6CEE; Sat, 15 Aug 2009 16:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.862 X-Spam-Level: ** X-Spam-Status: No, score=2.862 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bbEOZLFxZoy; Sat, 15 Aug 2009 16:52:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 172923A6CD1; Sat, 15 Aug 2009 16:52:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McSyK-0007yf-Jf for namedroppers-data0@psg.com; Sat, 15 Aug 2009 23:47:40 +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 1McSyF-0007y9-VO for namedroppers@ops.ietf.org; Sat, 15 Aug 2009 23:47:37 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1McSyD-000759-9m; Sun, 16 Aug 2009 00:47:33 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1McSyC-0005av-K4; Sun, 16 Aug 2009 00:47:32 +0100 Message-ID: From: "George Barwood" To: "Alex Bligh" , "Nicholas Weaver" Cc: "Nicholas Weaver" , , "Alex Bligh" References: <5722A99A87EA478BAC81D71ED194B500@localhost> <9FFAC887CC6EF10139B3044E@Ximines.local> <283378D8-912F-4F42-9C66-C457305D7F4B@icsi.berkeley.edu> <6E8FF2FD39404617F51D2230@nimrod.local> Subject: Re: [dnsext] EDNS Page Option draft Date: Sun, 16 Aug 2009 00:47:27 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Alex Bligh" To: "Nicholas Weaver" Cc: "Nicholas Weaver" ; "George Barwood" ; ; "Alex Bligh" Sent: Saturday, August 15, 2009 10:52 PM Subject: Re: [dnsext] EDNS Page Option draft > > > --On 15 August 2009 07:02:16 -0700 Nicholas Weaver > wrote: > >> This does not have to be. There are two reasons the response could >> change: >> >> a) The data itself changed (in which case, the cookie is a timestamp on >> data freshness) >> >> b) The server deliberately gives out partial/different information each >> time because of a randomized algorithm. In this case, the cookie >> represents the seed state for the pRNG used to give out this particular >> instance of a response, which allows the server to reconstruct things >> comptelety. > > I suppose the worst possible case is either the secondary of a large > zone with a constant trickle of IXFR, or a TLD zone (or similar) > built real time from a database, in each case where the average > interval between changes is smaller than a reasonable maximum for > RTT x 2 x a reasonable maximum of pages (i.e. where a change > is likely across the few seconds it might take to sample). For this scenario, servers could keep version information at the RRset level. Alternatively copies of changed RRsets, can be kept for a short period after an update, if there are outstanding EDNS Page transactions active on them. There are many possibilities. My guess is that in most cases a very simple approach will be adequate - e.g. simply restart outstanding transactions after an update. Page transactions should not very common : DNSKEY RRsets ( which are the obvious cause of large responses ) tend to be quite stable. A TLD only has a single DNSKEY RRset, so TLDs are not a bad case at all. Longer term, I don't doubt the ingenuity of programmers to come up with good solutions. Note: in the draft, the MAC is shown after the other data. This is an error : the MAC type (at least) should be adjacent to the secret key (maybe two copies : one before, one after), to reduce the possibility of fragmentation attacks. I will correct this in the next version. > Clearly the > cookie could be used as a timestamp here, but in order for > a deterministic answer to be present, there is going to have to > be a substantial change to the way the nameserver works. > > -- > Alex Bligh > From owner-namedroppers@ops.ietf.org Sat Aug 15 18:51: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 B31883A6C40; Sat, 15 Aug 2009 18:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRohrJA9se55; Sat, 15 Aug 2009 18:51:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DCF13A6C3C; Sat, 15 Aug 2009 18:51:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McUo6-000N6F-Pn for namedroppers-data0@psg.com; Sun, 16 Aug 2009 01:45:14 +0000 Received: from [2001:3c8:9009:181::2] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McUnz-000N4l-Mv for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 01:45:11 +0000 Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9009:181::2]) by jade.coe.psu.ac.th with ESMTP id n7G1ijdF014592; Sun, 16 Aug 2009 08:44:52 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id n7G1hTIR014669; Sun, 16 Aug 2009 08:44:07 +0700 (ICT) From: Robert Elz To: "George Barwood" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft In-Reply-To: <5722A99A87EA478BAC81D71ED194B500@localhost> References: <5722A99A87EA478BAC81D71ED194B500@localhost> Date: Sun, 16 Aug 2009 08:43:29 +0700 Message-ID: <8106.1250387009@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Date: Sat, 15 Aug 2009 13:22:19 +0100 From: "George Barwood" Message-ID: <5722A99A87EA478BAC81D71ED194B500@localhost> | I have submitted an internet draft | http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-00.txt I haven't been paying much attention to DNS drafts/rfcs recently, but I saw this one come past, and couldn't avboid taking a look. Sorry, but it is hard to imagine a worse proposal, this is just hopeless in almost every way. Let's start from the beginning ... 1. Introduction Large UDP packets are undesirable for 3 reasons: draft-barwood-dnsext-edns-page-option-00.txt (1) Although the IP protocol specifies a means by which large IP packets are split into fragments and then re-assembled, in practice this mechanism cannot be relied on, and large UDP packets may fail to be delivered Of course UDP packets may fail to be delivered, any IP packets may fail to be delivered - but fragmentation is (and always has been) a part of IP, if for some reason it cannot be relied upon, it needs to be fixed (even though it should be avoided where possible). (3) The large ratio between the request size and the response size allows malicious programs to mount "amplification" attacks. That is because of the nature of the DNS, your proposal does not affect that really (I guess it allows a victim to avoid asking for more responses after the first, when it is unknown, but the alternative is that now the served is hanging onto all that data waiting for some unspecified further time for the next request from the client, which is never going to arrive - if the server gives up too soon, then a legitimate request can never succeed). a DOS attack on a major DNS server is a far worse outsome than an amplification attack on some random node. (4) Re-assembling fragments requires buffer resources, which opens up denial of service attacks. That is not avoided by this, IP reassembly is still a required part of IP, you're just removing one legitimate client - unless you can remove every possible use of fragmentation, hosts still need to reassemble incoming datagrams. The resources used to reassemble the incoming DNS response will be approximately the same either weay (just spent in a different place), the big DNS reply still needs to be reassembled somewhere - this proposal will just take much longer to do it, so comsume the resources for longer. Instead, it is possible to use TCP, but this is undesirable, as TCP imposes significant overhead and state that is vulnerable to denial of service attack. Now you're trying to replace TCP as well - that makes no sense at all. There is little extra TCP state then your proposal requires, and TCP does its job far better and more effeciently. Please resist the temptation to attempt to invent alternatives to TCP, withoug a LOT of effort, they're almost all doomed to failure. The option includes an authentication mechanism that ensures that blind spoofing of the response is not possible. Just the DNS ID & question is reasonably good for that (though not perfect). I wouldn't really call what you have included as "authentication" either. 2. Protocol 2.1 Initial request The client signals support in it's initial request by including an EDNS Page option containing the following data: - Secret key length ( up to 16 bytes ) - Secret key It is sent in clear text, it is not a secret - this is what other protocols call a nonce, not a secret key. I cannot imagine why it needs the additional complication of being variable length, and if it is to be variable length, why the maximum length needs to be 16. 2.2 Server response The server responds with an EDNS Page option containing the following option data: - Secret key length - Secret key ( up to 16 bytes ) - Total response size ( 16 bits ) - Data offset ( 16 bits ) - Response data length ( 16 bits ) - Response data - Cookie length ( 1 byte ) - Cookie - MAC Type ( 1 byte ) - MAC Length ( 1 byte ) - MAC ( Message authentication code ) Obviously at some time the exact format of that would need to be specified, if this were to go forward (but hopefully that will never actually be needed). But ... The original Question is also sent. from this I assume that the question is in every answer fragment, which them makes the interpretation and reassembly of the reply harder - and adds to the overheads. The cookie has data that allows the server to send further data. Many different implementations are possible, and this document does not attempt to enumerate all these possibilities, except to note that allowance must be made for server updates and restarts. This limits the protocol to strict lock step, send one request, get one answer piece, send next request, get next piece, ... for long requests, with a remote server, that's going to mean perhaps 5 seconds or so (that's just 10 trips - assuming a 5K response, not very big, with a 500ms RTT which is just one satellite leg). That's absurd, TCP would be done and finished ages ago, and any rational client will have abandoned the request already. If you're looking for a way to kill DNSSEC, this would be it. 3. Security Considerations The secret key may expose internal state to an attacker who controls a name server. It is essential that a cryptographically strong source of random numbers be used to generate the secret key. This must be seeded from data that cannot be guessed by an attacker, such as thermal noise or other random physical fluctuations. And for clients that have no such source of randomness? Thay'r enot permitted to use this protocol? [RFC2181] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC 2181, August 1999. EDNS0 is not rfc2181. And de-facto is not "de factor" As a proposal, this isn't worth fixing, TCP is a much better solution to the problem. To make this workable, you'd need to allow the whole answer in one burst of packets (just like a fragmented UDP datagram), then if you want to be able to refetch just a part of the reply that was missed, you need just about all of TCP's mechanism to deal with it. Forget this proposal. kre From owner-namedroppers@ops.ietf.org Sat Aug 15 22:01: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 035023A6BCB; Sat, 15 Aug 2009 22:01: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 DjRxlpMnZKVs; Sat, 15 Aug 2009 22:01:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBF663A6B2E; Sat, 15 Aug 2009 22:01:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McXlN-000GD1-HV for namedroppers-data0@psg.com; Sun, 16 Aug 2009 04:54: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 1McXlI-000GCi-Uo for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 04:54:35 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4D4C0B2E6D for ; Sun, 16 Aug 2009 04:54:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft In-Reply-To: Your message of "Sun, 16 Aug 2009 08:43:29 +0700." <8106.1250387009@epsilon.noi.kre.to> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 16 Aug 2009 04:54:32 +0000 Message-ID: <35318.1250398472@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Robert Elz > Date: Sun, 16 Aug 2009 08:43:29 +0700 > > | I have submitted an internet draft > | http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-00.txt > > I haven't been paying much attention to DNS drafts/rfcs recently, > but I saw this one come past, and couldn't avboid taking a look. > > Sorry, but it is hard to imagine a worse proposal, this is just > hopeless in almost every way. > ... > Forget this proposal. +1. From owner-namedroppers@ops.ietf.org Sun Aug 16 00:19: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 A7D5F28C0D9; Sun, 16 Aug 2009 00:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.665 X-Spam-Level: *** X-Spam-Status: No, score=3.665 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WKmyFOqiKz5; Sun, 16 Aug 2009 00:19:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C1503A68A0; Sun, 16 Aug 2009 00:19:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McZvf-00047c-Ly for namedroppers-data0@psg.com; Sun, 16 Aug 2009 07:13:23 +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 1McZvW-00046e-7I for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 07:13:21 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1McZvU-0002C9-06; Sun, 16 Aug 2009 08:13:12 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1McZvP-0005Wa-3M; Sun, 16 Aug 2009 08:13:07 +0100 Message-ID: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> From: "George Barwood" To: "Robert Elz" Cc: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> Subject: Re: [dnsext] EDNS Page Option draft Date: Sun, 16 Aug 2009 08:13:01 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Robert Elz" To: "George Barwood" Cc: Sent: Sunday, August 16, 2009 2:43 AM Subject: Re: [dnsext] EDNS Page Option draft > > Date: Sat, 15 Aug 2009 13:22:19 +0100 > From: "George Barwood" > Message-ID: <5722A99A87EA478BAC81D71ED194B500@localhost> > > | I have submitted an internet draft > | http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-00.txt > > I haven't been paying much attention to DNS drafts/rfcs recently, > but I saw this one come past, and couldn't avboid taking a look. > > Sorry, but it is hard to imagine a worse proposal, this is just > hopeless in almost every way. I'm afraid your response is wrong in almost every point. Thanks for your interest, nevertheless, the fault may be mine, in that I probably did not sufficiently stress that the server can have no per-client state (which is the whole point of the design). I will fix that in the next draft. > Let's start from the beginning ... > > 1. Introduction > > Large UDP packets are undesirable for 3 reasons: > draft-barwood-dnsext-edns-page-option-00.txt > > (1) Although the IP protocol specifies a means by which large IP > packets are split into fragments and then re-assembled, in practice > this mechanism cannot be relied on, and large UDP packets may fail > to be delivered > > Of course UDP packets may fail to be delivered, any IP packets may > fail to be delivered - but fragmentation is (and always has been) a part > of IP, if for some reason it cannot be relied upon, it needs to be > fixed (even though it should be avoided where possible). The point is that the non-delivery is systematic - retrying will not succeed. Even if delivery does work, fragmentation is inherently susceptible to Dos attack, since the IP level cannot check that a fragment is bogus ( AFAIK, if anyone knows how IPsec might practically be incorporated into DNS, that might be interesting ). > (3) The large ratio between the request size and the response size > allows malicious programs to mount "amplification" attacks. > > That is because of the nature of the DNS, your proposal does not > affect that really Yes it does. It limits the amplification factor, that is the amount of traffic an attacker can generate in response to a small request. As described in the draft, a server can dynamically reduce the amplification in response to an attack. > (I guess it allows a victim to avoid asking for > more responses after the first, when it is unknown, but the alternative > is that now the served is hanging onto all that data waiting for > some unspecified further time for the next request from the client, > which is never going to arrive - if the server gives up too soon, > then a legitimate request can never succeed). I assume by "served" you mean "server". No, the server is not "hanging on" to the data, that is the whole point, there does not need to be any per-client state, as described in the security section. A server might have some per-client state, as an optimization, but this can (and should) be time and space limited. > a DOS attack on a major DNS server is a far worse outsome than > an amplification attack on some random node. An amplification attack can exhaust the transmit capability of the authoritative server, so it can be serious. It can have other serious consequences as well, and such attacks ( although normally using open recursive servers ) have been seen in the wild. This imposes extra costs on providing authoritative servers, as the transmit capability must be massively over-provisioned, or risk DoS attack. > (4) Re-assembling fragments requires buffer resources, which opens > up denial of service attacks. > > That is not avoided by this, Yes it is. The difference is that bogus packets are immediately discarded. > IP reassembly is still a required part > of IP, you're just removing one legitimate client - unless you can > remove every possible use of fragmentation, hosts still need to > reassemble incoming datagrams. That's true - in fact this proposal is not intended to rule out large packets / fragmentation entirely, just to provide a fall back that works smoothly and reliably (against DoS) when the path MTU is not large ( typically around 1500 bytes, the IPv6 minimum MTU is 1280 bytes ). One point I didn't mention is the possibility of a server setting DF=1 and then responding to an ICMP error message by reducing the packet size ( as occurs with TCP ). I don't know if this works theoretically or practically, or indeed whether any existing DNS servers have this capability - that is sending a truncated response in response to a transmit error. > The resources used to reassemble the incoming DNS response will be > approximately the same either weay (just spent in a different place), > the big DNS reply still needs to be reassembled somewhere - this proposal > will just take much longer to do it, so comsume the resources for > longer. > > Instead, it is possible to use TCP, but this is undesirable, as TCP > imposes significant overhead and state that is vulnerable to denial > of service attack. > > Now you're trying to replace TCP as well - that makes no sense at > all. There is little extra TCP state then your proposal requires, > and TCP does its job far better and more effeciently. TCP needs per-client state, this proposal does not. > Please resist the temptation to attempt to invent alternatives to > TCP, withoug a LOT of effort, they're almost all doomed to failure. This is nothing like TCP. Think of it more as intelligent truncation, which allows the client to efficiently and reliably continue with UDP when the MTU is not large. > The option includes an authentication mechanism that ensures that > blind spoofing of the response is not possible. > > Just the DNS ID & question is reasonably good for that (though > not perfect). I wouldn't really call what you have included as > "authentication" either. It's not good enough, especially when fragmentation occurs behind a NAT device, since the ID field only protects the first fragment, and port randomization is normally reversed by NAT. [ copy of draft snipped ] Regards, George From owner-namedroppers@ops.ietf.org Sun Aug 16 00:57: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 9A8D13A6925; Sun, 16 Aug 2009 00:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=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 zC0JNaJpeVWs; Sun, 16 Aug 2009 00:57:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B438C3A6ABA; Sun, 16 Aug 2009 00:57:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McaYG-00083c-FT for namedroppers-data0@psg.com; Sun, 16 Aug 2009 07:53:16 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McaYC-00083F-J2 for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 07:53:14 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 99D22C2DA5; Sun, 16 Aug 2009 08:53:10 +0100 (BST) Date: Sun, 16 Aug 2009 08:53:13 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Robert Elz , George Barwood cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: In-Reply-To: <8106.1250387009@epsilon.noi.kre.to> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Goerge, --On 16 August 2009 08:43:29 +0700 Robert Elz wrote: > This limits the protocol to strict lock step, send one request, get > one answer piece, send next request, get next piece, ... for long > requests, with a remote server, that's going to mean perhaps 5 seconds > or so (that's just 10 trips - assuming a 5K response, not very big, > with a 500ms RTT which is just one satellite leg). That's absurd, > TCP would be done and finished ages ago, and any rational client will > have abandoned the request already. If you're looking for a way to > kill DNSSEC, this would be it. If we ignore the point about amplification, as I pointed out, you could just sent all the UDP answers in one go. You could solve the amplification issue simply by saying the first request is answered with one packet, and the second request (if one is needed) is answered with n-1 packets. As this would require the "secret key" (or nonce), we know (but see below) its source is not forged. The RTT time here is maximum 2 x RTT, which is no worse than TCP. --On 16 August 2009 08:43:29 +0700 Robert Elz wrote: > And for clients that have no such source of randomness? Thay'r enot > permitted to use this protocol? I am not quite sure "secret key" (nonce or whatever) is trying to achieve. The concern appears to be that a rogue nameserver could get hold of the internal state of the client, presumably to subsequently forge answers to queries to a different name server. As this is a proposal intended (mainly) to address DNSSEC queries, that problem is mostly solved already. However, if the key used was something like H(real-secret,query,incrementing-counter), where "real-secret" is a true secret (i.e. known only to the client, not the 'secret" in George's proposal), it's hard to see how internal state would be revealed if H() was an effective hash function. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sun Aug 16 01:55: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 CCD413A6D3F; Sun, 16 Aug 2009 01:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.078 X-Spam-Level: **** X-Spam-Status: No, score=4.078 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3FU07Ve2xzo; Sun, 16 Aug 2009 01:55:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0035E3A6D17; Sun, 16 Aug 2009 01:55:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McbR7-000EsM-2L for namedroppers-data0@psg.com; Sun, 16 Aug 2009 08:49:57 +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 1McbR3-000Ers-7y for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 08:49:55 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1McbQi-0006pO-Ss; Sun, 16 Aug 2009 09:49:32 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1McbQi-0003HM-7X; Sun, 16 Aug 2009 09:49:32 +0100 Message-ID: From: "George Barwood" To: "Florian Weimer" , "Mark Andrews" Cc: "Nicholas Weaver" , "Doug Barton" , "Paul Vixie" , References: <4A80453B.1000203@gmail.com> <8560.1249922543@nsa.vix.com> <4A80685A.1080104@gmail.com> <4A817D6E.9040202@gmail.com> <87474.1250029811@nsa.vix.com> <1B6540C99B25F4995938FACE@nimrod.local> <8241.1250060733@nsa.vix.com> <617024FFDB8A38B36B2EE21D@nimrod.local> <83721.1250176115@nsa.vix.com> <4A847C98.4010302@dougbarton.us> <60725924-FFF6-416F-8C7B-5EE6D81C865E@ICSI.Berkeley.EDU> <87eire2kfw.fsf@mid.deneb.enyo.de> <200908142230.n7EMU9eg026329@drugs.dv.isc.org> Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory Date: Sun, 16 Aug 2009 09:49:26 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Mark Andrews" To: "Florian Weimer" Cc: "Nicholas Weaver" ; "Doug Barton" ; "Paul Vixie" ; Sent: Friday, August 14, 2009 11:30 PM Subject: Re: [dnsext] DNS over SCTP problems, part 1, theory > > In message <87eire2kfw.fsf@mid.deneb.enyo.de>, Florian Weimer writes: >> * Nicholas Weaver: >> >> > DNS UDP is generally not sent with DF set, >> >> The picture is mixed. There's a lost of DF at the TLD and root level. >> End users typically use mainstream systems in more recent versions >> which generally don't set DF anymore. > > Only because OS vendors turned it on without thinking about the > applications. Named turns it off it if can on a per socket basis. > The only OS where it is on for UDP and named can't turn it off on > a per socket basis that I am aware of is Solaris. Since fragmented responses are vulnerable to spoofing, would it be better to set DF=1 where possible, and accept TCP fallback? Does Named react to ICMP messages when DF=1 is in effect ( by transmitting a truncated response ) ? I don't know if support for this is widespread. A quick google search turned up this http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.commadmn/doc/commadmndita/sctp_mtu.htm which suggests that it is possible in principle. George > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > From owner-namedroppers@ops.ietf.org Sun Aug 16 04:53: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 DB65C3A6A68; Sun, 16 Aug 2009 04:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW4cMczr19DI; Sun, 16 Aug 2009 04:53:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E6B53A6DB7; Sun, 16 Aug 2009 04:53:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MceD8-0007Vl-Rv for namedroppers-data0@psg.com; Sun, 16 Aug 2009 11:47:42 +0000 Received: from [2001:3c8:9009:181::2] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MceCx-0007Tv-BO for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 11:47:36 +0000 Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9009:181::2]) by jade.coe.psu.ac.th with ESMTP id n7GBlDiY024813; Sun, 16 Aug 2009 18:47:15 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id n7GBk7k9025471; Sun, 16 Aug 2009 18:46:41 +0700 (ICT) From: Robert Elz To: "George Barwood" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft In-Reply-To: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> References: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> Date: Sun, 16 Aug 2009 18:46:07 +0700 Message-ID: <12414.1250423167@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Date: Sun, 16 Aug 2009 08:13:01 +0100 From: "George Barwood" Message-ID: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> | I'm afraid your response is wrong in almost every point. You didn't address the most important point, which is the lock step nature of the proposal, which makes it totally unworkable. | Thanks for your interest, nevertheless, the fault may be mine, in that I | probably did not sufficiently stress that the server can have no | per-client state (which is the whole point of the design). Yes, I could see that the server could encode some kind of a hash of the answer in the cookie it sent back, so it can tell whather or not the data has changed since its last (part) reply. (I'd kind of hate to imagine the likely client implementation bugs when that happens though). But that's not nearly enough, recall that RRs are not ordered, and servers typically don't send the RRs in the same order in two consecutive answers to the same question. That means, that not only a hash of the data needs to be remembered per client, but the exact layout of the generated answer, or that answer itself (the easy way) so a subsequent reply can continue from where the previous one left off. You seem to be assuming that just the offset will allow a stateless server to continue its reply - it wouldn't. I doubt it is possible to encode all of the information that would be needed in a 16 byte cookie - making the cookie big enough would mean ending up including almost no useful data in a limited size reply, not making it big enough means state is required at the server. | The point is that the non-delivery is systematic - retrying will not | succeed. Only if someone has deliberately broken fragmentation/reassembly, not for the more typical case of a frag just being lost due to congestion or whatever. In the former case, whatever has been broken needs to get fixed. | Even if delivery does work, fragmentation is inherently susceptible to Dos | attack, Sure - it is also trivially easy to protect from, well enough for the net to continue to operate, and for the attack to be mostly useless (ie: not perfect protectionm but good enough). If that wasn't true, the internet would have collapsed by now. Fragmentation has lots of problems, and is best avoided wherever possible, but it isn't nearly as bad as you're making out. | I assume by "served" you mean "server". Yes, one of my common typos when I am in a hurry - sorry... | No, the server is not "hanging on" to the data, As above, I doubt what you're thinking is implementable. | That's true - in fact this proposal is not intended to rule out large | packets / fragmentation entirely, just to provide a fall back that works | smoothly and reliably (against DoS) when the path MTU is not large | ( typically around 1500 bytes, the IPv6 minimum MTU is 1280 bytes ). Yes, I know what MTU's typically are - the point was that avoiding using fragmentation doesn't make fragmentation safer (assuming the problems are serious enough to really worry about). Whatever fragmentation attack someone wants to carry out doesn't need to involve the DNS at all. You aren't going to succeed in having fragmentation elimiinated from IP, just to avoid a minor DoS attack possibility. | One point I didn't mention is the possibility of a server setting DF=1 | and then responding to an ICMP error message by reducing the packet | size ( as occurs with TCP ). PMTUD - for IPv6 it is more or less required (ie: unavoidable) unless the large packet sender deliberately fragments at a smallish size. | I don't know if this works theoretically or practically, It works theoretically (though it is complicated for UDP). Practically, idiots who filter ICMP messages cause problems. | TCP needs per-client state, this proposal does not. I suspect they both do. | This is nothing like TCP. I know, it isn't - yet. The problem is that as you find that you need to solve all of the other problems (like avoiding the lock step, one packet in flight at at time design - which is horrid) you'll end up making it more and more like TCP - when you have multiple packets in transit at once, you have to deal with reordering, and arranging a method to have retransmitted just what needs retransmitting, and flow control, and ... and what you will end up with is something that has to do just about all that TCP has to do, just (probably) done in a different way. This isn't uncommon, people keep making these proposals for UDP based protocols to supposedly "solve" the problems of using TCP for some problem or other. I don't think I've ever seen one succeed. For really large DNS answers, TCP is the right solution. | Think of it more as intelligent truncation, | which allows the client to efficiently and reliably continue with UDP | when the MTU is not large. But that is not a rational aim. | It's not good enough, especially when fragmentation occurs behind | a NAT device, since the ID field only protects the first fragment, and port | randomization is normally reversed by NAT. This depends what you're really worried about. If it is just the reassembly cost, then sure - but that's not (or shouldn't be with a reasonable implementation) a problem serious enough for all of this, if it is DNS spoofing, then protecting fragments is not relevant any more, only the entire answer (and as Alex Bligh said in a later reply, since the whole point of this is dealing with the large replies that DNSSEC generates, DNS spoofing is irrelevant anyway, that's what DNSSEC is all about). kre From owner-namedroppers@ops.ietf.org Sun Aug 16 11:32: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 C9CA03A6CB4; Sun, 16 Aug 2009 11:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: 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+qLo9-SSKwE; Sun, 16 Aug 2009 11:32:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FD4F3A6A99; Sun, 16 Aug 2009 11:32:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MckQP-0008fK-S1 for namedroppers-data0@psg.com; Sun, 16 Aug 2009 18:25:49 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MckQL-0008ee-Am for namedroppers@ops.ietf.org; Sun, 16 Aug 2009 18:25:47 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MckQI-0005bX-FM; Sun, 16 Aug 2009 19:25:42 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MckQH-000076-Ll; Sun, 16 Aug 2009 19:25:41 +0100 Message-ID: <7A092320F96440F186F89464389FEC7D@localhost> From: "George Barwood" To: "Robert Elz" Cc: References: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> <12414.1250423167@epsilon.noi.kre.to> Subject: Re: [dnsext] EDNS Page Option draft Date: Sun, 16 Aug 2009 19:25:35 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Robert Elz" To: "George Barwood" Cc: Sent: Sunday, August 16, 2009 12:46 PM Subject: Re: [dnsext] EDNS Page Option draft > > Date: Sun, 16 Aug 2009 08:13:01 +0100 > From: "George Barwood" > Message-ID: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> > > | I'm afraid your response is wrong in almost every point. > > You didn't address the most important point, which is the lock > step nature of the proposal, which makes it totally unworkable. I don't think that's the case. It's not expected that more than 2 response packets would ever be needed. However, by adding a page count to the response, and a page number to the follow-up request, the follow-ups could all be fetched in parallel. That leads to 2 x RTT as the overall time, assuming no packets are lost. However congestion control may then be a concern. > | Thanks for your interest, nevertheless, the fault may be mine, in that > I > | probably did not sufficiently stress that the server can have no > | per-client state (which is the whole point of the design). > > Yes, I could see that the server could encode some kind of a hash of the > answer in the cookie it sent back, so it can tell whather or not the > data has changed since its last (part) reply. (I'd kind of hate to > imagine the likely client implementation bugs when that happens though). > > But that's not nearly enough, recall that RRs are not ordered, and servers > typically don't send the RRs in the same order in two consecutive answers > to the same question. I would expect authoritative servers to be deterministic. Maybe you are referring to load balancing servers? I think for that case DNSSEC may be problematic, but in any case, I don't see a reason to shuffle the DNSKEY RRset, which is the case that generates large responses. > That means, that not only a hash of the data needs > to be remembered per client, but the exact layout of the generated answer, > or that answer itself (the easy way) so a subsequent reply can continue > from > where the previous one left off. You seem to be assuming that just the > offset > will allow a stateless server to continue its reply - it wouldn't. I > doubt > it is possible to encode all of the information that would be needed in a > 16 byte cookie - making the cookie big enough would mean ending up > including > almost no useful data in a limited size reply, not making it big enough > means state is required at the server. If random shuffling of RRsets was required (and that's an odd thing to do I think), that could still be accomodated by careful programming. > | The point is that the non-delivery is systematic - retrying will not > | succeed. > > Only if someone has deliberately broken fragmentation/reassembly, not for > the > more typical case of a frag just being lost due to congestion or whatever. > In the former case, whatever has been broken needs to get fixed. Fragmentation is bad when there is congestion, because a single lost packet can generate multiple new transmissions, worsening the congestion. > | Even if delivery does work, fragmentation is inherently susceptible to > Dos > | attack, > > Sure - it is also trivially easy to protect from, well enough for the > net to continue to operate, and for the attack to be mostly useless (ie: > not perfect protectionm but good enough). If that wasn't true, the > internet > would have collapsed by now. Fragmentation has lots of problems, and is > best avoided wherever possible, but it isn't nearly as bad as you're > making out. I'm not sure how bad I painted it. But at least we agree it isn't ideal. > | I assume by "served" you mean "server". > > Yes, one of my common typos when I am in a hurry - sorry... > > | No, the server is not "hanging on" to the data, > > As above, I doubt what you're thinking is implementable. Well I guess that can only be settled by more detailed work, but I think it is really not that hard. Programming problems often seem hard until they have been solved, then with hindsight they are easy. > | That's true - in fact this proposal is not intended to rule out large > | packets / fragmentation entirely, just to provide a fall back that > works > | smoothly and reliably (against DoS) when the path MTU is not large > | ( typically around 1500 bytes, the IPv6 minimum MTU is 1280 bytes ). > > Yes, I know what MTU's typically are - the point was that avoiding > using fragmentation doesn't make fragmentation safer (assuming the > problems > are serious enough to really worry about). Whatever fragmentation > attack someone wants to carry out doesn't need to involve the DNS at all. Rome wasn't built in a day, you have to start somewhere. Having a robust DNS seems worthwhile to me. This is in the recently amended charter for the working group. > You aren't going to succeed in having fragmentation elimiinated from > IP, just to avoid a minor DoS attack possibility. > > | One point I didn't mention is the possibility of a server setting DF=1 > | and then responding to an ICMP error message by reducing the packet > | size ( as occurs with TCP ). > > PMTUD - for IPv6 it is more or less required (ie: unavoidable) unless > the large packet sender deliberately fragments at a smallish size. > > | I don't know if this works theoretically or practically, > > It works theoretically (though it is complicated for UDP). > Practically, idiots who filter ICMP messages cause problems. > > | TCP needs per-client state, this proposal does not. > > I suspect they both do. > > | This is nothing like TCP. > > I know, it isn't - yet. The problem is that as you find that you > need to solve all of the other problems (like avoiding the lock > step, one packet in flight at at time design - which is horrid) > you'll end up making it more and more like TCP - when you have > multiple packets in transit at once, you have to deal with reordering, > and arranging a method to have retransmitted just what needs > retransmitting, and flow control, and ... and what you will end > up with is something that has to do just about all that TCP has to > do, just (probably) done in a different way. The difference will be that many transactions can be done in 1 RTT. If 2 round trips is the worst case, I think you are exaggerating the problem. > This isn't uncommon, people keep making these proposals for UDP > based protocols to supposedly "solve" the problems of using TCP > for some problem or other. I don't think I've ever seen one > succeed. Ok. > For really large DNS answers, TCP is the right solution. Yes - but these are not expected ( excluding IXFR etc of course ). > | Think of it more as intelligent truncation, > | which allows the client to efficiently and reliably continue with UDP > | when the MTU is not large. > > But that is not a rational aim. It seems rational to me. It should improve performance and reliability. I accept that the increased complexity may be too high a price to pay. That's an unclear judgement call. > | It's not good enough, especially when fragmentation occurs behind > | a NAT device, since the ID field only protects the first fragment, and > port > | randomization is normally reversed by NAT. > > This depends what you're really worried about. If it is just > the reassembly cost, then sure - but that's not (or shouldn't be > with a reasonable implementation) a problem serious enough for > all of this, if it is DNS spoofing, then protecting fragments is > not relevant any more, only the entire answer (and as Alex Bligh > said in a later reply, since the whole point of this is dealing with > the large replies that DNSSEC generates, DNS spoofing is irrelevant > anyway, that's what DNSSEC is all about). Not entirely. Spoofing attacks against DNSSEC can still result in denial of service. It's especially a problem with a DNSSEC-aware, non-validating cache. A validating client of the cache has no way of telling the cache that it has bad ( spoofed ) data. I suspect it's also non-trivial for validating caches to proceed smoothly when a signature fails due to spoofing. Regards, George > kre > From owner-namedroppers@ops.ietf.org Sun Aug 16 18:49: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 2D49C3A6842; Sun, 16 Aug 2009 18:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2joxmnnhIuCo; Sun, 16 Aug 2009 18:49:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BE7E3A6A10; Sun, 16 Aug 2009 18:49:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McrEu-00098p-C7 for namedroppers-data0@psg.com; Mon, 17 Aug 2009 01:42: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 1McrEp-00097k-Dk for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 01:42: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 938D4E606E; Mon, 17 Aug 2009 01:42: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 n7H1g8Om073680; Mon, 17 Aug 2009 11:42:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908170142.n7H1g8Om073680@drugs.dv.isc.org> To: "George Barwood" Cc: "Robert Elz" , namedroppers@ops.ietf.org From: Mark Andrews References: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> <12414.1250423167@epsilon.noi.kre.to> <7A092320F96440F186F89464389FEC7D@localhost> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Sun, 16 Aug 2009 19:25:35 +0100." <7A092320F96440F186F89464389FEC7D@localhost> Date: Mon, 17 Aug 2009 11:42:08 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <7A092320F96440F186F89464389FEC7D@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Robert Elz" > To: "George Barwood" > Cc: > Sent: Sunday, August 16, 2009 12:46 PM > Subject: Re: [dnsext] EDNS Page Option draft > > > Date: Sun, 16 Aug 2009 08:13:01 +0100 > > From: "George Barwood" > > Message-ID: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> > > > > | I'm afraid your response is wrong in almost every point. > > > > You didn't address the most important point, which is the lock > > step nature of the proposal, which makes it totally unworkable. > > I don't think that's the case. It's not expected that more than 2 response > packets would ever be needed. You wanted to get through 512 byte limited devices. This is up to 9 DNS pages compared to 2 to 3 (IPv4) or 4 (IPv6) fragments with IP fragmentation assuming a 4096 byte DNS response. Whatever is done still needs to work through 512 byte limited devices. > However, by adding a page count to the response, > and a page number to the follow-up request, the follow-ups could all be > fetched in parallel. That leads to 2 x RTT as the overall time, assuming > no packets are lost. However congestion control may then be a concern. > > > | Thanks for your interest, nevertheless, the fault may be mine, in that > > I > > | probably did not sufficiently stress that the server can have no > > | per-client state (which is the whole point of the design). > > > > Yes, I could see that the server could encode some kind of a hash of the > > answer in the cookie it sent back, so it can tell whather or not the > > data has changed since its last (part) reply. (I'd kind of hate to > > imagine the likely client implementation bugs when that happens though). > > > > But that's not nearly enough, recall that RRs are not ordered, and servers > > typically don't send the RRs in the same order in two consecutive answers > > to the same question. > > I would expect authoritative servers to be deterministic. > Maybe you are referring to load balancing servers? > I think for that case DNSSEC may be problematic, but in any case, I don't > see a reason to shuffle the DNSKEY RRset, which is the case that generates > large responses. There are lots of answers that want to exceed 512 bytes that need to be shuffled. > > That means, that not only a hash of the data needs > > to be remembered per client, but the exact layout of the generated answer, > > or that answer itself (the easy way) so a subsequent reply can continue > > from > > where the previous one left off. You seem to be assuming that just the > > offset > > will allow a stateless server to continue its reply - it wouldn't. I > > doubt > > it is possible to encode all of the information that would be needed in a > > 16 byte cookie - making the cookie big enough would mean ending up > > including > > almost no useful data in a limited size reply, not making it big enough > > means state is required at the server. > > If random shuffling of RRsets was required (and that's an odd thing to do I > think), that could still be accomodated by careful programming. Random shuffling is needed as it is the only way to get balanced load in the presence of a dead server. Lots of things can be accomodated by careful programming and extra memory. The question is "is it worth it". We have a simple system that is working though it is is not optimal. It works through 512 byte limiting devices. It doesn't require the server to hold any state. > > | The point is that the non-delivery is systematic - retrying will not > > | succeed. > > > > Only if someone has deliberately broken fragmentation/reassembly, not for > > the > > more typical case of a frag just being lost due to congestion or whatever. > > In the former case, whatever has been broken needs to get fixed. > > Fragmentation is bad when there is congestion, because a single lost packet > can generate multiple new transmissions, worsening the congestion. > > | Even if delivery does work, fragmentation is inherently susceptible to > > Dos > > | attack, > > > > Sure - it is also trivially easy to protect from, well enough for the > > net to continue to operate, and for the attack to be mostly useless (ie: > > not perfect protectionm but good enough). If that wasn't true, the > > internet > > would have collapsed by now. Fragmentation has lots of problems, and is > > best avoided wherever possible, but it isn't nearly as bad as you're > > making out. > > I'm not sure how bad I painted it. But at least we agree it isn't ideal. > > > | I assume by "served" you mean "server". > > > > Yes, one of my common typos when I am in a hurry - sorry... > > > > | No, the server is not "hanging on" to the data, > > > > As above, I doubt what you're thinking is implementable. > > Well I guess that can only be settled by more detailed work, but I > think it is really not that hard. Programming problems often seem hard until > they have been solved, then with hindsight they are easy. > > > | That's true - in fact this proposal is not intended to rule out large > > | packets / fragmentation entirely, just to provide a fall back that > > works > > | smoothly and reliably (against DoS) when the path MTU is not large > > | ( typically around 1500 bytes, the IPv6 minimum MTU is 1280 bytes ). > > > > Yes, I know what MTU's typically are - the point was that avoiding > > using fragmentation doesn't make fragmentation safer (assuming the > > problems > > are serious enough to really worry about). Whatever fragmentation > > attack someone wants to carry out doesn't need to involve the DNS at all. > > Rome wasn't built in a day, you have to start somewhere. > Having a robust DNS seems worthwhile to me. > This is in the recently amended charter for the working group. > > > You aren't going to succeed in having fragmentation elimiinated from > > IP, just to avoid a minor DoS attack possibility. > > > > | One point I didn't mention is the possibility of a server setting DF=1 > > | and then responding to an ICMP error message by reducing the packet > > | size ( as occurs with TCP ). > > > > PMTUD - for IPv6 it is more or less required (ie: unavoidable) unless > > the large packet sender deliberately fragments at a smallish size. IPv6 DNS/UDP responses are fragmented by the sender at network MTU. IPv4 stacks which set DF on UDP without the application requesting is are broken and need to be fixed. DF is therefore a non-issue. > > | I don't know if this works theoretically or practically, > > > > It works theoretically (though it is complicated for UDP). > > Practically, idiots who filter ICMP messages cause problems. > > > > | TCP needs per-client state, this proposal does not. > > > > I suspect they both do. > > > > | This is nothing like TCP. > > > > I know, it isn't - yet. The problem is that as you find that you > > need to solve all of the other problems (like avoiding the lock > > step, one packet in flight at at time design - which is horrid) > > you'll end up making it more and more like TCP - when you have > > multiple packets in transit at once, you have to deal with reordering, > > and arranging a method to have retransmitted just what needs > > retransmitting, and flow control, and ... and what you will end > > up with is something that has to do just about all that TCP has to > > do, just (probably) done in a different way. > > The difference will be that many transactions can be done in 1 RTT. > If 2 round trips is the worst case, I think you are exaggerating the > problem. No. Robert is not exaggerating the problem. If you only have static data your simple scheme will work as the server really doesn't have to hold extra data or state. In the real world you have caches and dynamic zones which result in constantly changing data sources with no short term stability. For your scheme to work you need to be able to hold the data used to create the response until you are sure there will not be a request for it. You need to do this for every paged response, i.e. every response > 512 bytes. You also need to hold/pass state to reference that data and have it replayed in the original order so you can send the relevent page. > > This isn't uncommon, people keep making these proposals for UDP > > based protocols to supposedly "solve" the problems of using TCP > > for some problem or other. I don't think I've ever seen one > > succeed. > > Ok. > > > For really large DNS answers, TCP is the right solution. > > Yes - but these are not expected ( excluding IXFR etc of course ). No. They my not be common by they are expected. > > | Think of it more as intelligent truncation, > > | which allows the client to efficiently and reliably continue with UDP > > | when the MTU is not large. > > > > But that is not a rational aim. > > It seems rational to me. It should improve performance and reliability. > I accept that the increased complexity may be too high a price to pay. > That's an unclear judgement call. > > > | It's not good enough, especially when fragmentation occurs behind > > | a NAT device, since the ID field only protects the first fragment, and > > port > > | randomization is normally reversed by NAT. > > > > This depends what you're really worried about. If it is just > > the reassembly cost, then sure - but that's not (or shouldn't be > > with a reasonable implementation) a problem serious enough for > > all of this, if it is DNS spoofing, then protecting fragments is > > not relevant any more, only the entire answer (and as Alex Bligh > > said in a later reply, since the whole point of this is dealing with > > the large replies that DNSSEC generates, DNS spoofing is irrelevant > > anyway, that's what DNSSEC is all about). > > Not entirely. Spoofing attacks against DNSSEC can still result in > denial of service. It's especially a problem with a DNSSEC-aware, > non-validating cache. A validating client of the cache has no way of > telling the cache that it has bad ( spoofed ) data. > > I suspect it's also non-trivial for validating caches to proceed > smoothly when a signature fails due to spoofing. > > Regards, > George > > > kre -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 17 01:46: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 12DE73A6C2C; Mon, 17 Aug 2009 01:46:17 -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 gFeqDpnvMgzW; Mon, 17 Aug 2009 01:46:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14D9028C162; Mon, 17 Aug 2009 01:46:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mcxjh-0009PY-9s for namedroppers-data0@psg.com; Mon, 17 Aug 2009 08:38:37 +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 1McxjZ-0009Og-25 for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 08:38:34 +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 n7H8cI17056762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 10:38:23 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A8916FA.8050302@nlnetlabs.nl> Date: Mon, 17 Aug 2009 10:38:18 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <5722A99A87EA478BAC81D71ED194B500@localhost> In-Reply-To: <5722A99A87EA478BAC81D71ED194B500@localhost> 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, 17 Aug 2009 10:38:23 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi George, My opinion about the piece. I hope that IP fragmentation is not broken, and effort to fix IP itself is the first concern. If it turns out that IP is badly broken. And that the only recourse is to have another big bad layer violation in the DNS. Then, something like this draft can be the solution. It would need to fix the stuff that is broken. That is the fragmentation. Thus I would like to echo Alex Bligh's idea that this draft would be better with no cookies and state, and just replying with several smaller packets. I note that is no backwards compatibility considerations in the draft. Overall, I do not get the impression that fragmentation is badly broken. The only reports we have seen are adsl box tests that indicate those proxies are broken (must use their routing capabilities). There may be misconfigured or misguided operators, but fragmentation problems seem sporadic. Therefore, I do not think this is something for the workgroup to take up at this time. Best regards, Wouter On 08/15/2009 02:22 PM, George Barwood wrote: > I have submitted an internet draft > > http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-00.txt > > Abstract > > Describes an EDNS option to allow large DNS responses to be sent > using small UDP packets. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqJFvoACgkQkDLqNwOhpPj1FACdEgZSGlNrjAgoYhq+M1O1xJ3h bGQAoIEC4PiA9uSKPklW6bWgsLI5BDsp =zEBS -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 17 01:46: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 1EEEE3A6D95; Mon, 17 Aug 2009 01:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=-0.862, 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 5G69SjABxoC0; Mon, 17 Aug 2009 01:46:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC34B3A6D28; Mon, 17 Aug 2009 01:46:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mcxkf-0009aD-Hf for namedroppers-data0@psg.com; Mon, 17 Aug 2009 08:39: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 1Mcxka-0009Zl-HY for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 08:39:34 +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 1McxkQ-0000ju-Tm; Mon, 17 Aug 2009 10:39:22 +0200 Received: by bfk.de with local id 1McxkQ-0001D1-Mj; Mon, 17 Aug 2009 08:39:22 +0000 To: Mark Andrews Cc: "George Barwood" , "Robert Elz" , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> <12414.1250423167@epsilon.noi.kre.to> <7A092320F96440F186F89464389FEC7D@localhost> <200908170142.n7H1g8Om073680@drugs.dv.isc.org> From: Florian Weimer Date: Mon, 17 Aug 2009 08:39:22 +0000 In-Reply-To: <200908170142.n7H1g8Om073680@drugs.dv.isc.org> (Mark Andrews's message of "Mon\, 17 Aug 2009 11\:42\:08 +1000") Message-ID: <82ws52al6t.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Mark Andrews: >> I don't think that's the case. It's not expected that more than 2 respon= se >> packets would ever be needed. > > You wanted to get through 512 byte limited devices. Wouldn't they block this unknown protocol extensions anyway? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 17 02: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 6C6F828C298; Mon, 17 Aug 2009 02:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 u9KkEMiGg87H; Mon, 17 Aug 2009 02:58:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68FA128C297; Mon, 17 Aug 2009 02:58:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mcysb-000Iii-H0 for namedroppers-data0@psg.com; Mon, 17 Aug 2009 09:51: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 1McysW-000IiB-RY for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 09:51:51 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 03292E601C; Mon, 17 Aug 2009 09:51: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 n7H9pgpW081626; Mon, 17 Aug 2009 19:51:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908170951.n7H9pgpW081626@drugs.dv.isc.org> To: Florian Weimer Cc: "George Barwood" , "Robert Elz" , namedroppers@ops.ietf.org From: Mark Andrews References: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> <12414.1250423167@epsilon.noi.kre.to> <7A092320F96440F186F89464389FEC7D@localhost> <200908170142.n7H1g8Om073680@drugs.dv.isc.org> <82ws52al6t.fsf@mid.bfk.de> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Mon, 17 Aug 2009 08:39:22 GMT." <82ws52al6t.fsf@mid.bfk.de> Date: Mon, 17 Aug 2009 19:51:42 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <82ws52al6t.fsf@mid.bfk.de>, Florian Weimer writes: > * Mark Andrews: > > >> I don't think that's the case. It's not expected that more than 2 respon= > se > >> packets would ever be needed. > > > > You wanted to get through 512 byte limited devices. > > Wouldn't they block this unknown protocol extensions anyway? You have some which do and some which don't. You can't work through those that do so we can effectively ignore them. > --=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 From owner-namedroppers@ops.ietf.org Mon Aug 17 03: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 AD8813A6D19; Mon, 17 Aug 2009 03:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxO7ImNYXfik; Mon, 17 Aug 2009 03:20:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C4D93A6A09; Mon, 17 Aug 2009 03:20:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MczGG-000Lpq-Ov for namedroppers-data0@psg.com; Mon, 17 Aug 2009 10:16:20 +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 1MczG7-000LnS-Lu for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 10:16:18 +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 1MczG1-0003zb-Cw; Mon, 17 Aug 2009 12:16:05 +0200 Received: by bfk.de with local id 1MczG1-0001cM-9R; Mon, 17 Aug 2009 10:16:05 +0000 To: Mark Andrews Cc: "George Barwood" , "Robert Elz" , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <02DA7F9C1CE84E4AB0CE185185B5B55B@localhost> <5722A99A87EA478BAC81D71ED194B500@localhost> <8106.1250387009@epsilon.noi.kre.to> <12414.1250423167@epsilon.noi.kre.to> <7A092320F96440F186F89464389FEC7D@localhost> <200908170142.n7H1g8Om073680@drugs.dv.isc.org> <82ws52al6t.fsf@mid.bfk.de> <200908170951.n7H9pgpW081626@drugs.dv.isc.org> From: Florian Weimer Date: Mon, 17 Aug 2009 10:16:05 +0000 In-Reply-To: <200908170951.n7H9pgpW081626@drugs.dv.isc.org> (Mark Andrews's message of "Mon\, 17 Aug 2009 19\:51\:42 +1000") Message-ID: <82ab1yagpm.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Mark Andrews: > In message <82ws52al6t.fsf@mid.bfk.de>, Florian Weimer writes: >> * Mark Andrews: >>=20 >> >> I don't think that's the case. It's not expected that more than 2 res= pon=3D >> se >> >> packets would ever be needed. >> > >> > You wanted to get through 512 byte limited devices. >>=20 >> Wouldn't they block this unknown protocol extensions anyway? > > You have some which do and some which don't. You can't work through > those that do so we can effectively ignore them. Why can't we ignore those who *still* restrict DNS to 512 bytes, too? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 17 03:22:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADFC3A6EB6; Mon, 17 Aug 2009 03:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.701 X-Spam-Level: *** X-Spam-Status: No, score=3.701 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGhUmWxE1crv; Mon, 17 Aug 2009 03:22:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 868B23A6E37; Mon, 17 Aug 2009 03:22:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MczJ5-000MJX-Mh for namedroppers-data0@psg.com; Mon, 17 Aug 2009 10:19:15 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MczJ1-000MHk-Nw for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 10:19:13 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1MczIv-0001PM-Fv; Mon, 17 Aug 2009 11:19:05 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MczIu-0003KC-PR; Mon, 17 Aug 2009 11:19:04 +0100 Message-ID: <06A65CB0596049F7A085A8C45494823F@localhost> From: "George Barwood" To: "W.C.A. Wijngaards" Cc: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 11:18:57 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "W.C.A. Wijngaards" To: "George Barwood" Cc: Sent: Monday, August 17, 2009 9:38 AM Subject: Re: [dnsext] EDNS Page Option draft > My opinion about the piece. I hope that IP fragmentation is not > broken, and effort to fix IP itself is the first concern. Nicholas Weaver has done some investigation, which suggests it is broken http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01513.html and has stated "At least for DNS, fragmented UDP does not get through a shockingly high percentage of the time, when non-fragmented UDP gets through just fine. To my mind, this suggests that, as an authority, whenever possible, make sure you fit in the Ethernet MTU, unless you are happy with TCP fallback on those queries." http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01693.html It would actually be quite surprising to me if it was not broken. This capability is apparently not required for current internet use, hence it has evolved to a state where it doesn't work. It may be that TCP fallback is adequate, but I think it's worth considering an alternative solution. I worry that resolvers may start establishing a TCP connection before the UDP attempt has failed - since the failure is a "slow" timeout. I think that could lead to problems. George From owner-namedroppers@ops.ietf.org Mon Aug 17 03:49: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 A7AB028C25F; Mon, 17 Aug 2009 03:49:38 -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 7D56Ozz5fUGk; Mon, 17 Aug 2009 03:49:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB00828C259; Mon, 17 Aug 2009 03:49:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McziL-000PRq-Nu for namedroppers-data0@psg.com; Mon, 17 Aug 2009 10:45:21 +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 1McziE-000PPu-Qf for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 10:45:17 +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 n7HAj9jC011991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 12:45:09 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A8934B5.7000106@nlnetlabs.nl> Date: Mon, 17 Aug 2009 12:45:09 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> In-Reply-To: <06A65CB0596049F7A085A8C45494823F@localhost> 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, 17 Aug 2009 12:45:09 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi George, On 08/17/2009 12:18 PM, George Barwood wrote: > Nicholas Weaver has done some investigation, which suggests it is broken > > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01513.html I see the results but those are mostly end-users and are testing the proxied-dns resolver on their adsl box. And it is my understanding also the tests from Osterweil and Bellis show the errors in the end-user adsl box. So, there is ample evidence that for end-users their proxied dns service has troubles (all over the place). - From Osterweil, it became clear the 1500-point changes things. - From Bellis, we know that that non-proxied DNS packets are OK. .org is talked about but seems to be solved by not appending NS RR sets to DNSKEY queries (making the reply is 1334 bytes). I see no evidence of IP fragmentation problems. Am I missing something? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqJNLUACgkQkDLqNwOhpPhKcwCfWyW3a3ktU3LJzclYFSp1twSk e7YAoIpn/PoF1e141R/OS8pUjZ5hku1F =cCce -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 17 05:35: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 C7CE53A6D79; Mon, 17 Aug 2009 05:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL3L7bXOT3W1; Mon, 17 Aug 2009 05:35:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0445D3A68CD; Mon, 17 Aug 2009 05:35:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md1K1-000BEA-0p for namedroppers-data0@psg.com; Mon, 17 Aug 2009 12:28:21 +0000 Received: from [209.85.132.250] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md1Ju-000BC6-4D for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 12:28:19 +0000 Received: by an-out-0708.google.com with SMTP id c3so1120770ana.26 for ; Mon, 17 Aug 2009 05:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Y3kHGkcUPKRKiQotISvBpQ1LUiG2rCPe/TaO88NN/Lg=; b=NyGQ7Big5XXod+0md/hjk3wcIEtD3VGeQw7JvR0+Rgu6NPU3VCH4JUcQXq+lVn8kR/ UwUuYR55Tz99MCAJ8VW+z71vWqEPvsFMcmKdwYUS7O/9bAh1HotRootQUZn4YKoVjHHH ZhN9RuUf+AML6wDR+glBX2yD8PNld8C5CmkSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=FLwQaWRCLU7KteIOzn+1XOAEbqCVZDdY8F3rNoBkFEI/XB/4nL/5bex8hD1w3kE/Oa rTLGmsy/riN+DcGANROimd3f2X3g7zjsrrkHpYMNH6/DIdWeLBbY3EuwC3lxThv427TT G7HbOKEVfoomJ92LvYQn+z42CysmIav9sBiaE= Received: by 10.101.102.12 with SMTP id e12mr3262645anm.144.1250512092388; Mon, 17 Aug 2009 05:28:12 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id c23sm2272363ana.8.2009.08.17.05.28.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 05:28:11 -0700 (PDT) Message-ID: <4A894CD9.7030307@gmail.com> Date: Mon, 17 Aug 2009 08:28:09 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] Size of DNSsec NXDOMAIN response Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I'm having trouble counting the number of actual likely bytes in NXDOMAIN with DNSsec. It seems to me that the result will never fit within 512 bytes? (Assuming SOA, NS, glue, etc.) I'm currently getting 1022 bytes with SOA alone, but there's several RRSIGs. Testing: dig www.123.456.powerdnssecc.org @D0.ORG.AFILIAS-NST.org. +dnssec +all Are there simplifications that I'm missing? From owner-namedroppers@ops.ietf.org Mon Aug 17 06: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 CAA2B28C174; Mon, 17 Aug 2009 06:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.798 X-Spam-Level: ** X-Spam-Status: No, score=2.798 tagged_above=-999 required=5 tests=[AWL=0.696, 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 tUVWn2yQEa2Z; Mon, 17 Aug 2009 06:00:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F21E28C163; Mon, 17 Aug 2009 06:00:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md1k7-000Es7-NI for namedroppers-data0@psg.com; Mon, 17 Aug 2009 12:55:19 +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 1Md1k2-000Eq2-JV for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 12:55:17 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Md1k1-0002i2-J1; Mon, 17 Aug 2009 13:55:13 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Md1k0-0001Nk-B1; Mon, 17 Aug 2009 13:55:12 +0100 Message-ID: From: "George Barwood" To: "W.C.A. Wijngaards" Cc: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <4A8934B5.7000106@nlnetlabs.nl> Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 13:55:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D8_01CA1F42.52FB8B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_03D8_01CA1F42.52FB8B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: "W.C.A. Wijngaards" To: "George Barwood" Cc: Sent: Monday, August 17, 2009 11:45 AM Subject: Re: [dnsext] EDNS Page Option draft > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi George, >=20 > On 08/17/2009 12:18 PM, George Barwood wrote: >> Nicholas Weaver has done some investigation, which suggests it is = broken >>=20 >> = http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01513.html >=20 > I see the results but those are mostly end-users and are testing > the proxied-dns resolver on their adsl box. And it is my = understanding > also the tests from Osterweil and Bellis show the errors in the > end-user adsl box. So, there is ample evidence that for end-users > their proxied dns service has troubles (all over the place). > - From Osterweil, it became clear the 1500-point changes things. > - From Bellis, we know that that non-proxied DNS packets are OK. Bellis and Weaver seem to not agree on this. Bellis: "All 24 units could route DNSSEC queries transparently to upstream resolverswithout flag or length limitations." http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf Weaver: "The situation is similar for the end user's connection.=20 On a query directly to our server from the applet, bypassing=20 the recursive resolver, the EDNS large request is successful=20 86% of the time (3635 out of 4211), the medium is successful=20 95% of the time (4019 out of 4211), and the small is successful=20 99% of the time (4179 out of 4211). This suggests that for the end user there is a significant problem with middleboxes. Many middleboxes=20 either can't NAT UDP fragments or do not reassemble fragmented=20 DNS traffic before analysis, but a significant number simply assume=20 that DNS packets are smaller than 1400B." suggesting that the 24 units tested were not fully representative, = AFAICS. Perhaps Ray Bellis could confirm that responses > 1500 bytes were = tested. =20 > .org is talked about but seems to be solved by not appending NS > RR sets to DNSKEY queries (making the reply is 1334 bytes). > I see no evidence of IP fragmentation problems. Am I > missing something? Responses larger than 1500 bytes seem inevitable during algorithm = upgrade / key rollover. My worry is that the protocol goes up a creek and then finds itself = without a paddle. Besides that, support for proxies that impose a 512 byte limit on = responses (even over TCP), and/or do not respect Z bits etc, seems desirable. I hope to include = that in the next version of the draft. Best regards, George > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkqJNLUACgkQkDLqNwOhpPhKcwCfWyW3a3ktU3LJzclYFSp1twSk > e7YAoIpn/PoF1e141R/OS8pUjZ5hku1F > =3DcCce > -----END PGP SIGNATURE----- > ------=_NextPart_000_03D8_01CA1F42.52FB8B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From: "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>
To: "George Barwood" <george.barwood@blueyonder.co.uk>
Cc: <namedroppers@ops.ietf.org>
Sent: Monday, August 17, 2009 11:45 = AM
Subject: Re: [dnsext] EDNS Page Option=20 draft

> -----BEGIN PGP SIGNED = MESSAGE-----
>=20 Hash: SHA1
>
> Hi George,
>
> On 08/17/2009 = 12:18 PM,=20 George Barwood wrote:
>> Nicholas Weaver has done some = investigation,=20 which suggests it is broken
>>
>> http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg= 01513.html
>
> I see the results but those are = mostly end-users=20 and are testing
> the proxied-dns resolver on their adsl = box.  And it=20 is my understanding
> also the tests from Osterweil and Bellis = show the=20 errors in the
> end-user adsl box.  So, there is ample = evidence that=20 for end-users
> their proxied dns service has troubles (all over = the=20 place).
> - From Osterweil, it became clear the 1500-point changes = things.
> - From Bellis, we know that that non-proxied DNS packets = are=20 OK.
 
Bellis and Weaver seem to not agree on=20 this.
 
Bellis: "All 24 units could route = DNSSEC queries=20 transparently
to upstream resolverswithout flag or = length=20 limitations."
 
= http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.= pdf
 
Weaver: "The situation is similar for the end user's = connection.=20
On a query directly to our server from = the applet,=20 bypassing
the recursive resolver, the EDNS large = request is=20 successful
86% of the time = (3635 out of 4211), the medium is = successful=20
95% of the time = (4019 out of 4211), and the small is = successful=20
99% of the time = (4179 out of=20 4211). This suggests that = for the end=20 user
there is a = significant problem=20 with middleboxes. = Many=20 middleboxes
either can't NAT = UDP fragments=20 or do not reassemble fragmented=20
DNS traffic before = analysis, but=20 a significant number simply = assume=20
that DNS packets = are smaller=20 than 1400B."
 
suggesting that the 24 units tested = were not fully=20 representative, AFAICS.
Perhaps Ray Bellis could confirm = that=20 responses > 1500 bytes were tested.
 
> .org is talked = about but=20 seems to be solved by not appending NS
> RR sets to DNSKEY queries = (making=20 the reply is 1334 bytes).
> I see no evidence of IP fragmentation=20 problems.  Am I
> missing something?
 
Responses larger than 1500 bytes seem = inevitable=20 during algorithm upgrade / key rollover.
My worry is that the protocol goes up a = creek and=20 then finds itself without a paddle.
 
Besides that, support for proxies = that impose=20 a 512 byte limit on responses (even over TCP),
and/or do not respect Z bits etc, = seems desirable. I hope to include that in the=20 next
version of the draft.
 
Best regards,
George

> Best=20 regards,
>   Wouter
> -----BEGIN PGP=20 SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> = Comment: Using=20 GnuPG with Fedora - http://enigmail.mozdev.org/
>
>=20 iEYEARECAAYFAkqJNLUACgkQkDLqNwOhpPhKcwCfWyW3a3ktU3LJzclYFSp1twSk
> = e7YAoIpn/PoF1e141R/OS8pUjZ5hku1F
> =3DcCce
> -----END PGP=20 SIGNATURE-----
>
------=_NextPart_000_03D8_01CA1F42.52FB8B80-- From owner-namedroppers@ops.ietf.org Mon Aug 17 06:37: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 549BB3A6EC8; Mon, 17 Aug 2009 06:37:07 -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 RnpAkWxYWGUJ; Mon, 17 Aug 2009 06:37:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13B2C28C15C; Mon, 17 Aug 2009 06:36:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md2IY-000JxU-0a for namedroppers-data0@psg.com; Mon, 17 Aug 2009 13:30:54 +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 1Md2IR-000Jwk-LV for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 13:30:50 +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 n7HDUbJt016025; Mon, 17 Aug 2009 06:30:37 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , namedroppers@ops.ietf.org Message-Id: <0E5D0F8E-98D0-41FE-9F8B-E6C50DAE29C7@icsi.berkeley.edu> From: Nicholas Weaver To: "W.C.A. Wijngaards" In-Reply-To: <4A8934B5.7000106@nlnetlabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 06:30:37 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <4A8934B5.7000106@nlnetlabs.nl> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 17, 2009, at 3:45 AM, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi George, > > On 08/17/2009 12:18 PM, George Barwood wrote: >> Nicholas Weaver has done some investigation, which suggests it is >> broken >> >> http://ops.ietf.org/lists/namedroppers/namedroppers.2009/ >> msg01513.html > > I see the results but those are mostly end-users and are testing > the proxied-dns resolver on their adsl box. And it is my > understanding > also the tests from Osterweil and Bellis show the errors in the > end-user adsl box. So, there is ample evidence that for end-users > their proxied dns service has troubles (all over the place). > - From Osterweil, it became clear the 1500-point changes things. > - From Bellis, we know that that non-proxied DNS packets are OK. Actually, those tests are for the recursive resolvers in the ISP/ network, not just the end box. The client generates a query which, from our server, will generate a huge amount of crud in terms of completely unrelated CNAMEs. But almost all this crud is meaningless, so the recursive resolver should strip it out. edns_large.netalyzr.icsi.berkeley.edu edns_medim.netalyzr.icsi.berkeley.edu Compare the results with a dig directly to our authority dig +dnssec edns_large.netalyzr.icsi.berkeley.edu @roland.icir.org from one without. Thus only the actual recursive resolver receives a large response, the part returned to the client should be much smaller because there are a lot of just totally pointless glue records involved. Making it a test of the recursive resolver, not the end client. End boxes are tested separately, and those are more likely to have a "can't do DNS >512" failure mode. One big problem is the simple firewall rules, such as: DENY all Allow DNS UDP will not work, because that will cause all the fragments beyond the first one to drop, unless the firewall is stateful with respect to fragments. But since TCP goes through many hoops to avoid fragmentation these days, and every other UDP protocol I can think of is happy to limit itself to <1500B packets, this doesn't prove a problem for anything else. > > .org is talked about but seems to be solved by not appending NS > RR sets to DNSKEY queries (making the reply is 1334 bytes). > I see no evidence of IP fragmentation problems. Am I > missing something? This "Not appending NS Rrsets" is specifically the effect of the recommendation: make sure your responses DO NOT fragment, because otherwise you will have problems. But if you make sure they don't fragment, you're generally OK. Yet if DNSSEC gets deployed, you will end up with a lot pushing that 1500B limit, and serious breakage whenever it goes over. The Internet IS broken for UDP fragments, its just everybody else doing UDP has already implicitly understood this or does not do behavior which tickles this. From owner-namedroppers@ops.ietf.org Mon Aug 17 07:02: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 7285028C257; Mon, 17 Aug 2009 07:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.133, 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 ZwpntAn6tdQs; Mon, 17 Aug 2009 07:02:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A5F228C236; Mon, 17 Aug 2009 07:02:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md2j1-000OLM-Em for namedroppers-data0@psg.com; Mon, 17 Aug 2009 13:58:15 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md2ix-000OIO-FZ for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 13:58:13 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 3F707C2DA5; Mon, 17 Aug 2009 14:58:09 +0100 (BST) Date: Mon, 17 Aug 2009 14:55:52 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , "W.C.A. Wijngaards" cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <1931B8FB0122AC8BDEF52618@Ximines.local> In-Reply-To: <06A65CB0596049F7A085A8C45494823F@localhost> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 17 August 2009 11:18:57 +0100 George Barwood wrote: > Nicholas Weaver has done some investigation, which suggests it is broken > > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01513.html > > and has stated > > "At least for DNS, fragmented UDP does not get through > a shockingly high percentage of the time, when non-fragmented > UDP gets through just fine. To my mind, this suggests that, > as an authority, whenever possible, make sure you fit in the > Ethernet MTU, unless you are happy with TCP fallback on those queries." > > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01693.html What would be interesting is what percentage of the time a) DNSSEC is supported b) EDNS0 @4096 does not get through c) EDNS0 @1200(ish) does get through I don't believe we have seen data on that. IE broken DNS and middleboxen might have a high correlation with resolver inability to support DNSSEC. If that's the case, fragmentation wouldn't be a worry. This statement (from the first link, and thus by Nick Weaver): > 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. Suggests that nearly 10% of EDNS capable hosts do not support large EDNS packets (i.e. ones requiring fragmentation). If these were all behind legacy firewalls (for instance) that didn't pass DNSSEC through anyway, then no amount of EDNS Page Options will help (even if the legacy firewall passed them through). -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 17 07:02: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 ACAEB28C23D; Mon, 17 Aug 2009 07:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.120, 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 vB7zFOTWuyRS; Mon, 17 Aug 2009 07:02:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E590728C24D; Mon, 17 Aug 2009 07:02:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md2kQ-000OXv-Ri for namedroppers-data0@psg.com; Mon, 17 Aug 2009 13:59:42 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md2kN-000OXT-Gg for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 13:59:41 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 4B58AC2DA7; Mon, 17 Aug 2009 14:59:38 +0100 (BST) Date: Mon, 17 Aug 2009 14:57:22 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "W.C.A. Wijngaards" , George Barwood cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <6186C5DD5F1E3636E3CEE754@Ximines.local> In-Reply-To: <4A8934B5.7000106@nlnetlabs.nl> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <4A8934B5.7000106@nlnetlabs.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 17 August 2009 12:45:09 +0200 "W.C.A. Wijngaards" wrote: > I see the results but those are mostly end-users and are testing > the proxied-dns resolver on their adsl box. And it is my understanding > also the tests from Osterweil and Bellis show the errors in the > end-user adsl box. So, there is ample evidence that for end-users > their proxied dns service has troubles (all over the place). > - From Osterweil, it became clear the 1500-point changes things. > - From Bellis, we know that that non-proxied DNS packets are OK. And moreover, from Bellis we know that where the "proxied-dns resolver on adsl box" is used, it isn't likely to support DNSSEC anyway. So EDNS Page Option won't help. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 17 07:44: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 89B223A6AF1; Mon, 17 Aug 2009 07:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 PTvdojWFgltR; Mon, 17 Aug 2009 07:44:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9229D3A6F21; Mon, 17 Aug 2009 07:44:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md3MK-0003vX-3F for namedroppers-data0@psg.com; Mon, 17 Aug 2009 14:38: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 1Md3MF-0003uq-Lt for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 14:38:49 +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 n7HEcVWW021207; Mon, 17 Aug 2009 07:38:32 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Message-Id: <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> From: Nicholas Weaver To: Alex Bligh In-Reply-To: <1931B8FB0122AC8BDEF52618@Ximines.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 07:38:31 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 17, 2009, at 6:55 AM, Alex Bligh wrote: > > > --On 17 August 2009 11:18:57 +0100 George Barwood > wrote: > >> Nicholas Weaver has done some investigation, which suggests it is >> broken >> >> http://ops.ietf.org/lists/namedroppers/namedroppers.2009/ >> msg01513.html >> >> and has stated >> >> "At least for DNS, fragmented UDP does not get through >> a shockingly high percentage of the time, when non-fragmented >> UDP gets through just fine. To my mind, this suggests that, >> as an authority, whenever possible, make sure you fit in the >> Ethernet MTU, unless you are happy with TCP fallback on those >> queries." >> >> http://ops.ietf.org/lists/namedroppers/namedroppers.2009/ >> msg01693.html > > What would be interesting is what percentage of the time > a) DNSSEC is supported > b) EDNS0 @4096 does not get through > c) EDNS0 @1200(ish) does get through We didn't test B because the response has EDNS if the resolver's request has EDNS, and if EDNS was being stripped/blocked, it would failback and be counted as "Non EDNS". A and C are tested for, although C was only tested for later on (so fewer data points). If you have particular data analysis you would like to see on this, we can, we're currently starting to dig through the Mass Pile of Data. However, Bind's glue policy is moderately distinct, I wonder if we can find the set of glue policy etc which doesn't have EDNS?!? Hmm, need to think about it and think if its meaningful. > I don't believe we have seen data on that. IE broken DNS and > middleboxen > might have a high correlation with resolver inability to support > DNSSEC. > If that's the case, fragmentation wouldn't be a worry. ALMOST all resolvers (don't have the numbers) which advertise EDNS advertise also request DNSSEC (simply because thats Bind's default behavior). And the fragmentation problem was ONLY measured for those who do have EDNS availability >2000B. So yes, fragmentation IS a worry. :( > This statement (from the first link, and thus by Nick Weaver): >> 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. > > Suggests that nearly 10% of EDNS capable hosts do not support large > EDNS packets (i.e. ones requiring fragmentation). If these were > all behind legacy firewalls (for instance) that didn't pass > DNSSEC through anyway, then no amount of EDNS Page Options will > help (even if the legacy firewall passed them through). This is probably more likely devices which are fragmentation related, because they DID allow EDNS @1200ish, so they either don't care about DNS at all or are aware of EDNS, but some stupid rule doesn't allow fragments, or the part which cares about DNS doesn't handle fragments. From owner-namedroppers@ops.ietf.org Mon Aug 17 09:05: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 C1DA628C1B4; Mon, 17 Aug 2009 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.109, 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 eZTkxN-phntX; Mon, 17 Aug 2009 09:05:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E978428C287; Mon, 17 Aug 2009 09:05:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md4e6-000FbL-08 for namedroppers-data0@psg.com; Mon, 17 Aug 2009 16:01:18 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md4e2-000Fas-7a for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 16:01:16 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id CA6E4C2DA7; Mon, 17 Aug 2009 17:01:09 +0100 (BST) Date: Mon, 17 Aug 2009 16:58:51 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , George Barwood , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: In-Reply-To: <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Nick, >> What would be interesting is what percentage of the time >> a) DNSSEC is supported >> b) EDNS0 @4096 does not get through >> c) EDNS0 @1200(ish) does get through > > We didn't test B because the response has EDNS if the resolver's request > has EDNS, and if EDNS was being stripped/blocked, it would failback and > be counted as "Non EDNS". > > A and C are tested for, although C was only tested for later on (so fewer > data points). > > If you have particular data analysis you would like to see on this, we > can, we're currently starting to dig through the Mass Pile of Data. > > However, Bind's glue policy is moderately distinct, I wonder if we can > find the set of glue policy etc which doesn't have EDNS?!? Hmm, need to > think about it and think if its meaningful. I suppose the question is "of all the resolvers claiming DNSSEC support and EDNS0 support that actually respond at 1200 bytes-ish, what percentage do not respond at 4096 bytes-ish?" (i.e. what percentage are broken by fragmentation. > This is probably more likely devices which are fragmentation related, > because they DID allow EDNS @1200ish, so they either don't care about DNS > at all or are aware of EDNS, but some stupid rule doesn't allow > fragments, or the part which cares about DNS doesn't handle fragments. I'm trying to square this with Ray Bellis et al.'s data. I suppose one possibility is that the end user devices concerned are so broken that when a DNS query is sent to them, they are copying the whole query across (together with the OPT RR for EDNS0) and are sending that to the resolver, but fail to reassemble fragments. That's the only way I can see that they can (as Ray maintains) pass UDP fragments on port 53 OK provided they aren't addressed to the unit, still appear to be EDNS0 capable, and still result in your tests showing lots of problems with fragmented EDNS0 but not unfragmented EDNS0. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 17 09:06: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 D031928C2A3; Mon, 17 Aug 2009 09:06: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=[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 HoqzhVug+aql; Mon, 17 Aug 2009 09:06:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F420928C29B; Mon, 17 Aug 2009 09:05:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md4cS-000FPh-53 for namedroppers-data0@psg.com; Mon, 17 Aug 2009 15:59: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 1Md4cO-000FPF-At for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 15:59:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C7566B304F for ; Mon, 17 Aug 2009 15:59:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft In-Reply-To: Your message of "Mon, 17 Aug 2009 10:38:18 +0200." <4A8916FA.8050302@nlnetlabs.nl> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 17 Aug 2009 15:59:31 +0000 Message-ID: <16045.1250524771@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 17 Aug 2009 10:38:18 +0200 > From: "W.C.A. Wijngaards" > > If it turns out that IP is badly broken. And that the only > recourse is to have another big bad layer violation in the > DNS. Then, something like this draft can be the solution. unless we think DNS is the last wide-area UDP application who needs or will need payloads larger than path MTU, we're better off fixing IP fragmentation or adding UDP fragmentation (which is the approach i'm working on) than adding DNS fragmentation. From owner-namedroppers@ops.ietf.org Mon Aug 17 09:36: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 C08883A6B2D; Mon, 17 Aug 2009 09:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.096 X-Spam-Level: X-Spam-Status: No, score=-5.096 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 ZRoi7an1dtSX; Mon, 17 Aug 2009 09:36:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4B8728C1A3; Mon, 17 Aug 2009 09:36:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md58s-000Jm8-04 for namedroppers-data0@psg.com; Mon, 17 Aug 2009 16:33: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 1Md58n-000Jlj-Rj for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 16:33:03 +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 n7HGWmwb001541; Mon, 17 Aug 2009 09:32:48 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Message-Id: <2969ADE2-A048-4BFA-A4B0-0DE06453ED71@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Alex Bligh In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 09:32:48 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 17, 2009, at 8:58 AM, Alex Bligh wrote: > Nick, > >>> What would be interesting is what percentage of the time >>> a) DNSSEC is supported >>> b) EDNS0 @4096 does not get through >>> c) EDNS0 @1200(ish) does get through >> >> We didn't test B because the response has EDNS if the resolver's >> request >> has EDNS, and if EDNS was being stripped/blocked, it would failback >> and >> be counted as "Non EDNS". >> >> A and C are tested for, although C was only tested for later on (so >> fewer >> data points). >> >> If you have particular data analysis you would like to see on this, >> we >> can, we're currently starting to dig through the Mass Pile of Data. >> >> However, Bind's glue policy is moderately distinct, I wonder if we >> can >> find the set of glue policy etc which doesn't have EDNS?!? Hmm, >> need to >> think about it and think if its meaningful. > > I suppose the question is "of all the resolvers claiming DNSSEC > support > and EDNS0 support that actually respond at 1200 bytes-ish, what > percentage > do not respond at 4096 bytes-ish?" (i.e. what percentage are broken > by fragmentation. We did that. Its fragmentation, not 1300B EDNS, that causes most of the problems for recursive resolvers. (Unfortunately, that test was added later so only the more recent tests have that) For end hosts, rather than recursive resolvers, its about 1/3 of the problem cases is EDNS0 at 1300B, 2/3rds is fragmentation. >> This is probably more likely devices which are fragmentation related, >> because they DID allow EDNS @1200ish, so they either don't care >> about DNS >> at all or are aware of EDNS, but some stupid rule doesn't allow >> fragments, or the part which cares about DNS doesn't handle >> fragments. > > I'm trying to square this with Ray Bellis et al.'s data. I suppose > one possibility is that the end user devices concerned are so > broken that when a DNS query is sent to them, they are copying the > whole query across (together with the OPT RR for EDNS0) and are > sending > that to the resolver, but fail to reassemble fragments. That's the > only way I can see that they can (as Ray maintains) pass UDP > fragments on port 53 OK provided they aren't addressed to the unit, > still appear to be EDNS0 capable, and still result in your tests > showing lots of problems with fragmented EDNS0 but not > unfragmented EDNS0. On our test of end-user devices, its probably that we are testing a lot more different devices, and a lot more legacy devices. The test for end-user devices is a direct UDP request to our server, bypassing all other infrastructure. > > -- > Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 17 09:37: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 06E0628C1A3; Mon, 17 Aug 2009 09:37:42 -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 0jhib6l-p9+I; Mon, 17 Aug 2009 09:37:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34AA83A677C; Mon, 17 Aug 2009 09:37:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md5Af-000K1G-44 for namedroppers-data0@psg.com; Mon, 17 Aug 2009 16:34:57 +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 1Md5AT-000JzT-3P for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 16:34: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 n7HGYfPi001742; Mon, 17 Aug 2009 09:34:42 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> From: Nicholas Weaver To: Paul Vixie In-Reply-To: <16045.1250524771@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 09:34:41 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <16045.1250524771@nsa.vix.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 17, 2009, at 8:59 AM, Paul Vixie wrote: >> Date: Mon, 17 Aug 2009 10:38:18 +0200 >> From: "W.C.A. Wijngaards" >> >> If it turns out that IP is badly broken. And that the only >> recourse is to have another big bad layer violation in the >> DNS. Then, something like this draft can be the solution. > > unless we think DNS is the last wide-area UDP application who > needs or will need payloads larger than path MTU, we're better > off fixing IP fragmentation or adding UDP fragmentation (which > is the approach i'm working on) than adding DNS fragmentation. It might indeed be the case that DNS IS this case. After all, anyone else doing a UDP protocol NOW is going to run into the same problem, and rather than trying to work around broken middleboxes where some 10% of the time things fail, is going to either do path MTU discovery or the hack that works 99%+ of the time: assume Ethernet MTU and subtract a few bytes for safety. From owner-namedroppers@ops.ietf.org Mon Aug 17 09:53: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 6D13828C1C8; Mon, 17 Aug 2009 09:53: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=[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 0Q9AP-tBkqw1; Mon, 17 Aug 2009 09:53:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8570D28C1AF; Mon, 17 Aug 2009 09:53:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md5PM-000Lyk-7E for namedroppers-data0@psg.com; Mon, 17 Aug 2009 16:50: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 1Md5PI-000Lxn-GX for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 16:50:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B6FB9B3136; Mon, 17 Aug 2009 16:50:02 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Nicholas Weaver cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft In-Reply-To: Your message of "Mon, 17 Aug 2009 09:34:41 MST." <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <16045.1250524771@nsa.vix.com> <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 17 Aug 2009 16:50:02 +0000 Message-ID: <18326.1250527802@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Nicholas Weaver > Date: Mon, 17 Aug 2009 09:34:41 -0700 > > > unless we think DNS is the last wide-area UDP application who > > needs or will need payloads larger than path MTU, we're better > > off fixing IP fragmentation or adding UDP fragmentation (which > > is the approach i'm working on) than adding DNS fragmentation. > > It might indeed be the case that DNS IS this case. and we're ok with that? a datagram environment so hostile that new apps are encouraged to just find a way to do their work with small payloads and/or TCP? > After all, anyone else doing a UDP protocol NOW is going to run into the > same problem, and rather than trying to work around broken middleboxes > where some 10% of the time things fail, is going to either do path MTU > discovery or the hack that works 99%+ of the time: assume Ethernet MTU > and subtract a few bytes for safety. the solution we use for DNS has to be available to other apps, and if it is, then those middleboxes will be on the run, instead of us. From owner-namedroppers@ops.ietf.org Mon Aug 17 10:03: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 0973D28C2BF; Mon, 17 Aug 2009 10:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, 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 gwM+1+1ttmDS; Mon, 17 Aug 2009 10:03:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 448F028C1B0; Mon, 17 Aug 2009 10:03:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md5Xr-000NJs-CV for namedroppers-data0@psg.com; Mon, 17 Aug 2009 16:58:55 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md5Xn-000NJ0-26 for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 16:58:53 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 7196CC2DA5; Mon, 17 Aug 2009 17:58:49 +0100 (BST) Date: Mon, 17 Aug 2009 17:56:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , George Barwood , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <5683A53EB10D3D29C5E78C21@Ximines.local> In-Reply-To: <2969ADE2-A048-4BFA-A4B0-0DE06453ED71@ICSI.Berkeley.EDU> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <2969ADE2-A048-4BFA-A4B0-0DE06453ED71@ICSI.Berkeley.EDU> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > For end hosts, rather than recursive resolvers, its about 1/3 of the > problem cases is EDNS0 at 1300B, 2/3rds is fragmentation. So, of those that could receive DNSSEC, and have EDNS0 enabled, but exhibit failures with large packets (between 46 and 49% of all end users, 58% of resolvers), around 13% have problems with large packets, of which in 2/3 this is down to fragmentation (8% of end-users/resolvers that might otherwise work). > The test for end-user devices is a direct UDP request to our server, > bypassing all other infrastructure. Implying at least circa 10% of end users can't receive fragmented UDP packets at all. Depressing. It's very tempting to suggest we ensure *every* DNS packet requires UDP fragmentation in order to make people fix their middleboxes, but ok, count me in the "something must be done" camp. However, think that something isn't EDNS Page Option in current form. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 17 11:14: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 3847B3A6407; Mon, 17 Aug 2009 11:14:57 -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 aFuoxNo+0rZF; Mon, 17 Aug 2009 11:14:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 429973A6F05; Mon, 17 Aug 2009 11:14:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md6d2-000BFs-0g for namedroppers-data0@psg.com; Mon, 17 Aug 2009 18:08:20 +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 1Md6cm-000BCQ-HD for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 18:08:10 +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 n7HI7r9a012323; Mon, 17 Aug 2009 11:07:53 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Message-Id: <083C9EA0-7D48-4284-BADD-37EFAF237339@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Alex Bligh In-Reply-To: <5683A53EB10D3D29C5E78C21@Ximines.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 11:07:53 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <2969ADE2-A048-4BFA-A4B0-0DE06453ED71@ICSI.Berkeley.EDU> <5683A53EB10D3D29C5E78C21@Ximines.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 17, 2009, at 9:56 AM, Alex Bligh wrote: >> For end hosts, rather than recursive resolvers, its about 1/3 of the >> problem cases is EDNS0 at 1300B, 2/3rds is fragmentation. > > So, of those that could receive DNSSEC, and have EDNS0 enabled, > but exhibit failures with large packets (between 46 and 49% of > all end users, 58% of resolvers), around 13% have problems > with large packets, of which in 2/3 this is down to fragmentation > (8% of end-users/resolvers that might otherwise work). Close, but not quite. Of these recursive resolvers, almost ALL these failures are due to fragmentation rather than a middlebox which assumes DNS <=512B. For END HOST systems directly doing a request to an arbitrary internet host for DNS, about 13% have problems, of which ~2/3rds are due to fragmentation, and ~1/3rds are due to a middlebox either not understanding EDNS or not able to handle DNS replies >512B. >> The test for end-user devices is a direct UDP request to our server, >> bypassing all other infrastructure. > > Implying at least circa 10% of end users can't receive fragmented UDP > packets at all. Depressing. More depressing is that its 10% of the recursive resolvers!?! Which is just really sad. > > It's very tempting to suggest we ensure *every* DNS packet requires > UDP fragmentation in order to make people fix their middleboxes, > but ok, count me in the "something must be done" camp. However, think > that something isn't EDNS Page Option in current form. My thought is simply do a user-level fragmentation: An additional EDNS RR that is EDNS MTU rather than EDNS message size, with the DNS authority's response simply breaking the packet up at the application level (application-level fragmentation), with no notion of indidividual packet reliability, just a mini-header on the 2nd and subsequent packets that is the transaction ID and the sequence # of the reply. You don't lose any reliability over working IP fragmentation (the additional overhead is UDP header + mini-header per additional packet after the first, and both have an all-or-nothing failure mode), but work even when you don't have IP fragmentation working. From owner-namedroppers@ops.ietf.org Mon Aug 17 11:59: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 3B6A128C2F4; Mon, 17 Aug 2009 11:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[AWL=-1.031, 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 cIlNU3sjFIlR; Mon, 17 Aug 2009 11:59:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2288228C2ED; Mon, 17 Aug 2009 11:59:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md7Lu-000HmW-Tj for namedroppers-data0@psg.com; Mon, 17 Aug 2009 18:54:42 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md7Lm-000Hkb-3a; Mon, 17 Aug 2009 18:54:39 +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=DcLDd+BiwgyhzAdowWczlvP08MYM0ZSxNS6T0/H2FpSkcNjJDvXEFAND frQi17HRsC1+XMTyrL81kLkP/71OfL7Kl2tC57wu7q2AhVPda0QN69uk3 he34ClLKlnSut3i; 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=1250535274; x=1282071274; 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]=20EDNS=20Page=20Option=20draft|Date:=20Mon,=2017=20Au g=202009=2020:54:22=20+0200|Message-ID:=20|To:=20"George=20Barwood"=20|Cc:=20namedroppers@ops.ietf.org,=0D=0A=09owner-nam edroppers@ops.ietf.org,=0D=0A=09"W.C.A.=20Wijngaards"=20< wouter@NLnetLabs.nl>|MIME-Version:=201.0|In-Reply-To:=20< BFE9C9553A1A4D7DB134D76A078AC55C@localhost>|References: =20<5722A99A87EA478BAC81D71ED194B500@localhost>=20<4A8916 FA.8050302@nlnetlabs.nl>=20<06A65CB0596049F7A085A8C454948 23F@localhost>=20<4A8934B5.7000106@nlnetlabs.nl>=20; bh=Lf6oyvlTzKFiVtSju8DHGpy4312++SbOPeZ8CwmYP+c=; b=Updv4PbDjdOqOs9T41d/hfjpcshaFX52hajdvHBITjxO//JivLNtuOat wUmEitrwJW42Unoh4tLyFnPqja4OSQCYzWXdl9PxyqZ8AcZIEMhgVk2cm U+kud/HLlw0PKeY; X-IronPort-AV: E=Sophos;i="4.43,398,1246834800"; d="scan'208";a="12303137" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 17 Aug 2009 19:54:26 +0100 In-Reply-To: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <4A8934B5.7000106@nlnetlabs.nl> To: "George Barwood" Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, "W.C.A. Wijngaards" Subject: Re: [dnsext] EDNS Page Option draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 17 Aug 2009 20:54:22 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 17/08/2009 07:54:31 PM, Serialize complete at 17/08/2009 07:54:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0067DAA6C1257615_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0067DAA6C1257615_= Content-Type: text/plain; charset="US-ASCII" > suggesting that the 24 units tested were not fully representative, AFAICS. The 24 units were representative of the top-selling units in the UK (ADSL integrated) and US (dual-ethernet) markets. > Perhaps Ray Bellis could confirm that responses > 1500 bytes were tested. They were indeed tested. I've separately proposed that we should do some more indepth investigation to find out what's causing the 15% loss of fragmented packets shown by Netalyzr. I plan to try and start that up once I get back from vacation. Ray --=_alternative 0067DAA6C1257615_= Content-Type: text/html; charset="US-ASCII" > suggesting that the 24 units tested were not fully representative, AFAICS.

The 24 units were representative of the top-selling units in the UK (ADSL integrated) and US (dual-ethernet) markets.

> Perhaps Ray Bellis could confirm that responses > 1500 bytes were tested.

They were indeed tested.

I've separately proposed that we should do some more indepth investigation to find out what's causing the 15% loss of fragmented packets shown by Netalyzr.   I plan to try and start that up once I get back from vacation.

Ray
--=_alternative 0067DAA6C1257615_=-- From owner-namedroppers@ops.ietf.org Mon Aug 17 12: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 6B97E28C1D8; Mon, 17 Aug 2009 12:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[AWL=-0.988, 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 QTd8lkNYqU+7; Mon, 17 Aug 2009 12:14:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6412028C2F2; Mon, 17 Aug 2009 12:14:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md7Zm-000Jbz-Fy for namedroppers-data0@psg.com; Mon, 17 Aug 2009 19:09:02 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md7Zh-000Jam-FZ; Mon, 17 Aug 2009 19:08:59 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=hVw32YQyXZZwLVGF9vgeelevawrIar8AiydpMdS2rJYhEOh1za+7S0US HdacfYvMY6eqe3Rg4yXLPXtvNCixIoneBKwM8sPUelEZHrxvbsTwemTSv mVPP17u+eDcMyQ5; 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=1250536137; x=1282072137; 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]=20EDNS=20Page=20Option=20draft|Date:=20Mon,=2017=20Au g=202009=2021:08:41=20+0200|Message-ID:=20|To:=20Alex=20Bligh=20|Cc:=20Alex=20B ligh=20,=0D=0A=09George=20Barwood=20,=0D=0A=09namedroppers@ops. ietf.org,=0D=0A=09Nicholas=20Weaver=20,=0D=0A=09owner-namedroppers@ops.ietf.org,=0D=0A =09"W.C.A.=20Wijngaards"=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20<5722A99A87EA478BAC81D7 1ED194B500@localhost>=20<4A8916FA.8050302@nlnetlabs.nl> =20<06A65CB0596049F7A085A8C45494823F@localhost>=20<1931B8 FB0122AC8BDEF52618@Ximines.local>=20<2E4F4ECB-43B9-4948-8 16F-289E5C15454A@icsi.berkeley.edu>=20; bh=RRmHRRGTxeV0vMxTyZGCV9+URAiZGOWJu46imJOCih8=; b=G63mNH3K9OazToq3+ZfbzvIuCy0twusIEe3JAqgK5edcMLrFQ3wt7PSD k6sVf47nCCbprw0Sh3/HdNEyShGjf63HhHSVJl1S0Cru8CvtCtYVk1oC3 OaFyGdk1ENIW8AB; X-IronPort-AV: E=Sophos;i="4.43,398,1246834800"; d="scan'208";a="12303216" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 17 Aug 2009 20:08:46 +0100 In-Reply-To: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> To: Alex Bligh Cc: Alex Bligh , George Barwood , namedroppers@ops.ietf.org, Nicholas Weaver , owner-namedroppers@ops.ietf.org, "W.C.A. Wijngaards" Subject: Re: [dnsext] EDNS Page Option draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 17 Aug 2009 21:08:41 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 17/08/2009 08:08:55 PM, Serialize complete at 17/08/2009 08:08:55 PM Content-Type: multipart/alternative; boundary="=_alternative 00692AC2C1257615_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 00692AC2C1257615_= Content-Type: text/plain; charset="US-ASCII" > I'm trying to square this with Ray Bellis et al.'s data. I suppose > one possibility is that the end user devices concerned are so > broken that when a DNS query is sent to them, they are copying the > whole query across (together with the OPT RR for EDNS0) and are sending > that to the resolver, but fail to reassemble fragments. That's the > only way I can see that they can (as Ray maintains) pass UDP > fragments on port 53 OK provided they aren't addressed to the unit, > still appear to be EDNS0 capable, and still result in your tests > showing lots of problems with fragmented EDNS0 but not > unfragmented EDNS0. For the _proxies_ our tests showed that most units did indeed just blindly copy the OPT RR from stub to recursor, even if the proxy itself was subsequently unable to reassemble the returned fragments. Ray --=_alternative 00692AC2C1257615_= Content-Type: text/html; charset="US-ASCII"
> I'm trying to square this with Ray Bellis et al.'s data. I suppose
> one possibility is that the end user devices concerned are so
> broken that when a DNS query is sent to them, they are copying the
> whole query across (together with the OPT RR for EDNS0) and are sending
> that to the resolver, but fail to reassemble fragments. That's the
> only way I can see that they can (as Ray maintains) pass UDP
> fragments on port 53 OK provided they aren't addressed to the unit,
> still appear to be EDNS0 capable, and still result in your tests
> showing lots of problems with fragmented EDNS0 but not
> unfragmented EDNS0.
For the _proxies_ our tests showed that most units did indeed just blindly copy the OPT RR from stub to recursor, even if the proxy itself was subsequently unable to reassemble the returned fragments.

Ray
--=_alternative 00692AC2C1257615_=-- From owner-namedroppers@ops.ietf.org Mon Aug 17 13:53: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 111733A6DC7; Mon, 17 Aug 2009 13:53:23 -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 YEExhJ4viAVY; Mon, 17 Aug 2009 13:53:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31FE03A6783; Mon, 17 Aug 2009 13:53:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md97l-000824-5v for namedroppers-data0@psg.com; Mon, 17 Aug 2009 20:48:13 +0000 Received: from [209.85.216.174] (helo=mail-px0-f174.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md97h-000807-11 for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 20:48:11 +0000 Received: by pxi3 with SMTP id 3so1739447pxi.32 for ; Mon, 17 Aug 2009 13:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.134.4 with SMTP id l4mr1405587wan.118.1250542088041; Mon, 17 Aug 2009 13:48:08 -0700 (PDT) In-Reply-To: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> Date: Mon, 17 Aug 2009 13:48:07 -0700 Message-ID: Subject: Re: [dnsext] EDNS Page Option draft From: Matthew Dempsky To: Ray.Bellis@nominet.org.uk 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 17, 2009 at 12:08 PM, wrote: > For the _proxies_ our tests showed that most units did indeed just blindly > copy the OPT RR from stub to recursor, even if the proxy itself was > subsequently unable to reassemble the returned fragments. Are you implying that's desirable or undesirable behavior? I read your tone to imply it's undesirable, but it seems to be the behavior suggested by draft-ietf-dnsext-dnsproxy-06. From owner-namedroppers@ops.ietf.org Mon Aug 17 13:53: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 1D4BC3A6DC7; Mon, 17 Aug 2009 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwgbaZ1HoRKp; Mon, 17 Aug 2009 13:53:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 022823A6AE9; Mon, 17 Aug 2009 13:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md97v-000854-AY for namedroppers-data0@psg.com; Mon, 17 Aug 2009 20:48:23 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md97h-00080Z-M4 for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 20:48:12 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 8055A327A6F; Mon, 17 Aug 2009 20:48:08 +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 8214E327A5C; Mon, 17 Aug 2009 20:48:07 +0000 (UTC) Message-ID: <4A89C206.2050100@isc.org> Date: Mon, 17 Aug 2009 15:48:06 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: George Barwood CC: Alex Bligh , Nicholas Weaver , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <5722A99A87EA478BAC81D71ED194B500@localhost> <9FFAC887CC6EF10139B3044E@Ximines.local> <283378D8-912F-4F42-9C66-C457305D7F4B@icsi.berkeley.edu> <6E8FF2FD39404617F51D2230@nimrod.local> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > For this scenario, servers could keep version information at > the RRset level. Alternatively copies of changed RRsets, can be > kept for a short period after an update, if there are outstanding > EDNS Page transactions active on them. There are many possibilities. This touches on my main reason for not liking this page thing. It puts a lot of complication in a resolver, where the most complexity already lives. The most straight forward method here is to remember the item sent back to the client for a short time (2-3 seconds) and then send the next page from that cache. However, this means state must be maintained on the server in such a way that we don't know when the client is done with it. After all, just because all parts of the response are transmitted does not mean one can free the state -- there could be packet loss. I would rather just use TCP than this, which I think will cause more complication and problems than it solves. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqJwgYACgkQ+NNi0s9NRJ3RdwCgps2m8xCz06FC4IrcAUrHY6gH nFwAoKUTzRa0of1pbiIgmG+m0ddRmhMe =V+5t -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 17 14:24: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 9E6563A67DD; Mon, 17 Aug 2009 14:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.092, 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 xhODa7hWrkBr; Mon, 17 Aug 2009 14:24:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A888E28C1E3; Mon, 17 Aug 2009 14:24:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md9cc-000D0J-6B for namedroppers-data0@psg.com; Mon, 17 Aug 2009 21:20:06 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md9cX-000CzT-CH for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 21:20:03 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id D25E9C2DA5; Mon, 17 Aug 2009 22:19:59 +0100 (BST) Date: Mon, 17 Aug 2009 22:20:16 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Matthew Dempsky , Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <4431D05BC3A4E329EF9EA39C@nimrod.local> In-Reply-To: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 17 August 2009 13:48:07 -0700 Matthew Dempsky wrote: > On Mon, Aug 17, 2009 at 12:08 PM, wrote: >> For the _proxies_ our tests showed that most units did indeed just >> blindly copy the OPT RR from stub to recursor, even if the proxy itself >> was subsequently unable to reassemble the returned fragments. > > Are you implying that's desirable or undesirable behavior? I read > your tone to imply it's undesirable, but it seems to be the behavior > suggested by draft-ietf-dnsext-dnsproxy-06. I am not the author, but it seems to me that it is the combination of forwarding the OPT RR saying EDNS0@4096 is supported AND dropping the fragments which is bad. Para 4.4.3 of the above draft says: Therefore (irrespective of which of the methods above is in use) proxies SHOULD be capable of forwarding UDP packets up to a payload size of at least 4096 octets. "Proxying" the OPT RR and allowing the replies through, whilst yucky and possibly (*) contrary to RFC2671 para 4.1 "OPT RRs shall never be cached, forwarded, or stored in or loaded from master files.", is far less dangerous. (*)=this would depend what is meant by 'forwarded' - I presume it means in the sense of an old DNS "forwarder", as opposed to IP forwarding or some L4 proxy behaviour. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 17 14:39: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 81B703A6AE4; Mon, 17 Aug 2009 14:39:52 -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 IWOYBoEaGNPG; Mon, 17 Aug 2009 14:39:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BECF28C1B9; Mon, 17 Aug 2009 14:39:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md9r6-000EjR-9m for namedroppers-data0@psg.com; Mon, 17 Aug 2009 21:35:04 +0000 Received: from [209.85.216.174] (helo=mail-px0-f174.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md9r2-000Eio-Px for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 21:35:02 +0000 Received: by pxi3 with SMTP id 3so1762459pxi.32 for ; Mon, 17 Aug 2009 14:34:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.103.9 with SMTP id f9mr5082016wam.227.1250544899752; Mon, 17 Aug 2009 14:34:59 -0700 (PDT) In-Reply-To: <4431D05BC3A4E329EF9EA39C@nimrod.local> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> Date: Mon, 17 Aug 2009 14:34:59 -0700 Message-ID: Subject: Re: [dnsext] EDNS Page Option draft From: Matthew Dempsky To: Alex Bligh Cc: Ray.Bellis@nominet.org.uk, 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 17, 2009 at 2:20 PM, Alex Bligh wrote: > "Proxying" the OPT RR and allowing the replies through, whilst yucky > and possibly (*) contrary to RFC2671 para 4.1 "OPT RRs shall never > be cached, forwarded, or stored in or loaded from master files.", > is far less dangerous. This is perhaps deviating from the thread subject, but the reason I brought it up is I'm concerned that recommending DNS proxies to forward OPT records without any inspection limits what new EDNS option mechanisms can be introduced. E.g., in this thread there was a suggestion that the server could fragment the DNS response at the UDP level instead of the IP level. This would certainly require proxy support to work correctly, and could not be introduced if proxies are going to break the functionality. I'd kind of like to see some mechanism for proxies to know which EDNS options are safe to include in forwarded queries without needing to be aware of all options in use. E.g., suppose (going forward) even numbers are reserved for options that are safe to forward while proxies should strip out odd numbers that they don't know about. (The PNG file format uses something similar: chunk type tags are 4 characters long, and the case of each character is a flag to indicate to tools whether the chunk can be handled opaquely or not.) From owner-namedroppers@ops.ietf.org Mon Aug 17 15:49: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 3A0893A6A0E; Mon, 17 Aug 2009 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 Tg7dG3FM3noX; Mon, 17 Aug 2009 15:49:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 441B73A6A7C; Mon, 17 Aug 2009 15:48:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdAu2-000MSS-NK for namedroppers-data0@psg.com; Mon, 17 Aug 2009 22:42: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 1MdAty-000MRv-7v for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 22:42:08 +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 n7HMg2sO008201; Mon, 17 Aug 2009 15:42:02 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Paul Vixie In-Reply-To: <18326.1250527802@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Mon, 17 Aug 2009 15:42:01 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <16045.1250524771@nsa.vix.com> <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> <18326.1250527802@nsa.vix.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 17, 2009, at 9:50 AM, Paul Vixie wrote: >> From: Nicholas Weaver >> Date: Mon, 17 Aug 2009 09:34:41 -0700 >> >>> unless we think DNS is the last wide-area UDP application who >>> needs or will need payloads larger than path MTU, we're better >>> off fixing IP fragmentation or adding UDP fragmentation (which >>> is the approach i'm working on) than adding DNS fragmentation. >> >> It might indeed be the case that DNS IS this case. > > and we're ok with that? a datagram environment so hostile that new > apps are > encouraged to just find a way to do their work with small payloads > and/or TCP? Its NOT hostile to new apps. ITs pretty simple: Ethernet MTU - small safety factor pretty much always works, anything more and you WILL always have fragmentation happening. Can anyone name any major UDP application other than DNSSEC that relies on sending >1500B packets that are fragmented in the IP layer, rather than doing any fragmentation in the application layer? Especially since this isn't a problem for most DNS, only DNSSEC. So what will happen? People turn on DNSSEC, get either failures and timeouts and fallbacks to TCP on the resolver end, greatly increased load on the authority end, and either the authorities work around things by making their responses small, or the resolvers turn off DNSSEC. If we actually want DNSSEC over UDP, we should resign ourselves to doing an application-level fragmentation when responses exceed the Ethernet MTU. Because there is now enshrined in the de-facto Internet reality two limits: The Ethernet MTU, and devices that can't handle fragments. From owner-namedroppers@ops.ietf.org Mon Aug 17 16:30: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 EB05928C213; Mon, 17 Aug 2009 16:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 eNVbngdlL9s0; Mon, 17 Aug 2009 16:30:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C38133A6D90; Mon, 17 Aug 2009 16:30:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdBah-00016e-Jk for namedroppers-data0@psg.com; Mon, 17 Aug 2009 23:26: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 1MdBaZ-000150-6Q for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 23:26: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 2F532E601C; Mon, 17 Aug 2009 23:26: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 n7HNQ1YG092266; Tue, 18 Aug 2009 09:26:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908172326.n7HNQ1YG092266@drugs.dv.isc.org> To: "George Barwood" Cc: "W.C.A. Wijngaards" , namedroppers@ops.ietf.org From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Mon, 17 Aug 2009 11:18:57 +0100." <06A65CB0596049F7A085A8C45494823F@localhost> Date: Tue, 18 Aug 2009 09:26:01 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <06A65CB0596049F7A085A8C45494823F@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "W.C.A. Wijngaards" > To: "George Barwood" > Cc: > Sent: Monday, August 17, 2009 9:38 AM > Subject: Re: [dnsext] EDNS Page Option draft > > > > My opinion about the piece. I hope that IP fragmentation is not > > broken, and effort to fix IP itself is the first concern. > > Nicholas Weaver has done some investigation, which suggests it is broken > > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01513.html > > and has stated > > "At least for DNS, fragmented UDP does not get through > a shockingly high percentage of the time, when non-fragmented > UDP gets through just fine. To my mind, this suggests that, > as an authority, whenever possible, make sure you fit in the > Ethernet MTU, unless you are happy with TCP fallback on those queries." > > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01693.html Lots of which is *not* the result of IP fragmentation but is the result of broken APPLICATION layer DNS proxies. Application layer DNS proxies are in a position to adjust the EDNS UDP size advertised upstream and the size returned to the client. They don't have to just pass through the packet and hope that the packet they emit is compatible with the buffer sizes they are using. Yes there are firewalls which limit DNS to 512 bytes. The way to fix that is to talk to the firewall vendors to change the defaults. Unless the message is signed the firewalls can even adjust the EDNS size to something they are more comfortable with like a DNS proxy can. Yes there are firewalls which don't handled IP fragments well. The way to fix that is to talk to the firewall vendors. They can re-assemble the packet before applying filter rules or let through all fragments. Either of these strategies will deal with the issue. > It would actually be quite surprising to me if it was not broken. > This capability is apparently not required for current internet use, > hence it has evolved to a state where it doesn't work. Fragmented IP works through NATs. It works with all the end boxes. Some firewalls block fragments but that is purely configuration. IP fragmentation isn't the ogre here. Bad middleboxes are. We just need to talk to the middleboxes vendors so that new products are fixed. We can handle the existing broken ones. We just don't want the problem to get significantly bigger than it is which is a matter of education and not protocol change. > It may be that TCP fallback is adequate, but I think it's worth considering > an alternative solution. > > I worry that resolvers may start establishing a TCP connection before > the UDP attempt has failed - since the failure is a "slow" timeout. Current iterative clients go to TCP on truncation. TCP connect timeouts are much worse than UDP timeouts. Sane clients at least make sure the server is up via UDP before going to TCP. > I think that could lead to problems. > > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 17 17:07: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 7095A3A6B5D; Mon, 17 Aug 2009 17:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 ljOibAZWQzk1; Mon, 17 Aug 2009 17:07:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4DB43A6F8C; Mon, 17 Aug 2009 17:07:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdC6X-0004oU-Oa for namedroppers-data0@psg.com; Mon, 17 Aug 2009 23:59:09 +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 1MdC6T-0004ng-45 for namedroppers@ops.ietf.org; Mon, 17 Aug 2009 23:59:07 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D1D74E601C; Mon, 17 Aug 2009 23:59:03 +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 n7HNwxGw092677; Tue, 18 Aug 2009 09:59:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908172359.n7HNwxGw092677@drugs.dv.isc.org> To: Alex Bligh Cc: Nicholas Weaver , George Barwood , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Mon, 17 Aug 2009 16:58:51 +0100." Date: Tue, 18 Aug 2009 09:58:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Alex Bligh writes: > Nick, > > >> What would be interesting is what percentage of the time > >> a) DNSSEC is supported > >> b) EDNS0 @4096 does not get through > >> c) EDNS0 @1200(ish) does get through > > > > We didn't test B because the response has EDNS if the resolver's request > > has EDNS, and if EDNS was being stripped/blocked, it would failback and > > be counted as "Non EDNS". > > > > A and C are tested for, although C was only tested for later on (so fewer > > data points). > > > > If you have particular data analysis you would like to see on this, we > > can, we're currently starting to dig through the Mass Pile of Data. > > > > However, Bind's glue policy is moderately distinct, I wonder if we can > > find the set of glue policy etc which doesn't have EDNS?!? Hmm, need to > > think about it and think if its meaningful. > > I suppose the question is "of all the resolvers claiming DNSSEC support > and EDNS0 support that actually respond at 1200 bytes-ish, what percentage > do not respond at 4096 bytes-ish?" (i.e. what percentage are broken > by fragmentation. > > > This is probably more likely devices which are fragmentation related, > > because they DID allow EDNS @1200ish, so they either don't care about DNS > > at all or are aware of EDNS, but some stupid rule doesn't allow > > fragments, or the part which cares about DNS doesn't handle fragments. > > I'm trying to square this with Ray Bellis et al.'s data. I suppose > one possibility is that the end user devices concerned are so > broken that when a DNS query is sent to them, they are copying the > whole query across (together with the OPT RR for EDNS0) and are sending > that to the resolver, but fail to reassemble fragments. That's the > only way I can see that they can (as Ray maintains) pass UDP > fragments on port 53 OK provided they aren't addressed to the unit, > still appear to be EDNS0 capable, and still result in your tests > showing lots of problems with fragmented EDNS0 but not > unfragmented EDNS0. They copy the query sometime adjusting the id. The answer then comes into a buffer smaller than the EDNS UDP size and the resulting malformed packet is sent back to the original client. The original client then rejects it. That at least is what my Netgear WGR614v6 does. Mark e.g. % dig +dnssec se dnskey @192.168.1.1 ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.3.6-P1 <<>> +dnssec se dnskey @192.168.1.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13407 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;se. IN DNSKEY ;; ANSWER SECTION: se. 3600 IN DNSKEY 257 3 5 AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ1wcTkypSExLC BPMS0wWkrA1n7t5hcM86VD94L8oEd9jnHdjxreguOZYEBWkckajU0tBW wEPMoEwepknpB14la1wy3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6 FdFL9wyCflV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3AapH2G XCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNSM4q3zGhuly4NrF/t 9s9jakbWzd4PM1Q551XIEphRGyqcbA2JTU3/mcUVKfgrH7nxaPz5DoUB 7TKYyQgsTlc= se. 3600 IN DNSKEY 256 3 5 AwEAAZzN62+7wyMKUs06PMCvJf2FV/mo7phe+7447lPcvJvOF2uZ0nou 87Yp1waA2FPR84VWmK5qduytrNGpmBl1HM2FsDbdllA+TdgJvGETXHkX Hpxu5FkUtlTzdLmiKZ4Q/0JmHlftHGGQ5EBhbDCZbbtORXesvJvxnRDR 6WCngcV5 se. 3600 IN DNSKEY 256 3 5 AwEAAc9B2MqxtXW/bQUYBV5zHf1z8e8MRSVWleDlQ3XZaOMlki4g4qdX hJ2rHN69ZzmvMj2DjTvLd8lMTN54NiHntofBIg0ZJ9pi0pcDemeeVQ7B h7T1OYzaM2rnId7xfSaoXBdX+6tMhkB/3CXM/cgqgar33emkhzdPUDdS 8FYNBGuL se. 3600 IN DNSKEY 256 3 5 AwEAAeplhwBO0eadnSP6xMiFQyQ8PpVjHeutOzHSn5a47h48aPwnTUFp JzAWbHElXtweFU9g5gMtatNhHdofXz7ndsEoFArNS2M4DapSPaklrZGB SIdSMAUrhKsDPsmwIBqLHQgYVeAx4De4aEobnpTcVX/221w1+zpckwgh F79trWZD se. 3600 IN DNSKEY 257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc= se. 3600 IN RRSIG DNSKEY 5 1 3600 20090822001951 20090816001810 33786 se. uvhU3jWa+Jq04rctYryXFhXpUyasEcEDbkcMkwZ7qQ7GYwhCNsWkzy0U tt9US2BFD7M6z2NILqrgfhbEZCvmTMFxnbpW9Oz8qfLyskh43ERKLJ3N Dl7yWk/cMVhLseIHu9ih9r89upYLXipLidnrAoVsjFnhS3kZKQXWMdiO 1VE= se. 3600 IN RRSIG DNSKEY 5 1 3600 20090914000000 20090804080536 8779 se. gGtYyS7qZ89UgHHxzyfs754dtdpbipQV+SfwLxWDsBWNz8qZ2RHO82vY aqEBVcA3xo1onmRdDrijFvy28//HmcC3Jb7ZkMh5UAxo+GFHMZnSo0aJ UhHGNsy2Ul2YjqRUKJoOmlMkX/GhcrOUCZFkgmZPEalrlk74nnYSdB5M 4KbdCGJM2Wm82X5gO7ahe+ozqfGOu+pxM2wMOgdthFSOYkA1QVjKLkgr fc8/xo04WWCHudz/ldmng4myVzE4Zv4TJYuqOk9HXjKmdtWIsIQlrCWP 2SU2lFvElGJ/DvOMPj2z1QtPpbjNb8+q8LpahhJlljVSjG14mnqxKob0 LLC0QQ== ;; Query time: 606 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Aug 18 09:57:18 2009 ;; MSG SIZE rcvd: 1500 % > -- > Alex Bligh > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 17 17:29: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 D042C3A6D15; Mon, 17 Aug 2009 17:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feiYhwk9sdQN; Mon, 17 Aug 2009 17:29:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65A293A6C0A; Mon, 17 Aug 2009 17:29:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdCWi-0008h4-43 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 00:26:12 +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 1MdCWc-0008fL-GT for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 00:26:09 +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 B1991E609D; Tue, 18 Aug 2009 00:26: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 n7I0Q3X7093210; Tue, 18 Aug 2009 10:26:03 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908180026.n7I0Q3X7093210@drugs.dv.isc.org> To: William Allen Simpson Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4A894CD9.7030307@gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-reply-to: Your message of "Mon, 17 Aug 2009 08:28:09 -0400." <4A894CD9.7030307@gmail.com> Date: Tue, 18 Aug 2009 10:26:03 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A894CD9.7030307@gmail.com>, William Allen Simpson writes: > I'm having trouble counting the number of actual likely bytes in > NXDOMAIN with DNSsec. It seems to me that the result will never > fit within 512 bytes? (Assuming SOA, NS, glue, etc.) I'm currently > getting 1022 bytes with SOA alone, but there's several RRSIGs. > > Testing: > > dig www.123.456.powerdnssecc.org @D0.ORG.AFILIAS-NST.org. +dnssec +all > > Are there simplifications that I'm missing? It all depend apon which DNSKEYS are in use and which NSEC/NSEC3 records that need to be returned. Yes it can fit in 512 bytes (see below) though it usually will exceed 512 bytes as in general you need two NSEC (or 3 NSEC3) records. Mark ; <<>> DiG 9.3.6-P1 <<>> *.isc.org +dnssec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43355 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;*.isc.org. IN A ;; AUTHORITY SECTION: isc.org. 3572 IN SOA ns-int.isc.org. hostmaster.isc.org. 2009081700 7200 3600 24796800 3600 isc.org. 3572 IN RRSIG SOA 5 2 43200 20090916175637 20090817175637 48684 isc.org. S2htTDPXDS2r2j/+Kkut0rpi10ENns944xPuv3oJZGtXXHKsdaiavV1Z FbcrXgxhlrvLmOgpnUR/NCu7EfJTE76QWKnQ0rU0/tGd+TnStKR5dLJK AFKmI++ejX5eyGV0cbH4/gq6TsVU8Dky+Xrp38DhTho0CqV8sU5AM37s nrI= isc.org. 3572 IN RRSIG NSEC 5 2 3600 20090916175637 20090817175637 48684 isc.org. LI6RNTUTmsM8PGyIPhOm9Gil3iqiQ2mEgi8DJhiOJ8V9Gafy3XXAUSZs j2uO6VmqQUsg+begGuSgvq8NLf/k0GUnCPgN6cnWEKlnYfdi7/I429Iq uvmGwvMi4L7i6sr+Lpdftp55NADqxAFPsLM9DX7vJ0jvNkrUYW3xWpTc z0U= isc.org. 3572 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY TYPE99 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Aug 18 10:19:34 2009 ;; MSG SIZE rcvd: 472 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 17 17:49: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 3DCBE3A68B9; Mon, 17 Aug 2009 17:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7CczaCIqSBC; Mon, 17 Aug 2009 17:49:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 938663A6D98; Mon, 17 Aug 2009 17:49:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdCpN-000BBk-21 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 00:45: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 1MdCpJ-000BBL-Lc for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 00:45: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 B039FE609B; Tue, 18 Aug 2009 00:45:24 +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 n7I0jKsD093566; Tue, 18 Aug 2009 10:45:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908180045.n7I0jKsD093566@drugs.dv.isc.org> To: Nicholas Weaver Cc: "W.C.A. Wijngaards" , George Barwood , namedroppers@ops.ietf.org From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <4A8934B5.7000106@nlnetlabs.nl> <0E5D0F8E-98D0-41FE-9F8B-E6C50DAE29C7@icsi.berkeley.edu> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Mon, 17 Aug 2009 06:30:37 MST." <0E5D0F8E-98D0-41FE-9F8B-E6C50DAE29C7@icsi.berkeley.edu> Date: Tue, 18 Aug 2009 10:45:20 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <0E5D0F8E-98D0-41FE-9F8B-E6C50DAE29C7@icsi.berkeley.edu>, Nicholas W eaver writes: > Yet if DNSSEC gets deployed, you will end up with a lot pushing that > 1500B limit, and serious breakage whenever it goes over. The Internet > IS broken for UDP fragments, its just everybody else doing UDP has > already implicitly understood this or does not do behavior which > tickles this. No. Border firwalls are broken. Fragmented IP cross the Internet quite fine. The packets get to the destination host/net. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 17 18:18: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 05D4F3A6ED7; Mon, 17 Aug 2009 18:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 TaPPFFBVQVTM; Mon, 17 Aug 2009 18:18:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 18E4928C1BB; Mon, 17 Aug 2009 18:18:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdDGP-000EfV-Rg for namedroppers-data0@psg.com; Tue, 18 Aug 2009 01:13:25 +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 1MdDGM-000Eeu-8u for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 01:13: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 06882E609C; Tue, 18 Aug 2009 01:13: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 n7I1D0hX093912; Tue, 18 Aug 2009 11:13:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908180113.n7I1D0hX093912@drugs.dv.isc.org> To: Alex Bligh Cc: Matthew Dempsky , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Mon, 17 Aug 2009 22:20:16 +0100." <4431D05BC3A4E329EF9EA39C@nimrod.local> Date: Tue, 18 Aug 2009 11:13:00 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4431D05BC3A4E329EF9EA39C@nimrod.local>, Alex Bligh writes: > > > --On 17 August 2009 13:48:07 -0700 Matthew Dempsky > wrote: > > > On Mon, Aug 17, 2009 at 12:08 PM, wrote: > >> For the _proxies_ our tests showed that most units did indeed just > >> blindly copy the OPT RR from stub to recursor, even if the proxy itself > >> was subsequently unable to reassemble the returned fragments. > > > > Are you implying that's desirable or undesirable behavior? I read > > your tone to imply it's undesirable, but it seems to be the behavior > > suggested by draft-ietf-dnsext-dnsproxy-06. > > I am not the author, but it seems to me that it is the combination > of forwarding the OPT RR saying EDNS0@4096 is supported AND dropping > the fragments which is bad. Para 4.4.3 of the above draft says: > > Therefore (irrespective of which of the methods above is in use) > proxies SHOULD be capable of forwarding UDP packets up to a payload > size of at least 4096 octets. > > "Proxying" the OPT RR and allowing the replies through, whilst yucky > and possibly (*) contrary to RFC2671 para 4.1 "OPT RRs shall never > be cached, forwarded, or stored in or loaded from master files.", > is far less dangerous. draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP size it is incapable of returning to the client. > (*)=this would depend what is meant by 'forwarded' - I presume > it means in the sense of an old DNS "forwarder", as opposed to > IP forwarding or some L4 proxy behaviour. > > -- > Alex Bligh > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 17 22:45: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 E967B3A68FB; Mon, 17 Aug 2009 22:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.247 X-Spam-Level: X-Spam-Status: No, score=-4.247 tagged_above=-999 required=5 tests=[AWL=-0.949, 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 9Sjbwqctwvru; Mon, 17 Aug 2009 22:45:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6D4B3A68BF; Mon, 17 Aug 2009 22:45:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdHSa-000IoE-Ll for namedroppers-data0@psg.com; Tue, 18 Aug 2009 05:42:16 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdHSS-000Imf-9o for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 05:42: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=fCIS5dif1cKwbTsivnK/beZvcKrXa4b2fg55MOgy294Xe8iHyouR2ZCE TWWM7eVDOV0Cvok3f3bOVn0d6GclT9nxxmNacgDKPZ8THewHIAf2gbFJk SBcbh+mDJb20MzT; 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=1250574128; x=1282110128; 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]=20EDNS=20Page=20Option=20draft|Date:=20Tue,=2018=20Au g=202009=2007:41:51=20+0200|Message-ID:=20|To:=20Mark=20Andrews=20|Cc:=20Alex=20Bl igh=20,=0D=0A=09marka@isc.org,=0D=0A=09 Matthew=20Dempsky=20,=0D=0A=09namedr oppers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<2 00908180113.n7I1D0hX093912@drugs.dv.isc.org>|References: =20<5722A99A87EA478BAC81D71ED194B500@localhost>=20<4A8916 FA.8050302@nlnetlabs.nl>=20<06A65CB0596049F7A085A8C454948 23F@localhost>=20<1931B8FB0122AC8BDEF52618@Ximines.local> =20<2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.ed u>=20=20=20=20<4431D05BC3A4E329EF9EA39C@nimrod.local> =20<200908180113.n7I1D0hX093912@drugs.dv.isc.org>; bh=mvbsl8uzbVqYbusdGV/z3gFpS1SpXvGPnsXQ6/U4cMo=; b=C1R24IrRl3V6IJAQApWkzrmRyKyo4/+uZyzfykl4ysZL6x7jjNiMJ/+v CbDUR0/iSI+USycz6C/rv51ye6gsQjqUI0KFkz4meGF2zrRb6i7jRY5xP uONXMnMBGFLSSQM; X-IronPort-AV: E=Sophos;i="4.43,401,1246834800"; d="scan'208";a="16787251" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Aug 2009 06:42:00 +0100 In-Reply-To: <200908180113.n7I1D0hX093912@drugs.dv.isc.org> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> To: Mark Andrews Cc: Alex Bligh , marka@isc.org, Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 18 Aug 2009 07:41:51 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/08/2009 06:42:06 AM, Serialize complete at 18/08/2009 06:42:06 AM Content-Type: multipart/alternative; boundary="=_alternative 001F4BFDC1257616_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 001F4BFDC1257616_= Content-Type: text/plain; charset="US-ASCII" > draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP > size it is incapable of returning to the client. Well, not really. It already points out that it behoves the client to set their own EDNS0 buffer size in accordance with their MTU, with the implication that the client should also take the proxy's "buffer MTU" into account. Ray --=_alternative 001F4BFDC1257616_= Content-Type: text/html; charset="US-ASCII"
> draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP
> size it is incapable of returning to the client.
Well, not really.  It already points out that it behoves the client to set their own EDNS0 buffer size in accordance with their MTU, with the implication that the client should also take the proxy's "buffer MTU" into account.

Ray
--=_alternative 001F4BFDC1257616_=-- From owner-namedroppers@ops.ietf.org Mon Aug 17 22:45: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 5FDF33A68FB; Mon, 17 Aug 2009 22:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 9-DZ1O2I0Bf4; Mon, 17 Aug 2009 22:45:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 562333A68BF; Mon, 17 Aug 2009 22:45:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdHOg-000IOH-Io for namedroppers-data0@psg.com; Tue, 18 Aug 2009 05:38:14 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdHOb-000IMS-Ju for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 05:38:11 +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=nacZTG1pBlcMmQZ63OeGi59sc2Imup7Mm3L5m2KiTBmQm/CCEE5vzPog U4XteNNX7xLzMdUjCaZMdNMykNEFf3ZFlHipWEP8zV1niWAC2Wpb3qeLc l11ZbJChkNQwc4H; 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=1250573889; x=1282109889; 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]=20EDNS=20Page=20Option=20draft|Date:=20Tue,=2018=20Au g=202009=2007:37:55=20+0200|Message-ID:=20|To:=20Alex=20Bligh=20|Cc:=20Matthew =20Dempsky=20,=0D=0A=09namedroppers@ ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<4431D05B C3A4E329EF9EA39C@nimrod.local>|References:=20<5722A99A87E A478BAC81D71ED194B500@localhost>=09=20<4A8916FA.8050302@n lnetlabs.nl>=0D=0A=09=20<06A65CB0596049F7A085A8C45494823F @localhost>=09=20<1931B8FB0122AC8BDEF52618@Ximines.local> =0D=0A=09=20<2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.be rkeley.edu>=09=20 =0D=0A=09=20=20=20<4431D05BC3A4E329E F9EA39C@nimrod.local>; bh=Yx5hTFnHz7kYvLhaB2U7yQTgGlgLQcEWgRP6JmnK1do=; b=GjwkafB8o+K9NVPpZCMUJEz7UJ19UV9b7g7hYhMvN4IxrGPhztTrNIj0 HZl2Q6s7LygsUuOoMtC4Jty9HfBxCUTFPbXI6JCcu2r6g0HcRC2nt5wFV 0+tw8dneqz8+lMa; X-IronPort-AV: E=Sophos;i="4.43,401,1246834800"; d="scan'208";a="16787218" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Aug 2009 06:38:02 +0100 In-Reply-To: <4431D05BC3A4E329EF9EA39C@nimrod.local> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> To: Alex Bligh Cc: Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 18 Aug 2009 07:37:55 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/08/2009 06:38:05 AM, Serialize complete at 18/08/2009 06:38:05 AM Content-Type: multipart/alternative; boundary="=_alternative 001EEFC0C1257616_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 001EEFC0C1257616_= Content-Type: text/plain; charset="US-ASCII" > I am not the author, but it seems to me that it is the combination > of forwarding the OPT RR saying EDNS0@4096 is supported AND dropping > the fragments which is bad. Para 4.4.3 of the above draft says: > > Therefore (irrespective of which of the methods above is in use) > proxies SHOULD be capable of forwarding UDP packets up to a payload > size of at least 4096 octets. > > "Proxying" the OPT RR and allowing the replies through, whilst yucky > and possibly (*) contrary to RFC2671 para 4.1 "OPT RRs shall never > be cached, forwarded, or stored in or loaded from master files.", > is far less dangerous. See also Section 3 ("Transparency Principle") [added emphasis] "The role of the proxy should therefore be no more and no less than to receive DNS requests from clients on the LAN side, forward those verbatim to one of the known upstream recursive resolvers on the WAN side, and ensure that the *whole response* is returned verbatim to the original client. It is RECOMMENDED that proxies should be as transparent as possible, such that any "hop-by-hop" mechanisms or newly introduced protocol extensions operate as if the proxy were not there." In other words, a proxy can blindly copy request packets if it wants, but if it does it had better damned well ensure that it blindly copies the whole response too. Ray --=_alternative 001EEFC0C1257616_= Content-Type: text/html; charset="US-ASCII"
> I am not the author, but it seems to me that it is the combination
> of forwarding the OPT RR saying EDNS0@4096 is supported AND dropping
> the fragments which is bad. Para 4.4.3 of the above draft says:
>
>    Therefore (irrespective of which of the methods above is in use)
>    proxies SHOULD be capable of forwarding UDP packets up to a payload
>    size of at least 4096 octets.
>
> "Proxying" the OPT RR and allowing the replies through, whilst yucky
> and possibly (*) contrary to RFC2671 para 4.1 "OPT RRs shall never
> be cached, forwarded, or stored in or loaded from master files.",
> is far less dangerous.
See also Section 3 ("Transparency Principle") [added emphasis]

"The role of the proxy should therefore be no more and no less than to
receive DNS requests from clients on the LAN side, forward those
verbatim to one of the known upstream recursive resolvers on the WAN
side, and ensure that the *whole response* is returned verbatim to the
original client.

It is RECOMMENDED that proxies should be as transparent as possible,
such that any "hop-by-hop" mechanisms or newly introduced protocol
extensions operate as if the proxy were not there."

In other words, a proxy can blindly copy request packets if it wants, but if it does it had better damned well ensure that it blindly copies the whole response too.

Ray



--=_alternative 001EEFC0C1257616_=-- From owner-namedroppers@ops.ietf.org Tue Aug 18 00: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 84AA43A6A90; Tue, 18 Aug 2009 00:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 m5mGyc1J8OJT; Tue, 18 Aug 2009 00:10:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BE3D3A6914; Tue, 18 Aug 2009 00:10:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdIkv-0003Kl-8w for namedroppers-data0@psg.com; Tue, 18 Aug 2009 07:05: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 1MdIkq-0003Jz-Hi for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 07:05: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 43863E609B; Tue, 18 Aug 2009 07:05:11 +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 n7I74nQ7043296; Tue, 18 Aug 2009 17:04:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908180704.n7I74nQ7043296@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Alex Bligh , Matthew Dempsky , namedroppers@ops.ietf.org From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Tue, 18 Aug 2009 07:41:51 +0200." Date: Tue, 18 Aug 2009 17:04:49 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Ray.Bellis@nominet.org.uk writes: > This is a multipart message in MIME format. > --=_alternative 001F4BFDC1257616_= > Content-Type: text/plain; charset="US-ASCII" > > > draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP > > size it is incapable of returning to the client. > > Well, not really. It already points out that it behoves the client to set > their own EDNS0 buffer size in accordance with their MTU, with the > implication that the client should also take the proxy's "buffer MTU" into > account. The client has no way to know the DNS proxy's buffer sizes and it is unreasonable for us to expect the client to discover this especially when the DNS proxy is advertising itself in the DHCP offer as a recursive nameserver. The DNS proxy MUST adjust the EDNS buffer size to reflect it's own buffers. It MUST NOT just copy the request/response without doing so. If the DNS proxy want to do this in a minimal manner it will use the minimum of the recieved EDNS UDP size and its own buffer sizes. This will allow the reply to be passed through without having to completely rewrite it in the event that the client's EDNS UDP size is smaller than the DNS proxy's buffer size. It will also allow clients that are attempting to discover what size request they can send over UDP to work as the effective MTU of the outgoing path will be recorded in the response the client sees. A DNS proxy that tells the recursive server that it can accept EDNS responses that are ethernet sized is infinitely better that a DNS proxy that lies to the recursive server by copying the 4096 EDNS size the client sent. Mark > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 01:12: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 8FCC23A6D9A; Tue, 18 Aug 2009 01:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2GaZhOSoZ7C; Tue, 18 Aug 2009 01:12:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADAFB3A67E7; Tue, 18 Aug 2009 01:12:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdJie-000BLY-GW for namedroppers-data0@psg.com; Tue, 18 Aug 2009 08:07:00 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdJia-000BKo-Ng for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 08:06:58 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 69A74C2DA5; Tue, 18 Aug 2009 09:06:53 +0100 (BST) Date: Tue, 18 Aug 2009 09:04:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews , Ray.Bellis@nominet.org.uk cc: Matthew Dempsky , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft Message-ID: <355DA3C50423C35B84DD1052@Ximines.local> In-Reply-To: <200908180704.n7I74nQ7043296@drugs.dv.isc.org> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> <200908180704.n7I74nQ7043296@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 18 August 2009 17:04:49 +1000 Mark Andrews wrote: > The DNS proxy MUST adjust the EDNS buffer size to reflect it's own > buffers. I'm not sure that is right. Better alternatives would include acting as (say) a caching resolver rather than proxying at all. Isn't it the other way around, i.e. that it must not pass through OPT RRs indicating support for an EDNS0 buffer size which it then will not support? Note that the proxy may not be able to adjust its EDNS buffer size without relying on fragmentation working upstream as it may not know what the upstream MTU is (e.g. it may pass over a segment with smaller MTU than ethernet MTU). > It MUST NOT just copy the request/response without doing > so. There was a long discussion about MUST/SHOULD status of things in this draft; precatory words were favoured over language of obligation in many places where doing the opposite resulted in "bad things happening" (I can't remember the other examples off the top of my head). As I understand the argument, it was that encouraging vendors to conform was better than whipping them for not doing so, resulting in them ignoring the whole draft, particularly as some of the behaviours were already proscribed by other RFCs. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 18 01:29: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 A251B3A686C; Tue, 18 Aug 2009 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=-0.647, 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 bbwQ77HeMf5m; Tue, 18 Aug 2009 01:29:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE1A43A63D3; Tue, 18 Aug 2009 01:29:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdK14-000DdQ-MU for namedroppers-data0@psg.com; Tue, 18 Aug 2009 08:26:02 +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 1MdK0z-000DbE-SN for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 08:26: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 1MdK0p-0002Jr-4j; Tue, 18 Aug 2009 10:25:47 +0200 Received: by bfk.de with local id 1MdK0o-00084S-V9; Tue, 18 Aug 2009 08:25:46 +0000 To: Mark Andrews Cc: Ray.Bellis@nominet.org.uk, Alex Bligh , Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> <200908180704.n7I74nQ7043296@drugs.dv.isc.org> From: Florian Weimer Date: Tue, 18 Aug 2009 08:25:46 +0000 In-Reply-To: <200908180704.n7I74nQ7043296@drugs.dv.isc.org> (Mark Andrews's message of "Tue\, 18 Aug 2009 17\:04\:49 +1000") Message-ID: <82zl9x34vp.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Mark Andrews: > The DNS proxy MUST adjust the EDNS buffer size to reflect it's own > buffers. It MUST NOT just copy the request/response without doing > so. Ahem, it's much easier to just use a 64K buffer. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Tue Aug 18 01:41: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 C426F3A691E; Tue, 18 Aug 2009 01:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 nxhRXBz8h9Y7; Tue, 18 Aug 2009 01:41:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53B223A6AAE; Tue, 18 Aug 2009 01:41:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdKCR-000FMp-TJ for namedroppers-data0@psg.com; Tue, 18 Aug 2009 08:37: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 1MdKCM-000FLr-Sy for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 08:37: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 A3383E609C; Tue, 18 Aug 2009 08:37:41 +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 n7I8bdIJ093559; Tue, 18 Aug 2009 18:37:39 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908180837.n7I8bdIJ093559@drugs.dv.isc.org> To: Alex Bligh Cc: Ray.Bellis@nominet.org.uk, Matthew Dempsky , namedroppers@ops.ietf.org From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> <200908180704.n7I74nQ7043296@drugs.dv.isc.org> <355DA3C50423C35B84DD1052@Ximines.local> Subject: Re: [dnsext] EDNS Page Option draft In-reply-to: Your message of "Tue, 18 Aug 2009 09:04:34 +0100." <355DA3C50423C35B84DD1052@Ximines.local> Date: Tue, 18 Aug 2009 18:37:39 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <355DA3C50423C35B84DD1052@Ximines.local>, Alex Bligh writes: > > The DNS proxy MUST adjust the EDNS buffer size to reflect it's own > > buffers. > > I'm not sure that is right. Better alternatives would include > acting as (say) a caching resolver rather than proxying at all. > Isn't it the other way around, i.e. that it must not pass through > OPT RRs indicating support for an EDNS0 buffer size which it > then will not support? > > Note that the proxy may not be able to adjust its EDNS buffer > size without relying on fragmentation working upstream > as it may not know what the upstream MTU is (e.g. it > may pass over a segment with smaller MTU than ethernet MTU). That should not be a problem as these boxes are capable of correctly NATing UDP bigger that physical MTU. They either reassemble today to do this or hold out of order fragments until the initial fragment arrives then track the fragment. In either case they can still adjust the EDNS UDP size as the packet transits them. > > It MUST NOT just copy the request/response without doing > > so. > > There was a long discussion about MUST/SHOULD status of > things in this draft; precatory words were favoured over > language of obligation in many places where doing the > opposite resulted in "bad things happening" (I can't > remember the other examples off the top of my head). > As I understand the argument, it was that encouraging > vendors to conform was better than whipping them for > not doing so, resulting in them ignoring the whole > draft, particularly as some of the behaviours were > already proscribed by other RFCs. > > -- > Alex Bligh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 03:50: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 A166A3A6B58; Tue, 18 Aug 2009 03:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 eeDOlZe8Hedx; Tue, 18 Aug 2009 03:50:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E29BE3A680E; Tue, 18 Aug 2009 03:50:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdMAx-0006aP-45 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 10:44:23 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdMAr-0006Zm-N1 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 10:44:20 +0000 Received: by ewy11 with SMTP id 11so4352909ewy.11 for ; Tue, 18 Aug 2009 03:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xmhSpdLDkOnNgsxs0MYSWLC4qwZ3I1M282P8qWNgqWw=; b=Px78MAGBWlZO7GZs3/sE1qevZgIxFAeAKb5HcsweDod6l9Aiqd5QErigOPSSSlQ/NJ HWK+lIhudHCivUtB3vYsNpQMJm9REfhQqP94/txLERcgQJp5OdaAA4b93fZhJKvke2Tk K/Tli5GP7oXLWdm4sliRoDUa93yAyOVlU0Ocw= 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=Sofc1CHYO7vetz1ZgMIScOd4YkfHwqRm0wmVQyJuDEDqkzQTCQc1GPGS5Tokb/NWPD 7OMGaTZDjxdR1KRNTrBXu8xOsq2XLvQqBR9VmFb2JKUreB4yx8Q4NN1dYNv+w3wWOUyi t7QfJcsU5XGPP7Ua3jXmM0HHWme4EBi83PDTI= MIME-Version: 1.0 Received: by 10.210.70.18 with SMTP id s18mr2266365eba.45.1250592256113; Tue, 18 Aug 2009 03:44:16 -0700 (PDT) In-Reply-To: <4A894CD9.7030307@gmail.com> References: <4A894CD9.7030307@gmail.com> From: bert hubert Date: Tue, 18 Aug 2009 12:43:56 +0200 Message-ID: <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response To: William Allen Simpson Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 17, 2009 at 2:28 PM, William Allen Simpson wrote: > I'm having trouble counting the number of actual likely bytes in > NXDOMAIN with DNSsec. =A0It seems to me that the result will never > fit within 512 bytes? =A0(Assuming SOA, NS, glue, etc.) =A0I'm currently > getting 1022 bytes with SOA alone, but there's several RRSIGs. This is the sad NSEC3 truth, even with 1024 bit keys, SHA-1 DS and SHA-1 signatures. There are 3 NSEC3's needed mostly, and they all have an RRSIG. And they are not getting any smaller. Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 04:40: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 B4EE03A6892; Tue, 18 Aug 2009 04:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.175 X-Spam-Level: X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[AWL=-0.575, 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 velTpPgjw9+T; Tue, 18 Aug 2009 04:40:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E8673A676A; Tue, 18 Aug 2009 04:40:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdMyX-000DPv-Oi for namedroppers-data0@psg.com; Tue, 18 Aug 2009 11:35: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 1MdMyS-000DNR-6W for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 11:35:34 +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 1MdMyO-0002ff-O2; Tue, 18 Aug 2009 13:35:28 +0200 Received: by bfk.de with local id 1MdMyO-000591-Jc; Tue, 18 Aug 2009 11:35:28 +0000 To: William Allen Simpson Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response References: <4A894CD9.7030307@gmail.com> From: Florian Weimer Date: Tue, 18 Aug 2009 11:35:28 +0000 In-Reply-To: <4A894CD9.7030307@gmail.com> (William Allen Simpson's message of "Mon\, 17 Aug 2009 08\:28\:09 -0400") Message-ID: <824os5tkvz.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * William Allen Simpson: > I'm having trouble counting the number of actual likely bytes in > NXDOMAIN with DNSsec. It seems to me that the result will never > fit within 512 bytes? 512 bytes seems to be possible to reach with online signing only, unfortunately. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Tue Aug 18 05:39: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 2E1E43A6AE9; Tue, 18 Aug 2009 05:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.153, 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 d5oSWILdLGjb; Tue, 18 Aug 2009 05:39:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9869B3A6A43; Tue, 18 Aug 2009 05:39:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdNsX-000MOQ-L4 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 12:33:29 +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 1MdNsQ-000MNO-CL for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 12:33:26 +0000 Received: by yxe15 with SMTP id 15so4865956yxe.5 for ; Tue, 18 Aug 2009 05:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OospkfE6NHQP7xHBweGnLi4vT9fnXa8pkncZVBa+X9g=; b=eafwahVQk8tJ8Wap1icuiHCDnYT88zbqvJy1frGkXvfi936CMjHHiaA0r+mL9C5OTP X2sh4YQDf5vrhWRLPEHLrPLj9lbIPPpjTMc+boNfgsz2e8CmgwhwW5tKTEu83Mc8w40V qTzmza9SuAVyAtnyidUwP/T9dDaTLiT5XsGJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=SYdcw17jJ/rkYvdFeF4nyTg1/P7tJYCcCN3WzX5UXFYpLSSaUkMPBQ7zaUJ0w4grFm 2WuevGbcaViQNYIHKKON05YckViXPOsOJyoaIZCfKBm9O6IF4xalBXeT4xuLh8V771By EMr4NrzjF81KUVoM4bF83SVMd9q2Bby7CG4TQ= Received: by 10.90.11.30 with SMTP id 30mr3771850agk.42.1250598799856; Tue, 18 Aug 2009 05:33:19 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 26sm56258aga.64.2009.08.18.05.33.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 05:33:18 -0700 (PDT) Message-ID: <4A8A9F8D.4030009@gmail.com> Date: Tue, 18 Aug 2009 08:33:17 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> In-Reply-To: <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: bert hubert wrote: > On Mon, Aug 17, 2009 at 2:28 PM, William Allen > Simpson wrote: >> I'm having trouble counting the number of actual likely bytes in >> NXDOMAIN with DNSsec. It seems to me that the result will never >> fit within 512 bytes? (Assuming SOA, NS, glue, etc.) I'm currently >> getting 1022 bytes with SOA alone, but there's several RRSIGs. > > This is the sad NSEC3 truth, even with 1024 bit keys, SHA-1 DS and > SHA-1 signatures. There are 3 NSEC3's needed mostly, and they all have > an RRSIG. And they are not getting any smaller. > OK. I'm especially concerned for NXDOMAIN, as the last measurements I've seen say they're likely a minimum of 12% of the queries. Add key rollover to larger signatures (2 sets of RRSIGs), and we're always looking at more than 1024 bytes, maybe more than 1400 bytes. Anybody have exact data? From owner-namedroppers@ops.ietf.org Tue Aug 18 06:25: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 6D8F63A69D1; Tue, 18 Aug 2009 06:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 a7dMHRoYluyF; Tue, 18 Aug 2009 06:25:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A14913A689B; Tue, 18 Aug 2009 06:25:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdOc4-0003m1-9Z for namedroppers-data0@psg.com; Tue, 18 Aug 2009 13:20:32 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdObv-0003hK-GV for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 13:20:26 +0000 Received: by ewy11 with SMTP id 11so4460435ewy.11 for ; Tue, 18 Aug 2009 06:20:21 -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=rE0vGS4VTBaHJ+ZWE0CCGRxEOs1CoKLP12DTouNmNGg=; b=WPGvj0gXX5tZEjg3VYop2OreESA3L1yLBosEl3sNJFY9n+LH0Sob/gWmLmQM9vFUe6 U38mZt88D9CI1pTxaaS0BMkO81VNrb3vKpX+0tofp68bVeZ+yFmePTd4tqm9NWC3BrZm F8oBv4xoeZX8c9jI3w6dDL88/ZbBnI9qU4QN4= 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=RQxB1zKvEnAmbwLAvfWVNvNMKvpwairG65AQqaZLb0W3CDxWq20gGlk0ghl6nB9ZBJ clShyaA28rKfRqBacK6I3MpII+2C16oB0NWy6EOeOvckr1Ym3q0A2iOTXgYnFrsDufJS zYjlwIvTPNuhCsax5XAZKB5ICRbjIfGWG7klg= MIME-Version: 1.0 Received: by 10.210.33.17 with SMTP id g17mr4504297ebg.79.1250601621145; Tue, 18 Aug 2009 06:20:21 -0700 (PDT) In-Reply-To: <824os5tkvz.fsf@mid.bfk.de> References: <4A894CD9.7030307@gmail.com> <824os5tkvz.fsf@mid.bfk.de> From: bert hubert Date: Tue, 18 Aug 2009 15:20:01 +0200 Message-ID: <3efd34cc0908180620o30640e77tbb81f5069028eee0@mail.gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response To: Florian Weimer Cc: William Allen Simpson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 1:35 PM, Florian Weimer wrote: >> I'm having trouble counting the number of actual likely bytes in >> NXDOMAIN with DNSsec. =A0It seems to me that the result will never >> fit within 512 bytes? > > 512 bytes seems to be possible to reach with online signing only, > unfortunately. Or, perhaps, using 32 byte ECC-based signatures. Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 07:59: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 F403C3A6ADF; Tue, 18 Aug 2009 07:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 PJalRiwN9kfW; Tue, 18 Aug 2009 07:59:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C18493A6A61; Tue, 18 Aug 2009 07:59:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdQ3T-000L29-M5 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 14:52: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 1MdQ3O-000L1T-SM for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 14:52: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 C3543E609B; Tue, 18 Aug 2009 14:52:49 +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 n7IEqTZ5098762; Wed, 19 Aug 2009 00:52:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> To: William Allen Simpson Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-reply-to: Your message of "Tue, 18 Aug 2009 08:33:17 -0400." <4A8A9F8D.4030009@gmail.com> Date: Wed, 19 Aug 2009 00:52:29 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A8A9F8D.4030009@gmail.com>, William Allen Simpson writes: > bert hubert wrote: > > On Mon, Aug 17, 2009 at 2:28 PM, William Allen > > Simpson wrote: > >> I'm having trouble counting the number of actual likely bytes in > >> NXDOMAIN with DNSsec. It seems to me that the result will never > >> fit within 512 bytes? (Assuming SOA, NS, glue, etc.) I'm currently > >> getting 1022 bytes with SOA alone, but there's several RRSIGs. > > > > This is the sad NSEC3 truth, even with 1024 bit keys, SHA-1 DS and > > SHA-1 signatures. There are 3 NSEC3's needed mostly, and they all have > > an RRSIG. And they are not getting any smaller. > > > OK. I'm especially concerned for NXDOMAIN, as the last measurements I've > seen say they're likely a minimum of 12% of the queries. > > Add key rollover to larger signatures (2 sets of RRSIGs), and we're always > looking at more than 1024 bytes, maybe more than 1400 bytes. Anybody have > exact data? You need to learn how to manage keys so there isn't two sets of signatures. The DNSKEY response will have multiple signature but the rest of the responses don't need them. Basically you add a new DNSKEY to the DNSKEY RRset before you start signing with it. Wait until the on DNSKEY RRset has timed out of caches. You then stop signing changes with the old key and start signing changes with the new key. Once all the data signed with the old DNSKEY has timed out of caches you can remove the old DNSKEY. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 08:41: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 558643A6999; Tue, 18 Aug 2009 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.087 X-Spam-Level: X-Spam-Status: No, score=-5.087 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 tWUXvdMVUsiZ; Tue, 18 Aug 2009 08:41:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FDC13A6B4F; Tue, 18 Aug 2009 08:41:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdQkH-00015d-D8 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 15:37:09 +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 1MdQkA-00013u-7a for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 15:37: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 n7IFai9G027749; Tue, 18 Aug 2009 08:37:01 -0700 (PDT) Message-Id: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> From: Nicholas Weaver To: "namedroppers@ops.ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] What ELSE relies on UDP fragmentation? Date: Tue, 18 Aug 2009 08:37:01 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Can anyone identify a major application other than DNSSEC which uses UDP and assumes that packets greater than the Ethernet MTU can be sent and will be properly fragmented and reassembled on traffic traversing the Internet? From owner-namedroppers@ops.ietf.org Tue Aug 18 08:41: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 ECE383A6AEC; Tue, 18 Aug 2009 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 4Nvlo7wKZORt; Tue, 18 Aug 2009 08:41:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 801953A6999; Tue, 18 Aug 2009 08:41:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdQkN-000175-KM for namedroppers-data0@psg.com; Tue, 18 Aug 2009 15:37:15 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdQkK-00015i-Dp for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 15:37:14 +0000 Received: by ewy11 with SMTP id 11so4574091ewy.11 for ; Tue, 18 Aug 2009 08:37: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=4jvlyJH2Etn0SIuHHSn3i5hw9fFjZ+rtFBY7kGkFS8s=; b=yCF+rlUqoTHBJLYdh9DDV9NyX/kJFPRdXvxTNN+vAL1fa17eB0FIRg4g9xs2Yd49mz oyElGy/s91TYu+vNV8Ex0JZJDCoCeXIkwKTCjYAiy5PPTbaHGcZL6Mmo6un8Zu2AsEff DXlr4cvuGlzOB1bf2F2PFSEWFZRD1S8p8tioA= 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=fyayzoeH7jQRx9SA4HEEQTkeFvQJ4zNQVTxwJmwbcsPllUxKCpRZMOG8s0E9af29DS Gvgh8ZScRneiWnTT9sRUfy5tF9wpdgOqWtveo08Rqg3TgVmGc/rq7oY0oFMQEO/gpWQR l54N7oVIo8Aq/P2tKgw4+ZoLkHhKjPf65BH0c= MIME-Version: 1.0 Received: by 10.210.61.8 with SMTP id j8mr486802eba.34.1250609831092; Tue, 18 Aug 2009 08:37:11 -0700 (PDT) In-Reply-To: <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> From: bert hubert Date: Tue, 18 Aug 2009 17:36:51 +0200 Message-ID: <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response To: Mark Andrews Cc: William Allen Simpson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 4:52 PM, Mark Andrews wrote: > You need to learn how to manage keys so there isn't two sets of > signatures. =A0The DNSKEY response will have multiple signature but > the rest of the responses don't need them. The DNSKEY DO=3D1 query still needs to happen though. And it is 'the hugene= ss'. It might be feasible to do two queries, DNSKEY DO=3D0 and RRSIG DO=3D1. Could save some bytes. But in general, without fragmentation working reliably or allowing ('blessing') TCP, there is a problem. Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 09:16: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 8F81C3A68C2; Tue, 18 Aug 2009 09:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 Or3Rh5vzrDgC; Tue, 18 Aug 2009 09:16:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDA2D3A6B9E; Tue, 18 Aug 2009 09:16:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRIN-00061S-Ia for namedroppers-data0@psg.com; Tue, 18 Aug 2009 16:12:23 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRIK-000612-3A for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 16:12:21 +0000 Received: by ewy11 with SMTP id 11so4602666ewy.11 for ; Tue, 18 Aug 2009 09:12:18 -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=6ktKfA3dMic6v3goOyeTmY4Gfsj49eI2kLvIet4MsKM=; b=tDRBT9SOzAdJUetpJc/VftWSr/dNtWDnexMt+yRA7mA47tCMFrN/Mt+74loeTkVrUM EyxJSPGnPh1lfDTK4FDXR/xMa/gI1qht0v2hEGSQdV/znBwbT5HtmhmEspKDff5gKSQ+ Fi74eidR5SuskMQiiq8NqXZciOP3QQXLl3Zb0= 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=stVUmyMJff2RZpVNCgIZ+3RC2CTS0rqS9tr+RyvvCZnBjKk5vCjKhmnBXibQcul+1V ubpKukxUKQ9aKKXifcTnYdeAMcVVmYHYZgo2TraW3HX+EjBjoYZvNMwTac/aZ9KQwmXJ U4U+Zg0w21TQyfxTUI5mv0WLQ4Edd+ZxO1huU= MIME-Version: 1.0 Received: by 10.210.33.17 with SMTP id g17mr4702246ebg.79.1250611938153; Tue, 18 Aug 2009 09:12:18 -0700 (PDT) In-Reply-To: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> From: bert hubert Date: Tue, 18 Aug 2009 18:11:58 +0200 Message-ID: <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? To: Nicholas Weaver , "namedroppers@ops.ietf.org 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 5:37 PM, Nicholas Weaver wrote: > Can anyone identify a major application other than DNSSEC which uses UDP and > assumes that packets greater than the Ethernet MTU can be sent and will be > properly fragmented and reassembled on traffic traversing the Internet? "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Nothing else relies on fragmented UDP working as far as I know. OpenVPN for example has no less than 7 configuration options to prevent fragmentation, or to deal with it not working. Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 09:26: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 A18C428C18F; Tue, 18 Aug 2009 09:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 STsc2OFj9bn0; Tue, 18 Aug 2009 09:26:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93D5028C213; Tue, 18 Aug 2009 09:26:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRSt-0007QW-Ap for namedroppers-data0@psg.com; Tue, 18 Aug 2009 16:23:15 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRSo-0007Pi-PP for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 16:23:12 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id F27FA5656D; Tue, 18 Aug 2009 12:23:09 -0400 (EDT) Date: Tue, 18 Aug 2009 12:23:09 -0400 (EDT) From: Paul Wouters To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-Reply-To: <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> Message-ID: References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, 18 Aug 2009, bert hubert wrote: > The DNSKEY DO=1 query still needs to happen though. And it is 'the hugeness'. > It might be feasible to do two queries, DNSKEY DO=0 and RRSIG DO=1. > Could save some bytes. That sounds horrible. Where do you put the DNSKEY while doing the RRSIG? It can't go into the cache yet.... > But in general, without fragmentation working reliably or allowing > ('blessing') TCP, there is a problem. Yeah, people just will have to update their cisco firewall policies :P Paul From owner-namedroppers@ops.ietf.org Tue Aug 18 09:30: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 D93213A6974; Tue, 18 Aug 2009 09:30:42 -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 eTwSNa2DHoFx; Tue, 18 Aug 2009 09:30:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFCA428C242; Tue, 18 Aug 2009 09:30:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRXh-000847-RL for namedroppers-data0@psg.com; Tue, 18 Aug 2009 16:28:13 +0000 Received: from [74.125.78.26] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRXd-00083g-G7 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 16:28:11 +0000 Received: by ey-out-2122.google.com with SMTP id 9so786874eyd.65 for ; Tue, 18 Aug 2009 09:28:07 -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=ZT18iFOP565mZwJVPgiqceoq2eM0zoEKHoS9dh2jaeI=; b=B1bqLuU3SHzlyTWmm7kQkb1S5XjceveUanV+cN+HK3GFxJtR+zV80HdMOpaPAN8Uij FFpMhqUzRuIlmVohUpeXYYSl0DU85PvoCK9i0CtFTa+G8hYvsLB2YPDeXfN7jqpw2dUF oJv8TjOwsxF/qa/+HbneGp223yBgPtkUVjhKY= 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=RzqdRgdEzq3M9p8hbQRW1uw2orQY2HNIo7eytYUTrNhk1gHLULl4bbWU/Km4BanOYD RIfLQuP/cQYmKcWThXO4URiNY6zskv2OXDEDUJ7phWxJeJrywTF/LvH+mufouk5q2GMy zFg8JxSG9p+LhuK1CumwRV9OFVzVK4jCr7qfk= MIME-Version: 1.0 Received: by 10.210.80.17 with SMTP id d17mr4690549ebb.67.1250612887174; Tue, 18 Aug 2009 09:28:07 -0700 (PDT) In-Reply-To: References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> From: bert hubert Date: Tue, 18 Aug 2009 18:27:47 +0200 Message-ID: <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response To: Paul Wouters 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 6:23 PM, Paul Wouters wrote: >> It might be feasible to do two queries, DNSKEY DO=0 and RRSIG DO=1. >> Could save some bytes. > > That sounds horrible. Where do you put the DNSKEY while doing the RRSIG? > It can't go into the cache yet.... I suggest the stack. >> But in general, without fragmentation working reliably or allowing >> ('blessing') TCP, there is a problem. > > Yeah, people just will have to update their cisco firewall policies :P In general, people will change zilch for DNSSEC (or worse, they can't change it). It is up to the DNSSEC community to become deployable, and not to ask the internet to become suitable for DNSSEC deployment. Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 09:53: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 8958028C2E2; Tue, 18 Aug 2009 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.080, 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 RGHbUhKslt7Q; Tue, 18 Aug 2009 09:53:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFC4028C28E; Tue, 18 Aug 2009 09:53:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRsV-000BRn-Ef for namedroppers-data0@psg.com; Tue, 18 Aug 2009 16:49:43 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdRsQ-000BRO-SS for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 16:49:40 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 53B97C2DA5; Tue, 18 Aug 2009 17:49:37 +0100 (BST) Date: Tue, 18 Aug 2009 17:47:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver , "namedroppers@ops.ietf.org WG" cc: Nicholas Weaver , Alex Bligh Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: <36162FA2FEEC591D89DD9585@Ximines.local> In-Reply-To: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 18 August 2009 08:37:01 -0700 Nicholas Weaver wrote: > Can anyone identify a major application other than DNSSEC which uses UDP > and assumes that packets greater than the Ethernet MTU can be sent and > will be properly fragmented and reassembled on traffic traversing the > Internet? NFS (at least v2) @rsize=4096,wsize=4096. Somehow I doubt this is a major application though ... -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 18 10:12: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 D054E28C1F8; Tue, 18 Aug 2009 10:12:07 -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 IYy84MK5+epN; Tue, 18 Aug 2009 10:12:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC16828C319; Tue, 18 Aug 2009 10:12:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdSAx-000E80-GK for namedroppers-data0@psg.com; Tue, 18 Aug 2009 17:08: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 1MdSAu-000E7N-61 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 17:08:45 +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 AEF902FE8ED5 for ; Tue, 18 Aug 2009 17:08:40 +0000 (UTC) Date: Tue, 18 Aug 2009 13:08:38 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: <20090818170837.GJ3163@shinkuro.com> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <36162FA2FEEC591D89DD9585@Ximines.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36162FA2FEEC591D89DD9585@Ximines.local> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Tue, Aug 18, 2009 at 05:47:17PM +0100, Alex Bligh wrote: > Somehow I doubt this is a major application though ... I'm a little uncomfortable with the trend in this thread of trying to discern the "major" applications as opposed to the "minor" ones, on whom one gets to impose damage. I suggest it's hard to make the major/minor distinction in any clear way, and I also suggest that many people who could in principle be relying on this feature are not reading this list. Therefore, it seems to me that if someone wants to argue that some _N_ ought to be deprecated, the right answer is to write the draft that deprecates that _N_, and circulate it very widely. Given the _N_ that I think is under consideration, this mailing list is probably too restricted, although it's possible that we're in the right area. Let me emphasise that the above is a no-hat personal opinion. I am not moderating the conversation, insisting this discussion go elsewhere, or making any determination of whether this discussion is on-topic here. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 18 10:46: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 B24993A69D0; Tue, 18 Aug 2009 10:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.085 X-Spam-Level: X-Spam-Status: No, score=-5.085 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 4Az70zi5Oc1u; Tue, 18 Aug 2009 10:46:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0D113A69E1; Tue, 18 Aug 2009 10:46:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdShJ-000Iue-9P for namedroppers-data0@psg.com; Tue, 18 Aug 2009 17:42: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 1MdShF-000It7-FZ for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 17:42:11 +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 n7IHg4aW011040; Tue, 18 Aug 2009 10:42:04 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <165C4675-8107-4FA8-AC72-00364BAB7DE8@icsi.berkeley.edu> From: Nicholas Weaver To: Andrew Sullivan In-Reply-To: <20090818170837.GJ3163@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Tue, 18 Aug 2009 10:42:04 -0700 References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <36162FA2FEEC591D89DD9585@Ximines.local> <20090818170837.GJ3163@shinkuro.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 18, 2009, at 10:08 AM, Andrew Sullivan wrote: >> Somehow I doubt this is a major application though ... > > I'm a little uncomfortable with the trend in this thread of trying to > discern the "major" applications as opposed to the "minor" ones, on > whom one gets to impose damage. I suggest it's hard to make the > major/minor distinction in any clear way, and I also suggest that many > people who could in principle be relying on this feature are not > reading this list. Therefore, it seems to me that if someone wants to > argue that some _N_ ought to be deprecated, the right answer is to > write the draft that deprecates that _N_, and circulate it very > widely. Given the _N_ that I think is under consideration, this > mailing list is probably too restricted, although it's possible that > we're in the right area. Rather, the question is different: Has reality effectively already deprecated _N_: EG, in this specific case, have all other applications effectively assumed UDP fragments over the Internet don't work? So far, the only examples are: DNSSEC: Effectively undeployed at scale, but significant suggestions that datagrams greater than the ethernet MTU will cause problems. NSF v2: Already deprecated, and never intended for Internet usage in any case, but only within trusted networks. We don't need a draft to deprecate something. We just need to know if its already been deprecated underneath us. From owner-namedroppers@ops.ietf.org Tue Aug 18 10:51: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 E606D28C2ED; Tue, 18 Aug 2009 10:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.58 X-Spam-Level: X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=-0.980, 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 bf-INEcbYeci; Tue, 18 Aug 2009 10:51:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA7323A6872; Tue, 18 Aug 2009 10:51:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdSnw-000K65-Gl for namedroppers-data0@psg.com; Tue, 18 Aug 2009 17:49:04 +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 1MdSns-000K58-9S for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 17:49:02 +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 038062FE8ED5 for ; Tue, 18 Aug 2009 17:48:56 +0000 (UTC) Date: Tue, 18 Aug 2009 13:48:55 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: <20090818174854.GK3163@shinkuro.com> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <36162FA2FEEC591D89DD9585@Ximines.local> <20090818170837.GJ3163@shinkuro.com> <165C4675-8107-4FA8-AC72-00364BAB7DE8@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <165C4675-8107-4FA8-AC72-00364BAB7DE8@icsi.berkeley.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 10:42:04AM -0700, Nicholas Weaver wrote: > We don't need a draft to deprecate something. We just need to know if > its already been deprecated underneath us. Yes, I get this point. But "We don't know about $APP," is by no means the same as, "$APP does not exist." Part of my point is that, if the people happily building devices and applications out there were paying attention to our list (or even if there were WG participants who understood those builders as "important") then we wouldn't be in this mess at all. Especially in an old protocol like ours, the difference between theory and practice is smallery in theory &c. That isn't to say that a tentative conclusion, "_X_ is practically speaking deprecated," is the wrong one. But several previously-interested real operators of ISP networks have made noisy exits from the IETF (one of them used to be a Chair of this WG), and I don't think we should be too sanguine on the basis of a survey of WG participants. That's what (and all) I'm saying. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 18 11:09: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 D571B3A6A0F; Tue, 18 Aug 2009 11:09:35 -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=[AWL=-0.039, 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 bdJ-qV33SEKN; Tue, 18 Aug 2009 11:09:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A193A3A6E53; Tue, 18 Aug 2009 11:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdT3d-000N4p-VI for namedroppers-data0@psg.com; Tue, 18 Aug 2009 18:05:17 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdT3Z-000N3L-I2 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 18:05:16 +0000 Received: by ewy11 with SMTP id 11so4684588ewy.11 for ; Tue, 18 Aug 2009 11:05: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=vCj/XuvVmpuRBdOV7+azAKJZlp/hNMiYGJwUKIudWeE=; b=Fz5d1ExcViO59OhShmvqnkMOA94YIBRZdB8QIMe4WwkFZKPKTuJRW1lU/e9FWCIZq4 kN+HngoeG+ocjEPxcduMltliI1NSm9HEDOd4DxQhkpJskEb2wr3gUCjJ9x64+MNZXTC6 ZEBi/dnl4DwE93dPlylJDF0e3QjF67Q6688tk= 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=PhN4ImHxmqTkKZ7iRb2Y/ZDQMkhtvAO1NMhE17LZ2hrsg84Ri4qRZK1rwqVSKUo4JJ mh91XKr34pNDGTJtOp0af34/rNUfBmLVspKAK0hcyMsOw7BJntoiurkDyF20Y4U6Ub2E QTkHuMovwESUb3Waw6bLDKlBzSV3Fm/fz2llU= MIME-Version: 1.0 Received: by 10.210.70.18 with SMTP id s18mr2729819eba.45.1250618711086; Tue, 18 Aug 2009 11:05:11 -0700 (PDT) In-Reply-To: <20090818174854.GK3163@shinkuro.com> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <36162FA2FEEC591D89DD9585@Ximines.local> <20090818170837.GJ3163@shinkuro.com> <165C4675-8107-4FA8-AC72-00364BAB7DE8@icsi.berkeley.edu> <20090818174854.GK3163@shinkuro.com> From: bert hubert Date: Tue, 18 Aug 2009 20:04:51 +0200 Message-ID: <3efd34cc0908181104k6c9ccd9ck1fdce248fc653c46@mail.gmail.com> Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 7:48 PM, Andrew Sullivan wrote: > On Tue, Aug 18, 2009 at 10:42:04AM -0700, Nicholas Weaver wrote: >> We don't need a draft to deprecate something. =A0We just need to know if >> its already been deprecated underneath us. > > Yes, I get this point. =A0But "We don't know about $APP," is by no means > the same as, "$APP does not exist." =A0Part of my point is that, if the We also know 8% (or was it 12%?) of Netalyzr users have issues with fragmentation. This sounds like it corroborates the 'we know of nothing else that relies on it working end to end'. Maybe DNSSEC won't be for everybody, but only for discerning users on networks that are ok with (very) large packets? Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 11:27: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 BACF628C24C; Tue, 18 Aug 2009 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 TIwu-tSj+AiM; Tue, 18 Aug 2009 11:27:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E68B03A6A0F; Tue, 18 Aug 2009 11:27:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdTLh-000PaX-Uz for namedroppers-data0@psg.com; Tue, 18 Aug 2009 18:23:57 +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 1MdTLd-000PZq-1m for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 18:23:55 +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 n7IINmM5008311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 11:23:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> Date: Tue, 18 Aug 2009 11:23:47 -0700 To: bert hubert , Nicholas Weaver , From: Paul Hoffman Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 6:11 PM +0200 8/18/09, bert hubert wrote: >On Tue, Aug 18, 2009 at 5:37 PM, Nicholas >Weaver wrote: >> Can anyone identify a major application other than DNSSEC which uses UDP and >> assumes that packets greater than the Ethernet MTU can be sent and will be >> properly fragmented and reassembled on traffic traversing the Internet? > >"Fragmentation is like classful addressing -- an interesting early > architectural error that shows how much experimentation was going > on while IP was being designed." -- Paul Vixie > >Nothing else relies on fragmented UDP working as far as I know. So, I guess you don't know about IKE, the keying protocol for IPsec. I could introduce you two. :-) IKE runs over UDP, and always has. Some IKE messages are large due to them containing PKIX certificates and so on. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Tue Aug 18 11:47: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 A8D313A6BB7; Tue, 18 Aug 2009 11:47:30 -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 xdm-9zqzbzkG; Tue, 18 Aug 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 C816C3A68AF; Tue, 18 Aug 2009 11:47:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdTdq-00023k-9C for namedroppers-data0@psg.com; Tue, 18 Aug 2009 18:42:42 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdTdl-00022w-R9 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 18:42:40 +0000 Received: (qmail 7073 invoked by uid 399); 18 Aug 2009 18:42:34 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Aug 2009 18:42:34 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A8AF614.1040107@dougbarton.us> Date: Tue, 18 Aug 2009 11:42:28 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ray.Bellis@nominet.org.uk wrote: > >> draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP >> size it is incapable of returning to the client. > > Well, not really. It already points out that it behoves the client to > set their own EDNS0 buffer size in accordance with their MTU, with the > implication that the client should also take the proxy's "buffer MTU" > into account. This leads naturally into a thought that has been percolating in my brain throughout these fragmentation threads. It would be really nice if there were a command-line tool that admins could use to test this (where "this" is "what is my largest possible unfragmented UDP packet?"). Then at least admins who had sufficient clue to use the tool could set up there name servers appropriate and/or work to find the cause of things not being what they think they should be. I would love to jump into the fray on this immediately, but atm I'm busy trying to find ways to feed my family. :) Doug From owner-namedroppers@ops.ietf.org Tue Aug 18 12:08: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 1F61A3A6A0F; Tue, 18 Aug 2009 12:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.083 X-Spam-Level: X-Spam-Status: No, score=-5.083 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 6GJrGFWIcZoF; Tue, 18 Aug 2009 12:08:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A677F3A69D4; Tue, 18 Aug 2009 12:08:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdTxY-0005ln-BU for namedroppers-data0@psg.com; Tue, 18 Aug 2009 19:03: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 1MdTxM-0005j9-1G for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 19:02:58 +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 n7IJ2lTL020781; Tue, 18 Aug 2009 12:02:47 -0700 (PDT) Cc: Nicholas Weaver , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Doug Barton In-Reply-To: <4A8AF614.1040107@dougbarton.us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft Date: Tue, 18 Aug 2009 12:02:47 -0700 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> <4A8AF614.1040107@dougbarton.us> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 18, 2009, at 11:42 AM, Doug Barton wrote: > Ray.Bellis@nominet.org.uk wrote: >> >>> draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP >>> size it is incapable of returning to the client. >> >> Well, not really. It already points out that it behoves the client >> to >> set their own EDNS0 buffer size in accordance with their MTU, with >> the >> implication that the client should also take the proxy's "buffer MTU" >> into account. > > This leads naturally into a thought that has been percolating in my > brain throughout these fragmentation threads. It would be really nice > if there were a command-line tool that admins could use to test this > (where "this" is "what is my largest possible unfragmented UDP > packet?"). Then at least admins who had sufficient clue to use the > tool could set up there name servers appropriate and/or work to find > the cause of things not being what they think they should be. dig edns_large.{anything}.netalyzr.icsi.berkeley.edu edns_medium.{anything}.netalyzr.icsi.berkeley.edu edns_small.{anything}.netalyzr.icsi.berkeley.edu Basically a crude test, but gets you in the ballpark of small, ~1400B, ~1800B, and fragmentation almost always hits at the Ethernet MTU of 1500B > > I would love to jump into the fray on this immediately, but atm I'm > busy trying to find ways to feed my family. :) > > > Doug > From owner-namedroppers@ops.ietf.org Tue Aug 18 12: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 15A693A68AD; Tue, 18 Aug 2009 12:09:36 -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 7B2hWddNTV0z; Tue, 18 Aug 2009 12:09:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A869A28C2C2; Tue, 18 Aug 2009 12:09:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdU0H-0006Qs-Oy for namedroppers-data0@psg.com; Tue, 18 Aug 2009 19:05:53 +0000 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 1MdU0E-0006QD-68 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 19:05:52 +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 n7IJ4uQR000446; Tue, 18 Aug 2009 15:04:56 -0400 (EDT) (envelope-from weiler@tislabs.com) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n7IJ4tDJ000442; Tue, 18 Aug 2009 15:04:56 -0400 (EDT) (envelope-from weiler@tislabs.com) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 18 Aug 2009 15:04:55 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Jelte Jansen cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] experimental/testing DNSSEC algorithm identifiers In-Reply-To: <4A827535.9060400@NLnetLabs.nl> Message-ID: References: <4A827535.9060400@NLnetLabs.nl> 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]); Tue, 18 Aug 2009 15:04:56 -0400 (EDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, 12 Aug 2009, Jelte Jansen wrote: > We have 'private', but that's only one number, and currently there > are multiple algorithm proposals. Besides, it might clash with > actual privates that are used. While there are only two private numbers, we did define mechanisms for distinguishing between private algorithms (RFC4034, A.1.1). It may well be that such code, if it exists, is buggy, but I think it's worth figuring that out. Given the mechanism in 4034 A.1.1., do you really need more codepoints just for testing? -- Sam From owner-namedroppers@ops.ietf.org Tue Aug 18 12:21: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 01C9D3A6C76; Tue, 18 Aug 2009 12:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfYgTMn9wTCH; Tue, 18 Aug 2009 12:21:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02B483A6CA3; Tue, 18 Aug 2009 12:21:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdUC3-0008el-GW for namedroppers-data0@psg.com; Tue, 18 Aug 2009 19:18:03 +0000 Received: from [64.104.193.197] (helo=syd-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdUBy-0008dd-DH for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 19:18:01 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEebikoKS+eh/2dsb2JhbADAM4gtkEsFhBmBU14 X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="sig'?scan'208";a="56721864" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-2.cisco.com with ESMTP; 18 Aug 2009 19:17:53 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7IJHqIl011991; Wed, 19 Aug 2009 03:17:52 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7IJHq9B007561; Tue, 18 Aug 2009 19:17:52 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 03:17:52 +0800 Received: from [10.0.1.2] ([10.75.235.122]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 03:17:51 +0800 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <97D359B0-59D2-4AB0-A7D1-00F74174D82F@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bert hubert In-Reply-To: <3efd34cc0908181104k6c9ccd9ck1fdce248fc653c46@mail.gmail.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-84--414553127" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Wed, 19 Aug 2009 03:17:49 +0800 References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <36162FA2FEEC591D89DD9585@Ximines.local> <20090818170837.GJ3163@shinkuro.com> <165C4675-8107-4FA8-AC72-00364BAB7DE8@icsi.berkeley.edu> <20090818174854.GK3163@shinkuro.com> <3efd34cc0908181104k6c9ccd9ck1fdce248fc653c46@mail.gmail.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2009 19:17:52.0125 (UTC) FILETIME=[94DD02D0:01CA2038] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=934; t=1250623073; x=1251487073; c=relaxed/simple; s=hkgdkim1002; 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]=20What=20ELSE=20relies=20on=20 UDP=20fragmentation? |Sender:=20; bh=77ayRG6XQZAFSu9/coU+lkwt0S4U7iyfuoL6RBrRqwo=; b=igbny4y/4bKdPHC0svqPSsR4srmCiN/bQJmhWe168Eg21KpSTNxFj5qEVA PCIZiI7k/308z2INMAEUQAo6jec6/+99WhNxs1Wptp4I/FwUPwr5zJ8y7f0k DWhTfDXx65VsmpO20rWMN2bPHmWV9BtaO2dQIsW2eSs2XXzLKwKK4=; Authentication-Results: hkg-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-84--414553127 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 19 aug 2009, at 02.04, bert hubert wrote: > We also know 8% (or was it 12%?) of Netalyzr users have issues with > fragmentation. Is there a difference between IPv4 and IPv6? Or not enough IPv6 traffic to be able to count? Patrik -- that have not seen this report, sorry... --Apple-Mail-84--414553127 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) iD8DBQFKiv5evHlR2X0luNwRAqtJAJ0ey4Yi4RBHQ8AfSpFC5xTFn+3c/wCeI3lJ VQIJkAx+/g937d6ZzilGtmw= =aL3t -----END PGP SIGNATURE----- --Apple-Mail-84--414553127-- From owner-namedroppers@ops.ietf.org Tue Aug 18 12:49: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 ED2153A6E6F; Tue, 18 Aug 2009 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAEvf-2o8AQ2; Tue, 18 Aug 2009 12:49:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 104D128C0DB; Tue, 18 Aug 2009 12:49:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdUbe-000Dr4-VP for namedroppers-data0@psg.com; Tue, 18 Aug 2009 19:44:30 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdUbb-000Dqb-7l for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 19:44:29 +0000 Received: by ewy11 with SMTP id 11so4754520ewy.11 for ; Tue, 18 Aug 2009 12:44:25 -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=Mjk2z1Js4qNVsvcbzuam/Mn9jHrtA0/mEsYVazh2F8I=; b=HoXBQOu7W7K8PoB2q9IDz3+D9/spUGuzo7CX1D4b/tmScO2TAafUcA/TUeXEwPWOGf XQ+J//wm6OQMtvJpnO1Cozznj7GxwrlqYtFCMqMAz4G+QNJkNO1qns7ZBexz6ySCnxAx rNOkHGJAbr7sJvr9efuDyvwQrP/O7WPssGmO0= 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=OTJ/rtz/wThI5zc18kCvVTyP5OXipHPOMqKakOsM9fylVQ9sTrRD+dlRRxZTr8l4ce mQ8gEts9ZdnZUif1W3nqkeXwWvnnHjE+GszqeS2UhiFOr8aBN0uec1/xtGEYb5dnP0FP 4eJ/8G/cfZCa7+nXLEA62/M49RMGtkAxafXO4= MIME-Version: 1.0 Received: by 10.210.61.8 with SMTP id j8mr780638eba.34.1250624665716; Tue, 18 Aug 2009 12:44:25 -0700 (PDT) In-Reply-To: References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> From: bert hubert Date: Tue, 18 Aug 2009 21:44:05 +0200 Message-ID: <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? To: Paul Hoffman Cc: Nicholas Weaver , 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 8:23 PM, Paul Hoffman wrote: >>Nothing else relies on fragmented UDP working as far as I know. > So, I guess you don't know about IKE, the keying protocol for IPsec. I could introduce you two. :-) > > IKE runs over UDP, and always has. Some IKE messages are large due to them containing PKIX certificates and so on. This is indeed a poignant example. Especially since we find that IPSEC vendors have decided to implement countermeasures, like the "IKE Fragmentation" extension (which pre-fragments IKE messages over multiple smaller UDP packets). Or look at RFC3723 section 5.6 which discusses ways to deal with the problems of UDP fragmentation preventing IKE operation. It suggests reducing the size of certificates used. In fact, it appears we could learn a lot from the travails of the IPSEC community wrt fragmentation. I note that the Cisco implementation decides that IKE messages above 576 bytes should already be split out over multiple UDP packets... Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 12:49: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 A4FF33A6E93; Tue, 18 Aug 2009 12:49:33 -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 dhRl1SxvW78g; Tue, 18 Aug 2009 12:49:32 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 98FAB28C1D6; Tue, 18 Aug 2009 12:49:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdUbm-000DsI-NA for namedroppers-data0@psg.com; Tue, 18 Aug 2009 19:44:38 +0000 Received: from [149.20.58.5] (helo=mail.dns-oarc.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdUbj-000Dra-BH for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 19:44:37 +0000 Received: by mail.dns-oarc.net (Postfix, from userid 11202) id B6CC2BE293; Tue, 18 Aug 2009 19:44:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.dns-oarc.net (Postfix) with ESMTP id AC0ABBE1B1; Tue, 18 Aug 2009 19:44:34 +0000 (UTC) (envelope-from wessels@dns-oarc.net) Date: Tue, 18 Aug 2009 19:44:34 +0000 (UTC) From: Duane Wessels To: Doug Barton cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft In-Reply-To: <4A8AF614.1040107@dougbarton.us> Message-ID: References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> <4A8AF614.1040107@dougbarton.us> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, 18 Aug 2009, Doug Barton wrote: > if there were a command-line tool that admins could use to test this > (where "this" is "what is my largest possible unfragmented UDP > packet?"). Then at least admins who had sufficient clue to use the See also https://www.dns-oarc.net/oarc/services/replysizetest $ dig +short rs.dns-oarc.net txt From owner-namedroppers@ops.ietf.org Tue Aug 18 13:34: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 EB20D3A6D2F; Tue, 18 Aug 2009 13:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 WNvU3Z0--9lF; Tue, 18 Aug 2009 13:34:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C834B28C3A3; Tue, 18 Aug 2009 13:33:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVJZ-000L17-44 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 20:29:53 +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 1MdVJU-000L0J-4a for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 20:29:51 +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 n7IKTeAO015928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 13:29:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> Date: Tue, 18 Aug 2009 13:29:38 -0700 To: bert hubert From: Paul Hoffman Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Cc: Nicholas Weaver , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 9:44 PM +0200 8/18/09, bert hubert wrote: >On Tue, Aug 18, 2009 at 8:23 PM, Paul Hoffman wrote: >>>Nothing else relies on fragmented UDP working as far as I know. >> So, I guess you don't know about IKE, the keying protocol for IPsec. I could introduce you two. :-) >> >> IKE runs over UDP, and always has. Some IKE messages are large due to them containing PKIX certificates and so on. > >This is indeed a poignant example. Especially since we find that IPSEC >vendors have decided to implement countermeasures, like the "IKE >Fragmentation" extension (which pre-fragments IKE messages over >multiple smaller UDP packets). Some vendors have done this, of course. How does that relate to the original question: At 8:37 AM -0700 8/18/09, Nicholas Weaver wrote: >Can anyone identify a major application other than DNSSEC which uses UDP and assumes that packets greater than the Ethernet MTU can be sent and will be properly fragmented and reassembled on traffic traversing the Internet? IKE uses UDP. IKE assumes that packets yadda yadda. Some vendors have created proprietary ways of preventing the problem of firewalls that block fragmented UDP. >Or look at RFC3723 section 5.6 which discusses ways to deal with the >problems of UDP fragmentation preventing IKE operation. It suggests >reducing the size of certificates used. Yep. >In fact, it appears we could learn a lot from the travails of the >IPSEC community wrt fragmentation. I'm not sure there is "a lot" to learn other than "the IPsec community has found that some firewalls block fragmented UDP; normal IKE sometimes produces fragmented UDP; therefore it is good to avoid producing fragmented UDP". The problem has not been so great that there is any work in the IPsec space to standardize ways to avoid fragmenting UDP. OTOH, DNSSEC might cause fragmented UDP more often than IKE does, given the extremely low usage of certificates in IKE, much less usage of certificates that are long enough to cause fragmentation. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Tue Aug 18 13: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 E44A33A6A17; Tue, 18 Aug 2009 13:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPDicxypfmqx; Tue, 18 Aug 2009 13:40:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C0263A6978; Tue, 18 Aug 2009 13:40:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVQi-000M81-MG for namedroppers-data0@psg.com; Tue, 18 Aug 2009 20:37:16 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVQa-000M63-KP for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 20:37:14 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 4FC1F75D856; Tue, 18 Aug 2009 13:37:06 -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 pgOyJRbAJpRw; Tue, 18 Aug 2009 13:37:04 -0700 (PDT) Received: from [10.0.1.8] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 16E5075D846; Tue, 18 Aug 2009 13:37:04 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: <9CFFA1D9-5E8D-4807-94D0-A444EA21BAB1@virtualized.org> From: David Conrad To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Cutting to the chase (was Re: [dnsext] EDNS Page Option draft) Date: Tue, 18 Aug 2009 10:37:03 -1000 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <16045.1250524771@nsa.vix.com> <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> <18326.1250527802@nsa.vix.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hi, On Aug 17, 2009, at 12:42 PM, Nicholas Weaver wrote: > Especially since this isn't a problem for most DNS, only DNSSEC. > > So what will happen? People turn on DNSSEC, get either failures and > timeouts and fallbacks to TCP on the resolver end, greatly increased > load on the authority end, and either the authorities work around > things by making their responses small, or the resolvers turn off > DNSSEC. > > If we actually want DNSSEC over UDP, we should resign ourselves to > doing an application-level fragmentation when responses exceed the > Ethernet MTU. > > Because there is now enshrined in the de-facto Internet reality two > limits: The Ethernet MTU, and devices that can't handle fragments. An informal, wildly unscientific survey... So, in the relatively near future, the root zone will be signed. Current plans are to NOT make any special effort to reduce root response size (see ns.iana.org for a reasonable facsimile for what the signed root is going to look like). Last I checked, about 70% of the queries hitting the root had DO=1, with somewhere around 75% of those queries advertising a buffer size of 4096. On the fateful date the root gets signed, what do you think is going to happen? a) there will be much rejoicing b) no one but a few geeks will notice c) a percentage of folks will have resolution problems (what percentage?) d) some root server instances will fall over from increased load but no one other than geeks will notice e) some root server instances will fall over and non-geeks will notice due to performance degradation f) something else (what?) (combinations of answers are obviously ok) Respond publicly or privately to me, I'll summarize the responses. Thanks, -drc From owner-namedroppers@ops.ietf.org Tue Aug 18 13:49: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 F177328C397; Tue, 18 Aug 2009 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 nvp2k02l5Owb; Tue, 18 Aug 2009 13:49:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2047528C375; Tue, 18 Aug 2009 13:49:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVZM-000NSS-Dq for namedroppers-data0@psg.com; Tue, 18 Aug 2009 20:46:12 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVZI-000NR6-Gf for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 20:46:10 +0000 Received: by ewy11 with SMTP id 11so4795887ewy.11 for ; Tue, 18 Aug 2009 13:46:06 -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=5+KheOgzvLbC6blTlj12ZRnXVCzv0NZkVboCiusYqhM=; b=c88vuT8zrgalhN5Ze7Be17Hxk/0qmTGO9oUw25y0ETosUaY0Nwrm7CG7G2+/qxLJsF qrClezoO/VoN406f+IRRFxpm8WqvLODNUStLylwNq7NyhnJXS6OTFse3bITe5zBNl60B BCTIMwr+B6izY2t7VM+6mGRN3QssqyR4Wa7fo= 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=OAYFTMRDKlKtqCBP7GvllVeOgbo6SIdFn8OF6t7exvIwIudZ6WkzoPQhW0YdXBrIH0 bGfhqawSz+WCQZ44Jbj7Yt+Rhn592VZU1O32XSLvSceEC/kCuBMtAN3JzRiWJslIh+hX MlVCarNjMmMAos4Z9w5WhQGdRz0K96/lqxoog= MIME-Version: 1.0 Received: by 10.210.41.14 with SMTP id o14mr5103743ebo.23.1250628366119; Tue, 18 Aug 2009 13:46:06 -0700 (PDT) In-Reply-To: References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> From: bert hubert Date: Tue, 18 Aug 2009 22:45:46 +0200 Message-ID: <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? To: Paul Hoffman Cc: Nicholas Weaver , 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 10:29 PM, Paul Hoffman wrote: > [...] given the extremely low usage of certificates in IKE, much less usage of certificates that are long enough to cause fragmentation. So, getting back to Nicholas' question, IKE is not (generally) relying on UDP fragmentation, except sometimes. For those cases, vendors have felt the need to offer their customers proprietary workarounds, presumably because there were problems, enough of them to be noticeable. I don't want to be nasty about this, but it does appear 'we' are facing a very big problem with DNSSEC deployability as is, to the point that I wonder if we'll need to move to ECDSA before confidently being able to roll all of this out. Don't forget that if people turn DNSSEC on, and it breaks, they won't believe it next time implementors say it is 'ready for use'. Nicholas, do you feel confident about the statistics you derive about how many people can't see bigger packets? Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 13:50: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 7C7F43A6A17; Tue, 18 Aug 2009 13:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEUeYr9GEfsb; Tue, 18 Aug 2009 13:50:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF3893A69C7; Tue, 18 Aug 2009 13:50:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVZA-000NPz-92 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 20:46:00 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVZ6-000NOz-Aq for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 20:45:58 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 674005656C; Tue, 18 Aug 2009 16:45:55 -0400 (EDT) Date: Tue, 18 Aug 2009 16:45:54 -0400 (EDT) From: Paul Wouters To: Paul Hoffman cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? In-Reply-To: Message-ID: References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, 18 Aug 2009, Paul Hoffman wrote: >> Nothing else relies on fragmented UDP working as far as I know. > > So, I guess you don't know about IKE, the keying protocol for IPsec. I could introduce you two. :-) > > IKE runs over UDP, and always has. Some IKE messages are large due to them containing PKIX certificates and so on. Have you seen that work? With openswan we don't really see that working at all, and at times I have to tell people to go back to 1024bit RSA keys on their X.509 certs if they need to be send with IKE. So I'm not sure if this is a good example of "fragmenting udp works". Paul From owner-namedroppers@ops.ietf.org Tue Aug 18 13: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 977323A6A93; Tue, 18 Aug 2009 13:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.034 X-Spam-Level: **** X-Spam-Status: No, score=4.034 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVP0Wg9TP107; Tue, 18 Aug 2009 13:55:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA4C63A6A17; Tue, 18 Aug 2009 13:55:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVfB-000OPC-Og for namedroppers-data0@psg.com; Tue, 18 Aug 2009 20:52:13 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVf3-000OO2-Ci for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 20:52:07 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1MdVf2-0003UN-LX for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:52:04 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MdVex-0006fb-RK for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:51:59 +0100 Message-ID: <406156C126454795B38BBC396D4DED73@localhost> From: "George Barwood" To: Subject: [dnsext] EDNS Page Option draft updated Date: Tue, 18 Aug 2009 21:51:50 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have updated my internet draft : Abstract Describes an EDNS option to allow large DNS responses to be sent using small UDP packets. http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-01.txt Summary of changes: - Support for proxies that truncate at 512 bytes. - Follow-up requests may be sent in parallel, so total response time is 2 x RTT. - The MAC has gone. As before, your comments are appreciated. Regards, George From owner-namedroppers@ops.ietf.org Tue Aug 18 14:16: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 C0A933A6E29; Tue, 18 Aug 2009 14:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF7u32lqBQiR; Tue, 18 Aug 2009 14:16:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA0933A6BF8; Tue, 18 Aug 2009 14:16:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVyU-0001d0-Ea for namedroppers-data0@psg.com; Tue, 18 Aug 2009 21:12:10 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVyQ-0001cQ-Tk for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:12:08 +0000 Received: from crankycanuck.ca (static-68-179-76-140.ptr.terago.net [68.179.76.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9593A2FE8ED5 for ; Tue, 18 Aug 2009 21:12:05 +0000 (UTC) Date: Tue, 18 Aug 2009 17:12:03 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: <20090818211203.GB4128@shinkuro.com> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Tue, Aug 18, 2009 at 10:45:46PM +0200, bert hubert wrote: > Don't forget that if people turn DNSSEC on, and it breaks, they won't > believe it next time implementors say it is 'ready for use'. I think that's true. The important question to ask, for deployment purposes (and I suggest the answer to this belongs on another list), is what "it breaks" means. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 18 14:28: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 9BEDA3A6E17; Tue, 18 Aug 2009 14:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.082 X-Spam-Level: X-Spam-Status: No, score=-5.082 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 TxMqblIDhXYB; Tue, 18 Aug 2009 14:28:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8C3428C208; Tue, 18 Aug 2009 14:28:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWBA-0003ZD-GN for namedroppers-data0@psg.com; Tue, 18 Aug 2009 21:25:16 +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 1MdWB6-0003Y1-Ia for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:25:14 +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 n7ILPAqg007052; Tue, 18 Aug 2009 14:25:10 -0700 (PDT) Cc: Nicholas Weaver , Paul Hoffman , namedroppers@ops.ietf.org Message-Id: <153FF894-FE98-42DD-9943-4BD2CC37C02C@ICSI.Berkeley.EDU> From: Nicholas Weaver To: bert hubert In-Reply-To: <3efd34cc0908181345u14861163x5217327c10088af9@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 v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Tue, 18 Aug 2009 14:25:10 -0700 References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 18, 2009, at 1:45 PM, bert hubert wrote: > > Nicholas, do you feel confident about the statistics you derive about > how many people can't see bigger packets? Somewhat confident but NOT completely. Its enough to say "There is a potential problem here", the relative root causes of the problem (fragments vs DNS<=512B assumptions: fragments appear to be the big problem for recursive resolvers, and about 2/3rds for the end-host systems), but not exactly the scale of the problem: the error bars could be huge. Simply because the Netalyzr run is an incredibly biased and self- selecting data-set. Eg, how it got slashdotted caused ~10%+ of the tests to be from Comcast IPs! We've identified some other biases as well, and who knows how many biases exist that we don't know about. However, for those who are already doing monitoring of open recursive resolvers, the same basic probing methodology could be used (including the same authority we already have set up, so its really just a few more names into the query stream), and hopefully I can find someone who already has that infrastructure in place who'd be interested in adding the names to the queries, and possibly doing some other tests as well. This would also be a biased data set (you only get open recursive resolvers and cases where someone has set up an open proxy to their recursive resolver), but by being a different set of biases, it should give us a better feel for what the real numbers are. From owner-namedroppers@ops.ietf.org Tue Aug 18 15:00: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 89D993A68F8; Tue, 18 Aug 2009 15:00:17 -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.032, 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 K0kYrM181kst; Tue, 18 Aug 2009 15:00:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 964A63A67B7; Tue, 18 Aug 2009 15:00:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWe6-0007nv-Bh for namedroppers-data0@psg.com; Tue, 18 Aug 2009 21:55:10 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWe2-0007n9-11 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:55:07 +0000 Received: by ewy11 with SMTP id 11so4838000ewy.11 for ; Tue, 18 Aug 2009 14:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=5s5ysxHnO9IkmGknJu2rwkLmerI3xuDIhUlK6R2KUTg=; b=PcA19fd0d7SxxVVvLmIce+lHzqWz3xseDL5GcusVx7lsXsuyfnSrXYjkHdN3DzFW79 wSa9k7WI8oGQExlufiYPTh0r3t/vQM8OC+L97Hi0xLSim2oVqva56QBNJYhuLMaByIi9 3W9eMuxTDwaagtwgB383/cyHNGlevtpQ9yiIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; b=wvZom/XdD78bM2ytt8m/3NqVYGMTrv3511spz9j/Bjo+OSVV4QBIHpXJXYQWSeLqjY PUDrmCzwEC12d2/tMa4lv1MURreIyewQrrC1QH4vsEQFVMqTlWxnjICEVx5+ZoL84IOL aVvhQb3SJfZUFOBcHvEUMr794CuXFyIp2uDAs= MIME-Version: 1.0 Received: by 10.210.70.3 with SMTP id s3mr3926806eba.79.1250632501714; Tue, 18 Aug 2009 14:55:01 -0700 (PDT) From: bert hubert Date: Tue, 18 Aug 2009 23:54:41 +0200 Message-ID: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> Subject: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 11:12 PM, Andrew Sullivan wrote: > No hat. > I think that's true. =A0The important question to ask, for deployment > purposes (and I suggest the answer to this belongs on another list), > is what "it breaks" means. Perhaps - but from the 'theoretical side', we should be aware of what we have wrought. Oddly enough, some very common (.gov) responses are fragmented right now, and we don't see issues. The two biggest typical DNSSEC responses appear to be: 1) the one with the DNSKEY (that could, btw, travel safely over TCP, since it should be none too frequent, and the validating resolver *knows* it might be a whopper). This includes 'ANY' queries, which could well return DNSKEY. .GOV has this one at 1166 bytes, .ORG at 1723 and .SE at 4 kilobytes. 2) an NSEC3 NXDOMAIN (which comes in unexpectedly) Response 1 is the least scary, since it should only be performed by people that have actively turned on DNSSEC validation, or who are doing relatively rare ANY queries. If you can't deal with the (huge) size of this response, your normal DNS will work, but nothing will validate. Response '2' hits all recent BINDs that in their pioneering wisdom decided to set do=3D1 on outgoing queries. If that one gets too big, all BIND users will instantly have a problem. I actually & honestly do think ISC did us a service setting do=3D1 by default btw. Better suffer now than discover a problem later. Impact ---------- Response 1 is the biggest, but only impacts 'DNSSEC pioneers', and they could move to TCP for this query. Response 2 appears to be relatively harmless, and I don't understand why. Almost all .GOV do=3D1 NXDOMAIN answers are fragmented right now. And I don't hear people complaining, so there may be some hope yet. Nicholas, any ideas? Or is BIND being really smart with fallback? Are any of the .GOV people at liberty to share their experiences? Response '2' might still very well kill DNSSEC for a significant percentage of people *or zones*, which would lead to the aforementioned 'I turned it on and stuff broke' behaviour. This pain will be borne whenever someone DNSSEC signs his zone, and someone behind a validating resolver (with a trust anchor) tries to access that zone. 23:43:30.421519 IP 10.0.1.47.58971 > 76.74.254.208.53: 56855+ [1au] A? www.c1a.gov. (40) 23:43:30.590564 IP 76.74.254.208.53 > 10.0.1.47.58971: 56855 NXDomain*- 0/8/1 (1472) 23:43:30.590624 IP 76.74.254.208 > 10.0.1.47: udp ;; MSG SIZE rcvd: 1503 Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 15:00: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 C76003A68F8; Tue, 18 Aug 2009 15:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 1X7TTN8NP4uH; Tue, 18 Aug 2009 15:00:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFA653A67B7; Tue, 18 Aug 2009 15:00:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWf7-00080l-5x for namedroppers-data0@psg.com; Tue, 18 Aug 2009 21:56:13 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWf3-0007zC-6X for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:56:11 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 5E0A15656C; Tue, 18 Aug 2009 17:56:08 -0400 (EDT) Date: Tue, 18 Aug 2009 17:56:07 -0400 (EDT) From: Paul Wouters To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? In-Reply-To: <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> Message-ID: References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, 18 Aug 2009, bert hubert wrote: > facing a very big problem with DNSSEC deployability as is, to the > point that I wonder if we'll need to move to ECDSA before confidently > being able to roll all of this out. > > Don't forget that if people turn DNSSEC on, and it breaks, they won't > believe it next time implementors say it is 'ready for use'. How many more decades are we help those people fix their routers and firewalls? I mean, Cisco still says at www.cisco.com/web/about/security/intelligence/dns-bcp.html DNS message size limitations DNS amplification and reflection attacks are more effective when leveraging large DNS messages than small DNS message sizes. The message-length parameters submode command for policy-map type inspect dns can be used to ensure that message sizes to not exceed a specified size thus reducing the efficiency of these attacks. This feature is available beginning with software release 7.2(1) for Cisco ASA and Cisco PIX Firewalls. This feature is available beginning with software release 3.1 for FWSM Firewalls. This function is enabled by default with a limit of 512 bytes. Seriously, if you're still setting "message-length maximum 512" in your network, you deserve to keep all pieces. A lot of people have already enabled and deployed DNSSEC. It will be hard for anyone to say "dnssec is broken" instead of "my network is broken". Paul From owner-namedroppers@ops.ietf.org Tue Aug 18 15:01: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 382D03A68F8; Tue, 18 Aug 2009 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmB2N5BP5H2g; Tue, 18 Aug 2009 15:01:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D3C53A67B7; Tue, 18 Aug 2009 15:01:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWhD-0008IQ-Sb for namedroppers-data0@psg.com; Tue, 18 Aug 2009 21:58:23 +0000 Received: from [209.85.216.173] (helo=mail-px0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWhA-0008Hg-A3 for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 21:58:21 +0000 Received: by pxi3 with SMTP id 3so2539449pxi.32 for ; Tue, 18 Aug 2009 14:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=nmGIZPXB4HoNRmfQhSUVZopvvxEkScqMujI5XNOmARs=; b=d6MozGQacpGDgqBcmnCNILaCCfV7z7pi0JBwfhdm7Qibivjq2UDabTVSyNqSSSiOKE ZA3ApRtZZAkV/0xzOGsWwUd6wQXaV+275lLIwYKPtKeWsmM+COE6wWK3umgNc2Fc9D36 ykUikevhdlPlIhQjKA26Bb2nqsd065MrcSIqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BbRHqs6tFLpG3j1x7pOYee7u/jkywlI9WDUpkELMjgTctmgts0sqUYQ1lShv9CN4UW f1vCLofnZpur495KKAmNMyyE7VrIQKYtpIVCsy2UV5iyjMdqLNKSwDMoboG5o9hcmqY0 OaOmZWYDyr7Ik4pYnPwnNEIpgKtBQRflnz0v4= Received: by 10.115.85.27 with SMTP id n27mr5950279wal.188.1250632699853; Tue, 18 Aug 2009 14:58:19 -0700 (PDT) Received: from SJC-Office-NAT-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id l37sm13537374waf.40.2009.08.18.14.58.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 14:58:19 -0700 (PDT) Message-ID: <4A8B23F8.3000609@gmail.com> Date: Tue, 18 Aug 2009 14:58:16 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> <20090818211203.GB4128@shinkuro.com> In-Reply-To: <20090818211203.GB4128@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/18/09 2:12 PM, Andrew Sullivan wrote: > No hat. > > On Tue, Aug 18, 2009 at 10:45:46PM +0200, bert hubert wrote: > >> Don't forget that if people turn DNSSEC on, and it breaks, they won't >> believe it next time implementors say it is 'ready for use'. > > I think that's true. The important question to ask, for deployment > purposes (and I suggest the answer to this belongs on another list), > is what "it breaks" means. 1) Reduction in IEEE CRC error detection reliably. http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf 2) Fragmentation increases packet spoofing vulnerability. 3) Fragmentation increase resource exhaustion vulnerability. 4) Increased network amplification risks from none validated sources. For example, current email authorization schemes might chain transactions via cached resource records and cause distributed recipients to modulate queries based upon email local-parts. -Doug From owner-namedroppers@ops.ietf.org Tue Aug 18 15: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 7D3933A6942; Tue, 18 Aug 2009 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 JpgS-pN4pg-G; Tue, 18 Aug 2009 15:24:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30D8A3A6837; Tue, 18 Aug 2009 15:23:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdX2U-000B8C-CP for namedroppers-data0@psg.com; Tue, 18 Aug 2009 22:20:22 +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 1MdX2Q-000B7a-1I for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 22: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 D440BE60A2; Tue, 18 Aug 2009 22:20:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7IMKEw9004852; Wed, 19 Aug 2009 08:20:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908182220.n7IMKEw9004852@drugs.dv.isc.org> To: bert hubert Cc: Paul Wouters , namedroppers@ops.ietf.org From: Mark Andrews References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-reply-to: Your message of "Tue, 18 Aug 2009 18:27:47 +0200." <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> Date: Wed, 19 Aug 2009 08:20:14 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com>, bert hubert writes: > On Tue, Aug 18, 2009 at 6:23 PM, Paul Wouters wrote: > > >> It might be feasible to do two queries, DNSKEY DO=0 and RRSIG DO=1. > >> Could save some bytes. > > > > That sounds horrible. Where do you put the DNSKEY while doing the RRSIG? > > It can't go into the cache yet.... > > I suggest the stack. > > >> But in general, without fragmentation working reliably or allowing > >> ('blessing') TCP, there is a problem. > > > > Yeah, people just will have to update their cisco firewall policies :P > > In general, people will change zilch for DNSSEC (or worse, they can't > change it). It is up to the DNSSEC community to become deployable, and > not to ask the internet to become suitable for DNSSEC deployment. > > Bert > They will for plain DNS. Just put 256 byte MTU link, for DNS UDP packets, between the roots and the rest of the Internet and the problem will be gone within a week. It will approximtely double the DNS UDP packet count. All IPv4 devices are supposed to be able to resassemble UDP datagrams used. That is why the 512 limit was choosen for DNS in the first place. So that DNS didn't exceed the miminmum reassembly buffer size. Firewalls are about "Can I get way with doing this?". You just need to make the answer "No" and the configuration/implementation will change. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 15: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 80A423A6A89; Tue, 18 Aug 2009 15:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 4tCH3hskjDw2; Tue, 18 Aug 2009 15:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 025013A69AE; Tue, 18 Aug 2009 15:35:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdXDS-000Cn1-TU for namedroppers-data0@psg.com; Tue, 18 Aug 2009 22:31:42 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdXDP-000CmD-2F for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 22:31:40 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 5E1CA5656C; Tue, 18 Aug 2009 18:31:38 -0400 (EDT) Date: Tue, 18 Aug 2009 18:31:38 -0400 (EDT) From: Paul Wouters To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow In-Reply-To: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> Message-ID: References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, 18 Aug 2009, bert hubert wrote: > Response 2 appears to be relatively harmless, and I don't understand > why. Almost all .GOV do=1 NXDOMAIN answers are fragmented right now. > And I don't hear people complaining, so there may be some hope yet. What kind of complaint were you expecting from people trying to reach doesnotexist.gov ? :) > Response '2' might still very well kill DNSSEC for a significant > percentage of people *or zones*, which would lead to the > aforementioned 'I turned it on and stuff broke' behaviour. This pain > will be borne whenever someone DNSSEC signs his zone, and someone > behind a validating resolver (with a trust anchor) tries to access > that zone. I've been running DNSSEC on my zones for years. I've never hear someone complain they couldn't reach my sites. I've been running dnssec on my resolvers with all known trust anchors loaded and DLV enabled for about a year now, and have only seen a few problems, and those mostly related to enabling 0x20 and wijngaards-dnsext-resolver-side-mitigation, not dnssec in itself. If you have a clean network, these things do "just work". And it is not about when "we" enable dnssec. dnssec is already enabled by enough people to know that by Toutatis, the sky is not going to fall down. (for an overview of deployments: http://www.xelerance.com/dnssec/) Paul From owner-namedroppers@ops.ietf.org Tue Aug 18 15:55: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 254063A6991; Tue, 18 Aug 2009 15:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 BSvHZEVvg84P; Tue, 18 Aug 2009 15:55:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56A003A67B4; Tue, 18 Aug 2009 15:55:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdXXE-000FZ9-92 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 22:52:08 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdXXA-000FXl-TY for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 22:52:06 +0000 Received: by ewy11 with SMTP id 11so4866456ewy.11 for ; Tue, 18 Aug 2009 15:52:03 -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=D52vzxpjZAu9hEN83d4lXaLNuUhzTTBxwm3IpVUkS5Q=; b=snZ2zRvqtFvoKTOh2V7VtYymVx79kxHEjG/Ka5oDKYcme9ziyGvLnqqmz8hBM9hFPp ticwN4ibCFh9KPs0wrUx4RE6gWho2xXnRLjW3QcfkiKfEmQx2mWLlP/g/tWsMJiAuRu9 GHNxLl+CoNGZO/PpwajyYIJaTAjQ6tW7t7GfQ= 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=OQSIrSTMUXkqQdLCzgrsbu87fWj3VqmWdmldZt+mDBPMrrIWu7wxG1auxD4HfB9Ud0 lNXYrp8U3PupSwFFYKlMmlLArGYPZ6XZR0/+l3dMPeAmZR2KkT+QfkVWNoJdpA2DQgdR tZRL3bwPBSx4loBAp4urzVeWyrWkdfTYVwx4s= MIME-Version: 1.0 Received: by 10.210.61.8 with SMTP id j8mr978707eba.34.1250635923096; Tue, 18 Aug 2009 15:52:03 -0700 (PDT) In-Reply-To: References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> From: bert hubert Date: Wed, 19 Aug 2009 00:51:43 +0200 Message-ID: <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow To: Paul Wouters 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Aug 19, 2009 at 12:31 AM, Paul Wouters wrote: >> Response 2 appears to be relatively harmless, and I don't understand >> why. Almost all .GOV do=1 NXDOMAIN answers are fragmented right now. >> And I don't hear people complaining, so there may be some hope yet. > > What kind of complaint were you expecting from people trying to > reach doesnotexist.gov ? :) Good point. > If you have a clean network, these things do "just work". This, however, is not the point; we are not dealing with a 'clean network'. We are dealing with a network ('The Internet') that saw a 600-fold increase in TCP traffic, which should not have happened. I understand your stance that we should no longer 'wait' for the people behind, say, Cisco firewalls. But I'm afraid in reality, it is not about us waiting for them. But this might be getting too operational for DNSEXT. Bert From owner-namedroppers@ops.ietf.org Tue Aug 18 16:20: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 AE4263A6948; Tue, 18 Aug 2009 16:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Cju+Tiw44pud; Tue, 18 Aug 2009 16:20:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D47203A686D; Tue, 18 Aug 2009 16:20:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdXrj-000IHP-U8 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 23:13: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 1MdXrg-000IGu-FP for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 23:13:17 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7AB65E609D; Tue, 18 Aug 2009 23:13: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 n7INDCO2005066; Wed, 19 Aug 2009 09:13:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908182313.n7INDCO2005066@drugs.dv.isc.org> To: bert hubert Cc: William Allen Simpson , namedroppers@ops.ietf.org From: Mark Andrews References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-reply-to: Your message of "Tue, 18 Aug 2009 17:36:51 +0200." <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> Date: Wed, 19 Aug 2009 09:13:12 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com>, bert hubert writes: > On Tue, Aug 18, 2009 at 4:52 PM, Mark Andrews wrote: > > You need to learn how to manage keys so there isn't two sets of > > signatures. The DNSKEY response will have multiple signature but > > the rest of the responses don't need them. > > The DNSKEY DO=1 query still needs to happen though. And it is 'the hugeness'. > It might be feasible to do two queries, DNSKEY DO=0 and RRSIG DO=1. > Could save some bytes. > > But in general, without fragmentation working reliably or allowing > ('blessing') TCP, there is a problem. Nobody has said no TCP, just that most queries should be resolveable with just UDP. Mark > Bert -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 16:30: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 AD4613A6B73; Tue, 18 Aug 2009 16:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYYGrNn9q8Uc; Tue, 18 Aug 2009 16:30:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 853F03A6F3F; Tue, 18 Aug 2009 16:30:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdY3N-000Jza-Qt for namedroppers-data0@psg.com; Tue, 18 Aug 2009 23:25:21 +0000 Received: from [64.104.193.197] (helo=syd-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdY3H-000JyS-VK for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 23:25:19 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMTUikoKS+ej/2dsb2JhbAC/E4gtkHUFhBmCMQ X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="sig'?scan'208";a="56724807" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by syd-iport-2.cisco.com with ESMTP; 18 Aug 2009 23:25:12 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7INPBoI028697; Wed, 19 Aug 2009 07:25:11 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7INPBsu008735; Tue, 18 Aug 2009 23:25:11 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 07:25:11 +0800 Received: from [10.0.1.2] ([10.75.235.122]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 07:25:10 +0800 Cc: namedroppers@ops.ietf.org Message-Id: <09236FA2-D272-4D7D-8D2F-808AD118D7A0@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Andrew Sullivan In-Reply-To: <20090818211203.GB4128@shinkuro.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-96--399738791" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Wed, 19 Aug 2009 07:24:44 +0800 References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> <20090818211203.GB4128@shinkuro.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2009 23:25:11.0070 (UTC) FILETIME=[219053E0:01CA205B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2243; t=1250637911; x=1251501911; c=relaxed/simple; s=hkgdkim2001; 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]=20What=20ELSE=20relies=20on=20 UDP=20fragmentation? |Sender:=20; bh=inmGs/jng41R3FtvTtHqy+13HLcLY9MG7xVH3Zzsp3s=; b=RyqAWf7gzuDtMVnSZ3JorOLnhO/11TEx1OifgikxYVXywZkvgdyaz8sO2A clD8BjWSicqcbOfyjAoudt427NiGmvv+zYFmk9JLreATaSAURhfl0AjZafJg Yk8Q0Qdj5e6z3KGRMINOwhh7sbnakH46jBT9S49OtNwbkBh8w/Fmc=; Authentication-Results: hkg-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-96--399738791 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 19 aug 2009, at 05.12, Andrew Sullivan wrote: > On Tue, Aug 18, 2009 at 10:45:46PM +0200, bert hubert wrote: > >> Don't forget that if people turn DNSSEC on, and it breaks, they won't >> believe it next time implementors say it is 'ready for use'. > > I think that's true. The important question to ask, for deployment > purposes (and I suggest the answer to this belongs on another list), > is what "it breaks" means. We have to be careful with the two for me different questions: - Do fragmented UDP packets drop in a rate that is so high that we can not rely on it working for any existing or future protocol in the IETF - UDP packet fragmentation issues create problems for DNSSEC in real life The second of course relies on the fragmentation actually happen for DNSSEC signed responses, and as I think most fragmentation issues happens in soho firewalls, that DNSSEC signed responses do not traverse, it is not much of a problem. Or let me put this differently: In Sweden where we do have some signed domains, we have not heard of this problem. What we do see problems with have to do with key rollover, registry/ registrar problems etc. But not fragmentation of UDP packets. My guess is that this might be because verification is NOT happening on the customer side of the SOHO routers that are said to create problems with UDP fragmentation, which implies we still do not know what is happening, and whether the statement actually is true, "do fragmentation of UDP packets create problems for DNSSEC deployment". paf --Apple-Mail-96--399738791 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) iD8DBQFKizg8vHlR2X0luNwRAoXZAJwP/WvbAlHF1fKKyrzdpN8o2d8mnwCdFY+5 MkMtv5VxRiMvArjq4tPs1/g= =nmw4 -----END PGP SIGNATURE----- --Apple-Mail-96--399738791-- From owner-namedroppers@ops.ietf.org Tue Aug 18 16:37: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 605513A68C2; Tue, 18 Aug 2009 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm7Mt0ElPufl; Tue, 18 Aug 2009 16:37:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48DF53A6BC1; Tue, 18 Aug 2009 16:37:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdYBI-000L37-1w for namedroppers-data0@psg.com; Tue, 18 Aug 2009 23:33:32 +0000 Received: from [64.104.193.197] (helo=syd-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdYBC-000L2P-AU for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 23:33:28 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAzXikoKS+ej/2dsb2JhbAC/H4gtkHUFhBmBU14P X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="sig'?scan'208";a="56724948" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by syd-iport-2.cisco.com with ESMTP; 18 Aug 2009 23:33:23 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7INXMF5029790; Wed, 19 Aug 2009 07:33:22 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7INXMMm010042; Tue, 18 Aug 2009 23:33:22 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 07:33:22 +0800 Received: from [10.0.1.2] ([10.75.235.122]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 07:33:21 +0800 Cc: bert hubert , namedroppers@ops.ietf.org Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Wouters In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-98--399223538" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Wed, 19 Aug 2009 07:33:19 +0800 References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2009 23:33:22.0289 (UTC) FILETIME=[465A6610:01CA205C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2509; t=1250638402; x=1251502402; c=relaxed/simple; s=hkgdkim2001; 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]=20What=20ELSE=20relies=20on=20 UDP=20fragmentation? |Sender:=20; bh=4ojwEaXCRmv0UeptFYW+i5y7kZsUx31agd3B9a5Hroo=; b=Y+zOTbjt+jE8w16UgiQe0h7petpxkkvQgtbq1+mm0vDNyCgF/SZuFtBKXy J5LFBMChXFXLG0Muz8wCjKBn4b3LKWU3RPQZhMgfGBEaSYnADCw2BUFZncDf qDd5H0rRcLXIHtsC+wrQyMfQ0eVTbBCpagow/Mp2KUDwFgvnO2PFk=; Authentication-Results: hkg-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-98--399223538 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 19 aug 2009, at 05.56, Paul Wouters wrote: > I mean, Cisco still says at www.cisco.com/web/about/security/intelligence/dns-bcp.html > > DNS message size limitations > > DNS amplification and reflection attacks are more effective when > leveraging large DNS messages than small DNS message sizes. The > message-length parameters submode command for policy-map type inspect > dns can be used to ensure that message sizes to not exceed a > specified > size thus reducing the efficiency of these attacks. > > This feature is available beginning with software release 7.2(1) for > Cisco ASA and Cisco PIX Firewalls. This feature is available > beginning > with software release 3.1 for FWSM Firewalls. This function is > enabled > by default with a limit of 512 bytes. > > Seriously, if you're still setting "message-length maximum 512" in > your network, > you deserve to keep all pieces. Note that this is a function in a firewall, and this has nothing to do with IP fragmentation as this is an inspection of the DNS payload size. That said, I agree with you. If one have firewalls set to ensure that DNS payload MUST be smaller than 512 bytes, and still try to run DNSSEC (which of course will fail), then one should deserve to loose. Note further than the feature you describe is a bit more delicate than the text above describe. The feature also recognize the ENDS0 announcement of the response buffer size, so if you send out a request with EDNS0 size limitation, the firewall inspects the size of the response that it is not larger than what you announced. So the text you sent is regarding non-EDNS0 tagged packets. But in reality the algorithm used is even more complicated, so people that want to know how this inspection works should read the full documentation. Patrik --Apple-Mail-98--399223538 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) iD8DBQFKizo/vHlR2X0luNwRAuFKAKD2eaOxbIuhh0buYend4qsxBmokQgCgkHVF MNHafr1BjP7mfS3YjjMyCWY= =vBoX -----END PGP SIGNATURE----- --Apple-Mail-98--399223538-- From owner-namedroppers@ops.ietf.org Tue Aug 18 16:42: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 DF06C3A67A8; Tue, 18 Aug 2009 16:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 fxt0PTiS1wKR; Tue, 18 Aug 2009 16:42:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A70703A67B4; Tue, 18 Aug 2009 16:42:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdYFq-000Lct-B3 for namedroppers-data0@psg.com; Tue, 18 Aug 2009 23:38:14 +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 1MdYFl-000Lc4-Ir for namedroppers@ops.ietf.org; Tue, 18 Aug 2009 23:38: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 A26C8E609B; Tue, 18 Aug 2009 23:38: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 n7INc5l3005780; Wed, 19 Aug 2009 09:38:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908182338.n7INc5l3005780@drugs.dv.isc.org> To: David Conrad Cc: Nicholas Weaver , IETF DNSEXT WG From: Mark Andrews References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <16045.1250524771@nsa.vix.com> <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> <18326.1250527802@nsa.vix.com> <9CFFA1D9-5E8D-4807-94D0-A444EA21BAB1@virtualized.org> Subject: Re: Cutting to the chase (was Re: [dnsext] EDNS Page Option draft) In-reply-to: Your message of "Tue, 18 Aug 2009 10:37:03 -1000." <9CFFA1D9-5E8D-4807-94D0-A444EA21BAB1@virtualized.org> Date: Wed, 19 Aug 2009 09:38:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <9CFFA1D9-5E8D-4807-94D0-A444EA21BAB1@virtualized.org>, David Conrad writes: > Hi, > > On Aug 17, 2009, at 12:42 PM, Nicholas Weaver wrote: > > Especially since this isn't a problem for most DNS, only DNSSEC. > > > > So what will happen? People turn on DNSSEC, get either failures and > > timeouts and fallbacks to TCP on the resolver end, greatly increased > > load on the authority end, and either the authorities work around > > things by making their responses small, or the resolvers turn off > > DNSSEC. > > > > If we actually want DNSSEC over UDP, we should resign ourselves to > > doing an application-level fragmentation when responses exceed the > > Ethernet MTU. > > > > Because there is now enshrined in the de-facto Internet reality two > > limits: The Ethernet MTU, and devices that can't handle fragments. > > An informal, wildly unscientific survey... > > So, in the relatively near future, the root zone will be signed. > Current plans are to NOT make any special effort to reduce root > response size (see ns.iana.org for a reasonable facsimile for what the > signed root is going to look like). Last I checked, about 70% of the > queries hitting the root had DO=1, with somewhere around 75% of those > queries advertising a buffer size of 4096. > > On the fateful date the root gets signed, what do you think is going > to happen? > > a) there will be much rejoicing > b) no one but a few geeks will notice > c) a percentage of folks will have resolution problems (what > percentage?) > d) some root server instances will fall over from increased load but > no one other than geeks will notice > e) some root server instances will fall over and non-geeks will notice > due to performance degradation > f) something else (what?) > > (combinations of answers are obviously ok) a by b + c (sites that never talk to ORG, SE, BR or any other signed TLDs). f more firewalls will be re-configured to handle large UDP. There will be questions about why my lookups are slow. > Respond publicly or privately to me, I'll summarize the responses. > > Thanks, > -drc > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 18:05: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 5E8A83A6BE0; Tue, 18 Aug 2009 18:05: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=[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 oReiD1Dfr6QE; Tue, 18 Aug 2009 18:05:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 697A73A69C2; Tue, 18 Aug 2009 18:05:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdZWT-0006IN-Nv for namedroppers-data0@psg.com; Wed, 19 Aug 2009 00:59: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 1MdZWP-0006Hl-O3 for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 00:59:27 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5EF83B33C7 for ; Wed, 19 Aug 2009 00:59:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-Reply-To: Your message of "Wed, 19 Aug 2009 08:20:14 +1000." <200908182220.n7IMKEw9004852@drugs.dv.isc.org> References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> <200908182220.n7IMKEw9004852@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 19 Aug 2009 00:59:25 +0000 Message-ID: <95317.1250643565@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Mark Andrews > Date: Wed, 19 Aug 2009 08:20:14 +1000 > > > In general, people will change zilch for DNSSEC ... > > They will for plain DNS. Just put 256 byte MTU link, for DNS UDP > packets, between the roots and the rest of the Internet and the > problem will be gone within a week. ... "first, do no harm." > Firewalls are about "Can I get way with doing this?". You just > need to make the answer "No" and the configuration/implementation > will change. alas, whoever deploys a sloppy implementation earliest and most widely, has the high ground on saying "it's not my fault" when someone comes along later doing the right thing and fails to interoperate. i am reminded of the microsoft NT 3.51 resource kit which had an early version of their DNS software that had a correct implementation of AXFR that BIND4 failed to synch up with due to code bugs on the BIND4 side. we fixed it but we couldn't make the fix the default at first, and though we apologized all over the place, microsoft still took undeserved heat for it. had ISC failed to fix it and failed to apologize, microsoft would have had to break their AXFR code to become compatible with BIND4's broken AXFR code. stupid firewalls who presume datagram atomicity and have gotten away with it for all the years before EDNS0, can thus get away with claiming that the new problem (of not handling fragmented UDP/53) is not their bug. From owner-namedroppers@ops.ietf.org Tue Aug 18 18:37: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 961793A67B2; Tue, 18 Aug 2009 18:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGtsjcF421-p; Tue, 18 Aug 2009 18:37:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81E463A6837; Tue, 18 Aug 2009 18:37:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mda3i-000ARU-AV for namedroppers-data0@psg.com; Wed, 19 Aug 2009 01:33: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 1Mda3Y-000AQT-5x for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 01:33: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 F2F62E60A2; Wed, 19 Aug 2009 01:33: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 n7J1XXNV007382; Wed, 19 Aug 2009 11:33:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908190133.n7J1XXNV007382@drugs.dv.isc.org> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Paul Wouters , bert hubert , namedroppers@ops.ietf.org From: Mark Andrews References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? In-reply-to: Your message of "Wed, 19 Aug 2009 07:33:19 +0800." Date: Wed, 19 Aug 2009 11:33:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , =?ISO-8859-1?Q?Pat rik_F=E4ltstr=F6m?= writes: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > On 19 aug 2009, at 05.56, Paul Wouters wrote: > > > I mean, Cisco still says at www.cisco.com/web/about/security/intelligence/d > ns-bcp.html > > > > DNS message size limitations > > > > DNS amplification and reflection attacks are more effective when > > leveraging large DNS messages than small DNS message sizes. The > > message-length parameters submode command for policy-map type inspect > > dns can be used to ensure that message sizes to not exceed a > > specified > > size thus reducing the efficiency of these attacks. > > > > This feature is available beginning with software release 7.2(1) for > > Cisco ASA and Cisco PIX Firewalls. This feature is available > > beginning > > with software release 3.1 for FWSM Firewalls. This function is > > enabled > > by default with a limit of 512 bytes. > > > > Seriously, if you're still setting "message-length maximum 512" in > > your network, > > you deserve to keep all pieces. > > Note that this is a function in a firewall, and this has nothing to do > with IP fragmentation as this is an inspection of the DNS payload size. > > That said, I agree with you. If one have firewalls set to ensure that > DNS payload MUST be smaller than 512 bytes, and still try to run > DNSSEC (which of course will fail), then one should deserve to loose. > > Note further than the feature you describe is a bit more delicate than > the text above describe. The feature also recognize the ENDS0 > announcement of the response buffer size, so if you send out a request > with EDNS0 size limitation, the firewall inspects the size of the > response that it is not larger than what you announced. So the text > you sent is regarding non-EDNS0 tagged packets. But in reality the > algorithm used is even more complicated, so people that want to know > how this inspection works should read the full documentation. > > Patrik Wouldn't make more sense to fix that documentation to say something like: by default with a limit of 512 bytes for plain DNS. EDNS request packets are inspected to see what the EDNS UDP size is and the responses are examined to ensure that they conform. We would then have a club to beat up other firewall vendors with by saying "CISCO can do this so you should be able to do this as well" and point them at your page. We would also have a page we can point to which gives the minimum version CISCO customers need to be running which is compatible with DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 19:06: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 ED5813A688C; Tue, 18 Aug 2009 19:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 zS4I+zQY88Ma; Tue, 18 Aug 2009 19:06:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4CA93A67B2; Tue, 18 Aug 2009 19:06:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdaVY-000E2y-4B for namedroppers-data0@psg.com; Wed, 19 Aug 2009 02:02: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 1MdaVT-000E2P-Gd for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 02:02: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 4724EE609B; Wed, 19 Aug 2009 02:02:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7J22PdU007627; Wed, 19 Aug 2009 12:02:26 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908190202.n7J22PdU007627@drugs.dv.isc.org> To: bert hubert Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow In-reply-to: Your message of "Tue, 18 Aug 2009 23:54:41 +0200." <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> Date: Wed, 19 Aug 2009 12:02:25 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com>, bert hubert writes: > On Tue, Aug 18, 2009 at 11:12 PM, Andrew Sullivan wrote: > > No hat. > > I think that's true. =A0The important question to ask, for deployment > > purposes (and I suggest the answer to this belongs on another list), > > is what "it breaks" means. > > Perhaps - but from the 'theoretical side', we should be aware of what > we have wrought. > Oddly enough, some very common (.gov) responses are fragmented right > now, and we don't see issues. > > The two biggest typical DNSSEC responses appear to be: > > 1) the one with the DNSKEY (that could, btw, travel safely over TCP, > since it should be none too frequent, and the validating resolver > *knows* it might be a whopper). This includes 'ANY' queries, which > could well return DNSKEY. .GOV has this one at 1166 bytes, .ORG at > 1723 and .SE at 4 kilobytes. > > 2) an NSEC3 NXDOMAIN (which comes in unexpectedly) > > Response 1 is the least scary, since it should only be performed by > people that have actively turned on DNSSEC validation, or who are > doing relatively rare ANY queries. If you can't deal with the (huge) > size of this response, your normal DNS will work, but nothing will > validate. > > Response '2' hits all recent BINDs that in their pioneering wisdom > decided to set do=1 on outgoing queries. Well the bit does say "DNSSEC records are OK" and that is true for all versions of named. > If that one gets too big, all > BIND users will instantly have a problem. I actually & honestly do > think ISC did us a service setting do=1 by default btw. Better suffer > now than discover a problem later. > > Impact > ---------- > Response 1 is the biggest, but only impacts 'DNSSEC pioneers', and > they could move to TCP for this query. > > Response 2 appears to be relatively harmless, and I don't understand > why. Almost all .GOV do=1 NXDOMAIN answers are fragmented right now. > And I don't hear people complaining, so there may be some hope yet. > > Nicholas, any ideas? Or is BIND being really smart with fallback? Are > any of the .GOV people at liberty to share their experiences? Named just falls back to something that works. It tries EDNS@4096. If that fails (times out), it tries EDNS@512. If that fails (times out) it does plain DNS. If any of the responses sets TC then named will retry the query using TCP, using the EDNS state learnt by the UDP queries, before returning the response to the client. Note we were overly aggressive in the EDNS fallback and if you want DNSSEC validation to work reliably in the presence DNS/UDP breaking middleware you need this bug fix. 2564. [bug] Only take EDNS fallback steps when processing timeouts. [RT #19405] If you are not validating then you don't notice this problem. People who validate tend to also keep their nameservers current so this is not a real problem. By the time DNSSEC becomes general most vendors should have picked up fixed version of BIND. Mark > Response '2' might still very well kill DNSSEC for a significant > percentage of people *or zones*, which would lead to the > aforementioned 'I turned it on and stuff broke' behaviour. This pain > will be borne whenever someone DNSSEC signs his zone, and someone > behind a validating resolver (with a trust anchor) tries to access > that zone. > > 23:43:30.421519 IP 10.0.1.47.58971 > 76.74.254.208.53: 56855+ [1au] A? > www.c1a.gov. (40) > 23:43:30.590564 IP 76.74.254.208.53 > 10.0.1.47.58971: 56855 > NXDomain*- 0/8/1 (1472) > 23:43:30.590624 IP 76.74.254.208 > 10.0.1.47: udp > ;; MSG SIZE rcvd: 1503 > > Bert -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gaynessw@rishton66.fsnet.co.uk Tue Aug 18 22:00: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 C16CD3A686D; Tue, 18 Aug 2009 22:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.102 X-Spam-Level: X-Spam-Status: No, score=-18.102 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, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 uYKLr6oYBmJp; Tue, 18 Aug 2009 22:00:37 -0700 (PDT) Received: from bzq-84-108-154-5.cablep.bezeqint.net (bzq-84-108-154-5.cablep.bezeqint.net [84.108.154.5]) by core3.amsl.com (Postfix) with ESMTP id 26CEB3A6C06; Tue, 18 Aug 2009 22:00:31 -0700 (PDT) Received: from 84.108.154.5 by rishton66.fsnet.co.uk; Wed, 19 Aug 2009 07:00:18 +0200 Message-ID: <000d01ca2089$f25956b0$6400a8c0@gaynessw> From: Adolph Shaver To: Subject: total physicak renewal with the acai berry, try it free today Date: Wed, 19 Aug 2009 07:00:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2089.F25956B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA2089.F25956B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 Can't see=20 this email? VIEW IN BROWSER =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Threat Information and=20 Product News for Customers =20 =20 =20 =20 =20 =20 =20 =20 =20 In this Issue: =20   =20 =20 Product=20 NewsAcai Berry fights Cancer , Increases ener= gy and burns fat.=20 =A0 A chance to visit =20 =20 =20 =20 =20 We appreciate your interest in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to = our mailing=20 list. =20 =20 =A0 =20 Copyright=20 2009 Osndc, Incorporated. All rights reserved. All other product=20 orcompany names may be trademarks or registered trademarks of their=20 owners. =A0 ------=_NextPart_000_0007_01CA2089.F25956B0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ca= n't see=20 this email? VIEW IN BROWSER
=
Threat Information an= d=20 Product News for Customers
In this Issue:<= /TD>
 
Product=20 News

Acai Berry fights Cancer , Inc= reases energy and burns fat.
=A0
A chance to visit
=
We appreciate your inter= est in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please = opt-in to our mailing=20 list.
=A0
Copyright=20 2009 Osndc, Incorporated. All rights reserved. All other product=20 or
company names may be trademarks or registered trademarks of the= ir=20 owners.
=A0
------=_NextPart_000_0007_01CA2089.F25956B0-- From startle73@matrixbcp.com Tue Aug 18 22:01: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 6C0863A6BC3 for ; Tue, 18 Aug 2009 22:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.279 X-Spam-Level: X-Spam-Status: No, score=-17.279 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, 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_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 94TLWKKMe+SM for ; Tue, 18 Aug 2009 22:01:38 -0700 (PDT) Received: from bzq-84-109-23-177.red.bezeqint.net (bzq-84-109-23-177.red.bezeqint.net [84.109.23.177]) by core3.amsl.com (Postfix) with ESMTP id 0BE263A6AF9 for ; Tue, 18 Aug 2009 22:01:37 -0700 (PDT) Received: from 84.109.23.177 by matrixbcp.com; Wed, 19 Aug 2009 08:01:39 +0200 Message-ID: <000d01ca208a$2310f510$6400a8c0@startle73> From: Marcelo Mcintyre To: Subject: Lose Weight without moving a muscle Date: Wed, 19 Aug 2009 08:01:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA208A.2310F510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA208A.2310F510 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 Can't see=20 this email? VIEW IN BROWSER =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Threat Information and=20 Product News for Customers =20 =20 =20 =20 =20 =20 =20 =20 =20 In this Issue: =20   =20 =20 Product=20 NewsGet More Self Confidence by losing weight =A0 Click =20 =20 =20 =20 =20 We appreciate your interest in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to = our mailing=20 list. =20 =20 =A0 =20 Copyright=20 2009 Ophsb, Incorporated. All rights reserved. All other product=20 orcompany names may be trademarks or registered trademarks of their=20 owners. =A0 ------=_NextPart_000_0007_01CA208A.2310F510 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ca= n't see=20 this email? VIEW IN BROWSER

=
Threat Information an= d=20 Product News for Customers
In this Issue:<= /TD>
 
Product=20 News

Get More Self Confidence by lo= sing weight
=A0
Click
We appreciate your inter= est in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please = opt-in to our mailing=20 list.
=A0
Copyright=20 2009 Ophsb, Incorporated. All rights reserved. All other product=20 or
company names may be trademarks or registered trademarks of the= ir=20 owners.
=A0
------=_NextPart_000_0007_01CA208A.2310F510-- From owner-namedroppers@ops.ietf.org Tue Aug 18 22:23: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 3554C3A6A1F; Tue, 18 Aug 2009 22:23:38 -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 4ml4wNkguWgV; Tue, 18 Aug 2009 22:23:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE1253A6861; Tue, 18 Aug 2009 22:23:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MddYS-000Ej3-7A for namedroppers-data0@psg.com; Wed, 19 Aug 2009 05:17:48 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MddYO-000EiT-NI for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 05:17:46 +0000 Received: (qmail 17769 invoked by uid 399); 19 Aug 2009 05:17:40 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Aug 2009 05:17:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A8B8AEE.1040105@dougbarton.us> Date: Tue, 18 Aug 2009 22:17:34 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: bert hubert CC: Paul Wouters , namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> In-Reply-To: <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: bert hubert wrote: > This, however, is not the point; we are not dealing with a 'clean > network'. We are dealing with a network ('The Internet') that saw a > 600-fold increase in TCP traffic, which should not have happened. I asked in passing for references to this claim, now I'm asking directly. Doug From owner-namedroppers@ops.ietf.org Tue Aug 18 22:50:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF493A67F7; Tue, 18 Aug 2009 22:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 ZbGj+Cw1SRLK; Tue, 18 Aug 2009 22:50:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 101173A699C; Tue, 18 Aug 2009 22:50:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mde0S-000IHQ-5e for namedroppers-data0@psg.com; Wed, 19 Aug 2009 05:46:44 +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 1Mde0N-000IGg-Ni for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 05:46: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 DD192E60A0; Wed, 19 Aug 2009 05:46: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 n7J5kZJr009870; Wed, 19 Aug 2009 15:46:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908190546.n7J5kZJr009870@drugs.dv.isc.org> To: Doug Barton Cc: bert hubert , Paul Wouters , namedroppers@ops.ietf.org From: Mark Andrews References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow In-reply-to: Your message of "Tue, 18 Aug 2009 22:17:34 MST." <4A8B8AEE.1040105@dougbarton.us> Date: Wed, 19 Aug 2009 15:46:35 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A8B8AEE.1040105@dougbarton.us>, Doug Barton writes: > bert hubert wrote: > > > This, however, is not the point; we are not dealing with a 'clean > > network'. We are dealing with a network ('The Internet') that saw a > > 600-fold increase in TCP traffic, which should not have happened. > > I asked in passing for references to this claim, now I'm asking directly. > > Doug The traffic went from .1 connects/second to 60 connections/second compared to 6000 UDP requests/second. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 23:33: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 0F9873A69DA; Tue, 18 Aug 2009 23:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuPGjAiYBlrn; Tue, 18 Aug 2009 23:33:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46B633A684B; Tue, 18 Aug 2009 23:33:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdeeH-000NL9-EK for namedroppers-data0@psg.com; Wed, 19 Aug 2009 06:27:53 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdeeD-000NKR-Lj for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 06:27:51 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 60D8FC2DA5; Wed, 19 Aug 2009 07:27:45 +0100 (BST) Date: Wed, 19 Aug 2009 07:28:06 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: Paul Wouters , bert hubert , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: <27F2BEA58E05F96EAA1C45C9@nimrod.local> In-Reply-To: <200908190133.n7J1XXNV007382@drugs.dv.isc.org> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> <200908190133.n7J1XXNV007382@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 19 August 2009 11:33:33 +1000 Mark Andrews wrote: > Wouldn't make more sense to fix that documentation to say > something like: > > by default with a limit of 512 bytes for plain DNS. EDNS > request packets are inspected to see what the EDNS UDP size > is and the responses are examined to ensure that they conform. That would be lovely, and might be an accurate description of what it does now. However, it does not appear to be an accurate description of what the feature did when first introduced, judging by a lot of postings to the net by people who claim it broke EDNS queries beyond 512. Of course, a page saying Cisco fixed it would be even better. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 18 23:51: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 54BD33A6C34; Tue, 18 Aug 2009 23:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-89m823CgFT; Tue, 18 Aug 2009 23:51:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75F563A6802; Tue, 18 Aug 2009 23:51:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdexy-000PtX-Mw for namedroppers-data0@psg.com; Wed, 19 Aug 2009 06:48:14 +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 1Mdexu-000Ps3-8R for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 06:48: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 53D09E609D; Wed, 19 Aug 2009 06:48:09 +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 n7J6m6GQ010602; Wed, 19 Aug 2009 16:48:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908190648.n7J6m6GQ010602@drugs.dv.isc.org> Cc: Doug Barton , bert hubert , Paul Wouters , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow In-reply-to: Your message of "Wed, 19 Aug 2009 15:46:35 +1000." Date: Wed, 19 Aug 2009 16:48:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark Andrews writes: > > In message <4A8B8AEE.1040105@dougbarton.us>, Doug Barton writes: > > bert hubert wrote: > > > > > This, however, is not the point; we are not dealing with a 'clean > > > network'. We are dealing with a network ('The Internet') that saw a > > > 600-fold increase in TCP traffic, which should not have happened. > > > > I asked in passing for references to this claim, now I'm asking directly. > > > > Doug > > The traffic went from .1 connects/second to 60 connections/second compared > to 6000 UDP requests/second. http://www.nanog.org/meetings/nanog46/presentations/Wednesday/wessels_light_N46.pdf > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 18 23:53: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 1DD1A3A6BB9; Tue, 18 Aug 2009 23:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[AWL=0.079, 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 77wwlNe-OwDE; Tue, 18 Aug 2009 23:53:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 435C93A6802; Tue, 18 Aug 2009 23:53:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdewr-000PjZ-TY for namedroppers-data0@psg.com; Wed, 19 Aug 2009 06:47:05 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdewm-000Pj0-0p for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 06:47:03 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id A9645C2DA5; Wed, 19 Aug 2009 07:46:57 +0100 (BST) Date: Wed, 19 Aug 2009 07:47:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver , bert hubert cc: Nicholas Weaver , Paul Hoffman , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: <040E702977D60A28476FD02D@nimrod.local> In-Reply-To: <153FF894-FE98-42DD-9943-4BD2CC37C02C@ICSI.Berkeley.EDU> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> <153FF894-FE98-42DD-9943-4BD2CC37C02C@ICSI.Berkeley.EDU> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 18 August 2009 14:25:10 -0700 Nicholas Weaver wrote: > Somewhat confident but NOT completely. > > Its enough to say "There is a potential problem here", the relative root > causes of the problem (fragments vs DNS<=512B assumptions: fragments > appear to be the big problem for recursive resolvers, and about 2/3rds > for the end-host systems), but not exactly the scale of the problem: the > error bars could be huge. > > Simply because the Netalyzr run is an incredibly biased and > self-selecting data-set. Eg, how it got slashdotted caused ~10%+ of the > tests to be from Comcast IPs! We've identified some other biases as > well, and who knows how many biases exist that we don't know about. OK, so I ran netalyzer from my OS-X laptop. It is running with a separate DNS server discovered through DHCP (modern-ish BIND), behind a cruftily configured Cisco router as a firewall & NAT. The BIND server (Linux box) receives no special treatment on the firewall. This is one of your data points that is unable to receive fragments. However, I have no DNS problems I know about (certainly not receiving NXDOMAIN from .se). It claims that "Large DNS requests are blocked. Grr" (in the log). I don't believe this is actually the case. Is there a simple CLI utility to test this? It also claims: 052.539 test-22| Now checking for a bogus (non-DNS) packet on port 53 052.540 test-22| UDP socket at 192.168.100.80:53561 052.548 test-22| Got exception java.net.SocketException: Network is unreachable on UDP test 052.549 test-22| Bogus ping packet not received by the applet 052.549 test-22| now checking again with a real DNS packet 052.550 test-22| UDP socket at 192.168.100.80:53562 052.648 test-22| Got datagram of 212 bytes. 052.650 test-22| Legitimate DNS packet succeeded. And hence malformed DNS packets are being dropped. I am about 99% sure that it's not the path out doing this. It's either Java or some internal OS-X firewall prevent user applications from constructing their own invalid DNS packets. My concern is that Netalyzer may be reporting problems where there are in fact none. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 19 00: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 4183528C34B; Wed, 19 Aug 2009 00:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.184, 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 pFj2NtPA8HcZ; Wed, 19 Aug 2009 00:37:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31E3728C0EE; Wed, 19 Aug 2009 00:37:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdfef-00067G-8E for namedroppers-data0@psg.com; Wed, 19 Aug 2009 07:32:21 +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 1Mdfea-00065h-Kb for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 07:32:19 +0000 Received: from miffy.fritz.box ([IPv6:2001:980:2045:0:21b:63ff:fec4:a963]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n7J7VDuH038723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 09:32:00 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response Mime-Version: 1.0 (Apple Message framework v1074) Content-Type: multipart/signed; boundary=Apple-Mail-3--370554377; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> Date: Wed, 19 Aug 2009 09:31:08 +0200 Cc: Mark Andrews , William Allen Simpson , namedroppers@ops.ietf.org Message-Id: <80499EB4-0E9F-4F4D-BA49-3A978729E400@NLnetLabs.nl> References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> To: bert hubert X-Mailer: Apple Mail (2.1074) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 19 Aug 2009 09:32:06 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-3--370554377 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 18 aug 2009, at 17:36, bert hubert wrote: > [reduce size by a query for] RRSIG DO=1 Except that you get all the RRSIGS, for each RR type, that live with that owner name. When querying for the RRSIGs at the owner name of the DNSKEY that is likely to be the RRSIG over the DNSKEY, the NSEC, the SOA, the NS, and possibly A and AAAA. --Olaf --Apple-Mail-3--370554377 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODE5MDczMTA5WjAj BgkqhkiG9w0BCQQxFgQUOk0RH7YKgiDGzVIzt44hW9ijmoowgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBADR6ORCKflC6MUzj4Fvhvx32V7hvwbfSMuOZvZct3U4HfsfK9u+nvk1yCKagCD8/ i9ixRMSb+Ek6yEK1N2VTprqHGo+ENZ2DFZ6uoM5aUs6QjxqzYIfXIV8smR113q0R1DHQuInA/PHB RsRI2fsYVpLTEZ64vA8MWcAa1zNniar6W/k+rxR2m4xv0gX/6YsmZltz8bDTbwwl064zS6HJ4f2Z EjqhqrZSm8XLWllwnSURqgM4WldlFTnqkyn4Uuj3/1uErPUKx3aSvILWQ6+S6X3gtu+kxZ+mylPN j+n9P1knTAMMUFydLm8igJr759Gp/NDin5HJmLF3o678lyYkf+4AAAAAAAA= --Apple-Mail-3--370554377-- From owner-namedroppers@ops.ietf.org Wed Aug 19 02:40: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 DFEB23A682D; Wed, 19 Aug 2009 02:40:23 -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 f+3S8DDbMvbO; Wed, 19 Aug 2009 02:40:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E35C3A6AEE; Wed, 19 Aug 2009 02:40:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdhYU-000Lgh-2p for namedroppers-data0@psg.com; Wed, 19 Aug 2009 09:34:06 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febe:116e] (helo=out-61.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdhYP-000Lg6-8K for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 09:34:03 +0000 Received: from smtp-12.smtp.ucla.edu (smtp-12.smtp.ucla.edu [169.232.46.245]) by out-61.smtp.ucla.edu with ESMTP id n7J9Xf6P032230; Wed, 19 Aug 2009 02:33:46 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.145]) by smtp-12.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7J9Xf6P032230; Wed, 19 Aug 2009 02:33:41 -0700 Received: from [172.16.249.151] (190.Red-81-36-154.dynamicIP.rima-tde.net [81.36.154.190]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7J9XWIF020032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 02:33:36 -0700 Cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: <3594CDD0-09C8-4D14-B526-DF63C07B6CBD@cs.ucla.edu> From: Eric Osterweil To: Doug Barton In-Reply-To: <4A8AF614.1040107@dougbarton.us> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-78--363211594" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option draft Date: Wed, 19 Aug 2009 11:33:31 +0200 References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <06A65CB0596049F7A085A8C45494823F@localhost> <1931B8FB0122AC8BDEF52618@Ximines.local> <2E4F4ECB-43B9-4948-816F-289E5C15454A@icsi.berkeley.edu> <4431D05BC3A4E329EF9EA39C@nimrod.local> <200908180113.n7I1D0hX093912@drugs.dv.isc.org> <4A8AF614.1040107@dougbarton.us> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.245 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-78--363211594 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 18, 2009, at 8:42 PM, Doug Barton wrote: > Ray.Bellis@nominet.org.uk wrote: >> >>> draft-ietf-dnsext-dnsproxy need a MUST NOT advertise a EDNS UDP >>> size it is incapable of returning to the client. >> >> Well, not really. It already points out that it behoves the client =20= >> to >> set their own EDNS0 buffer size in accordance with their MTU, with =20= >> the >> implication that the client should also take the proxy's "buffer MTU" >> into account. > > This leads naturally into a thought that has been percolating in my > brain throughout these fragmentation threads. It would be really nice > if there were a command-line tool that admins could use to test this > (where "this" is "what is my largest possible unfragmented UDP > packet?"). Then at least admins who had sufficient clue to use the > tool could set up there name servers appropriate and/or work to find > the cause of things not being what they think they should be. Try dnsfunnel: http://www.vantage-points.org/download.html It's bundled w/ our DNSSEC suite. We announced this at IETF 75 and it =20= will find the exact size of messages that fit over the path from =20 nameservers to you: $ dnsfunnel questsys.com 208.67.177.139 4096B 0.291743 208.67.177.139 2304B 0.268944 208.67.177.139 1408B 0.326089 (truncated) 208.67.177.139 1856B 0.245980 (truncated) 208.67.177.139 2080B 0.234383 208.67.177.139 1968B 0.215011 (truncated) 208.67.177.139 2024B 0.269964 208.67.177.139 1996B 0.217236 208.67.177.139 1982B 0.214775 208.67.177.139 1975B 0.215307 (truncated) 208.67.177.139 1978B 0.227221 (truncated) 208.67.177.139 1980B 0.216392 (truncated) 208.67.177.139 1981B 0.216609 208.67.177.139 1980B 0.217926 (truncated) 208.67.177.139 4096B 0.216612 --------------------------------- 208.67.177.8 4096B * * * 208.67.177.8 2304B * * * 208.67.177.8 1408B * * * 208.67.177.8 960B 0.233100 (truncated) ... 208.67.177.7 1252B 0.214902 (truncated) --------------------------------- PMTU walking summary: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name Server Keys Small Largest Optimal IP fit? Buffer Buffer Buffer ------------------------------------------------ 208.67.177.139 yes 1981 4096 1981 208.67.177.8 no 1252 0 0 208.67.177.138 yes 1981 4096 1981 208.67.177.7 no 1252 0 0 Eric =E9 --Apple-Mail-78--363211594 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 v2.0.9 (Darwin) iEYEARECAAYFAkqLxusACgkQK/tq6CJjZQLUvwCdEwZKvfUMfPlLIa5ToHy91sVT MAkAn2v3+DpyQ+cWoldVhSbGRA/Hqp2Q =9MvK -----END PGP SIGNATURE----- --Apple-Mail-78--363211594-- From owner-namedroppers@ops.ietf.org Wed Aug 19 05:45: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 160F53A6AFB; Wed, 19 Aug 2009 05:45:00 -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.032, 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 mXKDrM+mPKrm; Wed, 19 Aug 2009 05:44:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8126B3A680D; Wed, 19 Aug 2009 05:44:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdkQl-000L5V-3L for namedroppers-data0@psg.com; Wed, 19 Aug 2009 12:38:19 +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 1MdkQg-000L4a-Jv for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 12:38:17 +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 n7JCc6au005708; Wed, 19 Aug 2009 05:38:06 -0700 (PDT) Cc: Nicholas Weaver , bert hubert , Paul Hoffman , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Alex Bligh In-Reply-To: <040E702977D60A28476FD02D@nimrod.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Wed, 19 Aug 2009 05:38:07 -0700 References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> <153FF894-FE98-42DD-9943-4BD2CC37C02C@ICSI.Berkeley.EDU> <040E702977D60A28476FD02D@nimrod.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 18, 2009, at 11:47 PM, Alex Bligh wrote: > > > --On 18 August 2009 14:25:10 -0700 Nicholas Weaver > wrote: > >> Somewhat confident but NOT completely. >> >> Its enough to say "There is a potential problem here", the relative >> root >> causes of the problem (fragments vs DNS<=512B assumptions: fragments >> appear to be the big problem for recursive resolvers, and about >> 2/3rds >> for the end-host systems), but not exactly the scale of the >> problem: the >> error bars could be huge. >> >> Simply because the Netalyzr run is an incredibly biased and >> self-selecting data-set. Eg, how it got slashdotted caused ~10%+ >> of the >> tests to be from Comcast IPs! We've identified some other biases as >> well, and who knows how many biases exist that we don't know about. > > OK, so I ran netalyzer from my OS-X laptop. It is running with a > separate > DNS server discovered through DHCP (modern-ish BIND), behind a > cruftily > configured Cisco router as a firewall & NAT. The BIND server (Linux > box) receives no special treatment on the firewall. > > This is one of your data points that is unable to receive fragments. > However, I have no DNS problems I know about (certainly not receiving > NXDOMAIN from .se). Does the RESOLVER get large responses OK? Or is it just your host? Remember, we test both of those separately. > It claims that "Large DNS requests are blocked. Grr" (in the log). I > don't believe this is actually the case. Is there a simple CLI utility > to test this? dig +norecurse +dnssec edns_large.netalyzr.icsi.berkeley.edu @n1.netalyzr.icsi.berkeley.edu dig +norecurse +dnssec edns_medium.netalyzr.icsi.berkeley.edu @n1.netalyzr.icsi.berkeley.edu dig +norecurse +dnssec edns_small.netalyzr.icsi.berkeley.edu @n1.netalyzr.icsi.berkeley.edu are the manually constructed requests: its a direct UDP raw packet equivelent to the dig request (in fact, thats how I generated it, I just used dig and captured the packet, easier than finding a Java DNS lib I liked). The responses should have a large number of irrelevant CNAMEs to pad out the packet. > It also claims: > > 052.539 test-22| Now checking for a bogus (non-DNS) packet on port 53 > 052.540 test-22| UDP socket at 192.168.100.80:53561 > 052.548 test-22| Got exception java.net.SocketException: Network is > unreachable on UDP test > 052.549 test-22| Bogus ping packet not received by the applet > 052.549 test-22| now checking again with a real DNS packet > 052.550 test-22| UDP socket at 192.168.100.80:53562 > 052.648 test-22| Got datagram of 212 bytes. > 052.650 test-22| Legitimate DNS packet succeeded. > > And hence malformed DNS packets are being dropped. I am about 99% sure > that it's not the path out doing this. It's either Java or some > internal > OS-X firewall prevent user applications from constructing their own > invalid DNS packets. The default Java and OS-X will, just fine, send that bogus packet, under both firefox and safari. Could you send me the link to the results page/transcript so I can see if there is a different JVM version? What other security software are you using? Also, many firewalls (you mentioned this as being behind a crufty Cisco, is it effectively local network?) WILL block the bogus request, and I suspect if it actually gives an ICMP back rather than just silently dropping, Java will get that exception. Can you try a simple dumb raw UDP request to that port and see what you get back? > My concern is that Netalyzer may be reporting problems where there > are in fact none. > > -- > Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 19 08: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 D69243A6CEA; Wed, 19 Aug 2009 08:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.776, 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 kPRLGasG681a; Wed, 19 Aug 2009 08:24:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C62193A67D3; Wed, 19 Aug 2009 08:24:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdmxh-000JOF-5m for namedroppers-data0@psg.com; Wed, 19 Aug 2009 15:20: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 1Mdmwm-000JFf-2Y for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 15:19:52 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7JFJVX0008006 for ; Wed, 19 Aug 2009 11:19:31 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n7JFJV3I008005 for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 11:19:31 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:a18:1::62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mde6S-000J98-0S for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 05:52:57 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A2CE210A96; Wed, 19 Aug 2009 07:48:44 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 819F910A82; Wed, 19 Aug 2009 07:48:44 +0200 (CEST) Message-ID: <4A8B9336.9080200@restena.lu> Date: Wed, 19 Aug 2009 07:52:54 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org CC: Nicholas Weaver Subject: [dnsext] Re: What ELSE relies on UDP fragmentation? X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Hello, (not subscribed to this list, sorry for breaking threading) > Can anyone identify a major application other than DNSSEC which uses UDP and assumes that packets greater than the Ethernet MTU can be sent and will be properly fragmented and reassembled on traffic traversing the Internet? one other protocol that relies on IP fragmentation for UDP packets working is RADIUS. The maximum datagram size for RADIUS packets is 4k, and it can not be split into multiple datagrams. Whether or not you call RADIUS "major" or not is your own choice :-) In day-to-day deployment, we (eduroam, a large wireless LAN roaming consortium) have hit the ~ 1500 MTU barrier repeatedly when using authentication payloads which transfer large amounts of data (EAP-TLS, most notably, which sends X.509 certificates bidirectionally in RADIUS datagrams). I'm following this thread here with some interest - the hint that most OSes set the DF bit on every outgoing datagram for example is important news for us (as it ruins the party for many EAP-TLS wireless users world-wide). Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From owner-namedroppers@ops.ietf.org Wed Aug 19 10:39: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 86A4A3A6C75; Wed, 19 Aug 2009 10:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33oVZ7QKWeB4; Wed, 19 Aug 2009 10:39:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B49D28C0D6; Wed, 19 Aug 2009 10:38:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdp2b-000DWn-WC for namedroppers-data0@psg.com; Wed, 19 Aug 2009 17:33:42 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdp2R-000DFH-LF for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 17:33:39 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n7JHUQ8X029380; Wed, 19 Aug 2009 17:30:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7JHUQeq029379; Wed, 19 Aug 2009 17:30:26 GMT Date: Wed, 19 Aug 2009 17:30:26 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: William Allen Simpson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response Message-ID: <20090819173026.GA29179@vacation.karoshi.com.> References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Aug 19, 2009 at 12:52:29AM +1000, Mark Andrews wrote: > > In message <4A8A9F8D.4030009@gmail.com>, William Allen Simpson writes: > > bert hubert wrote: > > > On Mon, Aug 17, 2009 at 2:28 PM, William Allen > > > Simpson wrote: > > >> I'm having trouble counting the number of actual likely bytes in > > >> NXDOMAIN with DNSsec. It seems to me that the result will never > > >> fit within 512 bytes? (Assuming SOA, NS, glue, etc.) I'm currently > > >> getting 1022 bytes with SOA alone, but there's several RRSIGs. > > > > > > This is the sad NSEC3 truth, even with 1024 bit keys, SHA-1 DS and > > > SHA-1 signatures. There are 3 NSEC3's needed mostly, and they all have > > > an RRSIG. And they are not getting any smaller. > > > > > OK. I'm especially concerned for NXDOMAIN, as the last measurements I've > > seen say they're likely a minimum of 12% of the queries. > > > > Add key rollover to larger signatures (2 sets of RRSIGs), and we're always > > looking at more than 1024 bytes, maybe more than 1400 bytes. Anybody have > > exact data? > > You need to learn how to manage keys so there isn't two sets of > signatures. The DNSKEY response will have multiple signature but > the rest of the responses don't need them. surely this is a policy choice, not a protocol choice. > Basically you add a new DNSKEY to the DNSKEY RRset before you start > signing with it. Wait until the on DNSKEY RRset has timed out of > caches. You then stop signing changes with the old key and start > signing changes with the new key. Once all the data signed with > the old DNSKEY has timed out of caches you can remove the old DNSKEY. thats a fine way to manage a scheduled keyrollover. not sure that will work for an unscheduled keyroll. --bill > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 19 10:39: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 016B128C0EC; Wed, 19 Aug 2009 10:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3LlPKHcmAa5; Wed, 19 Aug 2009 10:39:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A21943A6EA2; Wed, 19 Aug 2009 10:39:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdp4C-000DmY-Rl for namedroppers-data0@psg.com; Wed, 19 Aug 2009 17:35:20 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdp47-000DXk-Jd for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 17:35: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 n7JHXi8X029408; Wed, 19 Aug 2009 17:33:44 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7JHXYVV029406; Wed, 19 Aug 2009 17:33:34 GMT Date: Wed, 19 Aug 2009 17:33:34 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Nicholas Weaver , IETF DNSEXT WG Subject: Re: Cutting to the chase (was Re: [dnsext] EDNS Page Option draft) Message-ID: <20090819173334.GB29179@vacation.karoshi.com.> References: <5722A99A87EA478BAC81D71ED194B500@localhost> <4A8916FA.8050302@nlnetlabs.nl> <16045.1250524771@nsa.vix.com> <7EE5EA46-35DC-4684-BA4A-0D86F188938F@icsi.berkeley.edu> <18326.1250527802@nsa.vix.com> <9CFFA1D9-5E8D-4807-94D0-A444EA21BAB1@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CFFA1D9-5E8D-4807-94D0-A444EA21BAB1@virtualized.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 18, 2009 at 10:37:03AM -1000, David Conrad wrote: > > An informal, wildly unscientific survey... > > So, in the relatively near future, the root zone will be signed. > Current plans are to NOT make any special effort to reduce root > response size (see ns.iana.org for a reasonable facsimile for what the > signed root is going to look like). Last I checked, about 70% of the > queries hitting the root had DO=1, with somewhere around 75% of those > queries advertising a buffer size of 4096. > > On the fateful date the root gets signed, what do you think is going > to happen? > > a) there will be much rejoicing > b) no one but a few geeks will notice > c) a percentage of folks will have resolution problems (what > percentage?) > d) some root server instances will fall over from increased load but > no one other than geeks will notice > e) some root server instances will fall over and non-geeks will notice > due to performance degradation > f) something else (what?) > > (combinations of answers are obviously ok) > > Respond publicly or privately to me, I'll summarize the responses. > > Thanks, > -drc > a-e will occur. maybe f. a handful of us are currently running studies to get percentages. --bill From owner-namedroppers@ops.ietf.org Wed Aug 19 13:09:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C0A3A69DE; Wed, 19 Aug 2009 13:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+IvaRNoSjmw; Wed, 19 Aug 2009 13:09:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D13D83A6C08; Wed, 19 Aug 2009 13:09:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdrNo-000Fpe-VL for namedroppers-data0@psg.com; Wed, 19 Aug 2009 20:03:44 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdrNk-000Fos-4A for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 20:03:41 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B8D5CC2DA3; Wed, 19 Aug 2009 21:03:35 +0100 (BST) Date: Wed, 19 Aug 2009 21:03:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , Nicholas Weaver , bert hubert cc: Nicholas Weaver , Paul Hoffman , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Message-ID: In-Reply-To: <040E702977D60A28476FD02D@nimrod.local> References: <853147D1-4DE1-4312-A4E3-D9FC971032AD@ICSI.Berkeley.EDU> <3efd34cc0908180911v654e77b6i95c2e502a1fd5125@mail.gmail.com> <3efd34cc0908181244h2039c814v745eaa161e219e04@mail.gmail.com> <3efd34cc0908181345u14861163x5217327c10088af9@mail.gmail.com> <153FF894-FE98-42DD-9943-4BD2CC37C02C@ICSI.Berkeley.EDU> <040E702977D60A28476FD02D@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 19 August 2009 07:47:17 +0100 Alex Bligh wrote: > My concern is that Netalyzr may be reporting problems where there > are in fact none. This turns out to be that Cisco NAT silently does even more bizarre things with DNS packets than one might have thought. Netalyzr is working just fine. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 19 13:44: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 43E5128C10C; Wed, 19 Aug 2009 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.079 X-Spam-Level: X-Spam-Status: No, score=-5.079 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 NbVNn-cATLmu; Wed, 19 Aug 2009 13:44:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 484D93A6D81; Wed, 19 Aug 2009 13:44:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdrvr-000LT9-QQ for namedroppers-data0@psg.com; Wed, 19 Aug 2009 20:38:55 +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 1Mdrvn-000LSN-F8 for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 20:38: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 n7JKcnns027343; Wed, 19 Aug 2009 13:38:49 -0700 (PDT) Cc: "namedroppers@ops.ietf.org WG" , Nicholas Weaver Message-Id: From: Nicholas Weaver To: Dean Anderson In-Reply-To: <9993DAE7-65AC-4FDD-876B-95F796956044@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? Date: Wed, 19 Aug 2009 13:38:49 -0700 References: <9993DAE7-65AC-4FDD-876B-95F796956044@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 19, 2009, at 11:20 AM, Dean Anderson wrote: >> >> Because people are realizing in the DNSSEC community (like IKE did) >> that you can't rely on UDP fragmentation to work in a non-trivial >> (~10% >> +) of the cases when we actually measure things. > > I was unaware that IKE was having problems with UDP fragmentation. IKE > is a widely deployed protocol. Is there some documentation of this > claim? From this very thread: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02069.html From the referred RFC 3723 section 5.6: > When certificate authentication is used, IKE fragmentation can be > encountered. This can occur when certificate chains are used, or > even when exchanging a single certificate if the key size or size of > other certificate fields (such as the distinguished name and other > OIDs) is large enough. Many Network Address Translators (NATs) and > firewalls do not handle fragments properly, dropping them on inbound > and/or outbound. > > Routers in the path will also frequently discard fragments after the > initial one, since they typically will not contain full IP headers > that can be compared against an Access List. > > As a result, where IKE fragmentation occurs, the endpoints will > often > be unable to establish an IPsec security association. The solution > to this problem is to install NAT, firewall or router code load that > can properly support fragments. If this cannot be done, then the > following alternatives can be considered: > > [1] Obtaining certificates by other means. > > [2] Reducing the size of the certificate chain. > > [3] Reducing the size of fields within the certificates. This > includes reduction in the key size, the distinguished name or > other fields. This should be considered only as a last resort. > Google for IKE fragmentation, and you get (on page 1):: The CISCO IKE fragmentation extension: http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_fragment_ike_pack.html > Fragmentation of IKE Packets > First Published: September 12, 2008 > Last Updated: September 19, 2008 > Some third-party vendor devices, such as firewalls configured for > stateful packet inspection, do not permit the passthrough of User > Datagram Protocol (UDP) fragments in case they are part of a > fragmentation attack. If all fragments are not passed through, > Internet Key Exchange (IKE) negotiation fails because the intended > responder for the virtual private network (VPN) tunnel cannot > reconstruct the IKE packet and proceed with establishment of the > tunnel. > > This feature provides for the fragmentation of large IKE packets > into a series of smaller IKE packets to avoid fragmentation at the > UDP layer (for example, for large certificate payloads or > certificate request payloads). > > This feature provides support for Cisco IOS in terms of being a > responder in an IKE main mode exchange. > The MSDN synopsys of IKE for Windows Server Protocols: http://msdn.microsoft.com/en-us/library/cc233458%28PROT.13%29.aspx > 1.3.2 IKE Fragmentation > > IKE uses UDP as a transport. IKE messages can be sufficiently large; > so the underlying IP layer may fragment them, as described in > [RFC791] section 2.3. This fragmentation typically happens with IKE > messages that contain certificate chains. To avoid fragmentation- > based attacks, fragmented UDP packets are commonly blocked by > firewalls and routers. Blocking the fragmented UDP packets can lead > to IKE failures that are especially difficult to diagnose. The IKE > fragmentation extension that is specified in this document avoids > fragmentation at the IP level by fragmenting IKE packets into > smaller UDP packets that the underlying IP layer is guaranteed not > to fragment. > > Hosts that support IKE fragmentation advertise this capability > through a "FRAGMENTATION" vendor ID payload; for more information, > see section 1.7. If both peers support fragmentation, a > fragmentation timer is started whenever a message is sent. If the > timer expires, it is assumed that the message that is associated > with the timer did not reach its destination because it was too > large to traverse the intervening network. In this case, the message > is split into several small fragments, and all these small fragments > are sent. > > So that the destination host can correctly reassemble the fragmented > message, each fragment carries a fragment ID that is unique to the > original message and a fragment number that is unique to the > particular fragment. Fragment numbers range from 1 to N, where N is > the number of fragments for a message. > > Upon receipt of a fragment, the receiving host verifies whether it > has already received other fragments for that fragment ID. If not, > the receiving host starts a reassembly timer. It then verifies > whether it has received all N fragments for the message, where the > Nth fragment is indicated by a particular bit in the fragment. If > the fragment reassembly timer expires before all fragments are > correctly received, the receiving host must discard all fragments. > > For details, see section 3.3. > How is this not specifically IKE having problems with fragmentation, such that multiple vendors have written extensions to do application- level fragmentation and that RFCs themselves give recommendations on shrinking certificates to avoid fragmentation? Likewise, experience with using RADIUS on wide scale, which also relies on fragmentation: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02099.html >> EG, a very simple firewall rule: >> DENY all >> ALLOW udp 53 >> ... >> >> has the effect of, if the firewall is not stateful for fragments, of >> killing fragmented traffic. > > Well, There are a number of very simple configuration command can also > do some bad things: > > Erase flash: > reload > > That people _can_ do something stupid like configure a firewall to > drop > fragments is no reason to not allow fragmentation. In other words: > "Your misunderstanding of the protocol does not alter the protocol." But it may very well be so if the misunderstanding is there first: an example from Paul Vixie on Bind: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02088.html Likewise, how many broken IE-isms have corrupted the web? The first adopters, and the widespread adopters, define the real standards. Its an ugly situation, and believe me, I don't like it very much, but simply saying "its broken" and "Its nonstandard" and "those who are broken should fix things" doesn't help if and when the brokenness is widespread. >> Yet at the same time, the Internet has developed a couple of default >> MTUs that, if you assume them, do work, without MTU path discovery. > > In fact, "The Internet" has not actually developed any default MTUs, > mostly because "The Internet" is a fictional entity. By contrast, > RFC791 states on page 25: > > Every internet module must be able to forward a datagram of 68 octets > without further fragmentation. This is because an internet header may > be up to 60 octets, and the minimum fragment is 8 octets. > > I am always amused when people invent fictional authorities like "The > Internet" to justify their unjustifiable claims. If you prefer: The practical default MTU ceiling of 1500B applies for a substantial majority of hosts connected to this wide area network-of- networks colloquially called the Internet, as a side consequence of these hosts being connected through a layer 2 media which is somehow known as "Ethernet" which uses an 802.3 or related data framing. There may be lower MTUs on portions of the network (e.g. the 1492 of PPPoE, the 576 of many dialup connections), but I seriously doubt there are many paths between two hosts on the group of networks colloquially called the Internet where the MTU is greater than 1500. From owner-namedroppers@ops.ietf.org Wed Aug 19 14:18: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 97C5A3A6A9C; Wed, 19 Aug 2009 14:18:24 -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 W+U4jn0vM+od; Wed, 19 Aug 2009 14:18:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 105323A6C24; Wed, 19 Aug 2009 14:18:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdsSL-0001tb-CM for namedroppers-data0@psg.com; Wed, 19 Aug 2009 21:12: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 1MdsSD-0001s9-EC for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 21:12:26 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0E0D0B3560; Wed, 19 Aug 2009 21:12:21 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Nicholas Weaver cc: "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? In-Reply-To: Your message of "Wed, 19 Aug 2009 13:38:49 MST." References: <9993DAE7-65AC-4FDD-876B-95F796956044@ICSI.Berkeley.EDU> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 19 Aug 2009 21:12:21 +0000 Message-ID: <43908.1250716341@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: nick, please do not feed the trolls. --paul re: > Cc: "namedroppers@ops.ietf.org WG" , > Nicholas Weaver > From: Nicholas Weaver > To: Dean Anderson > Subject: Re: [dnsext] What ELSE relies on UDP fragmentation? > Date: Wed, 19 Aug 2009 13:38:49 -0700 > X-Mailer: Apple Mail (2.936) > Sender: owner-namedroppers@ops.ietf.org > > > > On Aug 19, 2009, at 11:20 AM, Dean Anderson wrote: > >> > >> Because people are realizing in the DNSSEC community (like IKE did) > >> that you can't rely on UDP fragmentation to work in a non-trivial (~10% > >> +) of the cases when we actually measure things. > > > > I was unaware that IKE was having problems with UDP fragmentation. IKE > > is a widely deployed protocol. Is there some documentation of this > > claim? > > From this very thread: > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02069.html > > From the referred RFC 3723 section 5.6: > > > When certificate authentication is used, IKE fragmentation can be > > encountered. This can occur when certificate chains are used, or > > even when exchanging a single certificate if the key size or size of > > other certificate fields (such as the distinguished name and other > > OIDs) is large enough. Many Network Address Translators (NATs) and > > firewalls do not handle fragments properly, dropping them on inbound > > and/or outbound. > > > > Routers in the path will also frequently discard fragments after the > > initial one, since they typically will not contain full IP headers > > that can be compared against an Access List. > > > > As a result, where IKE fragmentation occurs, the endpoints will often > > be unable to establish an IPsec security association. The solution > > to this problem is to install NAT, firewall or router code load that > > can properly support fragments. If this cannot be done, then the > > following alternatives can be considered: > > > > [1] Obtaining certificates by other means. > > > > [2] Reducing the size of the certificate chain. > > > > [3] Reducing the size of fields within the certificates. This > > includes reduction in the key size, the distinguished name or > > other fields. This should be considered only as a last resort. > > > > Google for IKE fragmentation, and you get (on page 1):: > > The CISCO IKE fragmentation extension: > > http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_fragment_ike_pack.html > > > Fragmentation of IKE Packets > > First Published: September 12, 2008 > > Last Updated: September 19, 2008 > > Some third-party vendor devices, such as firewalls configured for > > stateful packet inspection, do not permit the passthrough of User > > Datagram Protocol (UDP) fragments in case they are part of a > > fragmentation attack. If all fragments are not passed through, Internet > > Key Exchange (IKE) negotiation fails because the intended responder for > > the virtual private network (VPN) tunnel cannot reconstruct the IKE > > packet and proceed with establishment of the tunnel. > > > > This feature provides for the fragmentation of large IKE packets into a > > series of smaller IKE packets to avoid fragmentation at the UDP layer > > (for example, for large certificate payloads or certificate request > > payloads). > > > > This feature provides support for Cisco IOS in terms of being a > > responder in an IKE main mode exchange. > > > > The MSDN synopsys of IKE for Windows Server Protocols: > > http://msdn.microsoft.com/en-us/library/cc233458%28PROT.13%29.aspx > > > 1.3.2 IKE Fragmentation > > > > IKE uses UDP as a transport. IKE messages can be sufficiently large; so > > the underlying IP layer may fragment them, as described in [RFC791] > > section 2.3. This fragmentation typically happens with IKE messages that > > contain certificate chains. To avoid fragmentation- > > based attacks, fragmented UDP packets are commonly blocked by firewalls > > and routers. Blocking the fragmented UDP packets can lead to IKE > > failures that are especially difficult to diagnose. The IKE > > fragmentation extension that is specified in this document avoids > > fragmentation at the IP level by fragmenting IKE packets into smaller > > UDP packets that the underlying IP layer is guaranteed not to fragment. > > > > Hosts that support IKE fragmentation advertise this capability through a > > "FRAGMENTATION" vendor ID payload; for more information, see section > > 1.7. If both peers support fragmentation, a fragmentation timer is > > started whenever a message is sent. If the timer expires, it is assumed > > that the message that is associated with the timer did not reach its > > destination because it was too large to traverse the intervening > > network. In this case, the message is split into several small > > fragments, and all these small fragments are sent. > > > > So that the destination host can correctly reassemble the fragmented > > message, each fragment carries a fragment ID that is unique to the > > original message and a fragment number that is unique to the particular > > fragment. Fragment numbers range from 1 to N, where N is the number of > > fragments for a message. > > > > Upon receipt of a fragment, the receiving host verifies whether it has > > already received other fragments for that fragment ID. If not, the > > receiving host starts a reassembly timer. It then verifies whether it > > has received all N fragments for the message, where the Nth fragment is > > indicated by a particular bit in the fragment. If the fragment > > reassembly timer expires before all fragments are correctly received, > > the receiving host must discard all fragments. > > > > For details, see section 3.3. > > > > > How is this not specifically IKE having problems with fragmentation, such > that multiple vendors have written extensions to do application- > level fragmentation and that RFCs themselves give recommendations on > shrinking certificates to avoid fragmentation? > > > > > Likewise, experience with using RADIUS on wide scale, which also relies on > fragmentation: > > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02099.html > > >> EG, a very simple firewall rule: > >> DENY all > >> ALLOW udp 53 > >> ... > >> > >> has the effect of, if the firewall is not stateful for fragments, of > >> killing fragmented traffic. > > > > Well, There are a number of very simple configuration command can also > > do some bad things: > > > > Erase flash: > > reload > > > > That people _can_ do something stupid like configure a firewall to drop > > fragments is no reason to not allow fragmentation. In other words: > > "Your misunderstanding of the protocol does not alter the protocol." > > But it may very well be so if the misunderstanding is there first: > > an example from Paul Vixie on Bind: > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02088.html > > Likewise, how many broken IE-isms have corrupted the web? The first > adopters, and the widespread adopters, define the real standards. > > Its an ugly situation, and believe me, I don't like it very much, but > simply saying "its broken" and "Its nonstandard" and "those who are broken > should fix things" doesn't help if and when the brokenness is widespread. > > >> Yet at the same time, the Internet has developed a couple of default > >> MTUs that, if you assume them, do work, without MTU path discovery. > > > > In fact, "The Internet" has not actually developed any default MTUs, > > mostly because "The Internet" is a fictional entity. By contrast, > > RFC791 states on page 25: > > > > Every internet module must be able to forward a datagram of 68 octets > > without further fragmentation. This is because an internet header may > > be up to 60 octets, and the minimum fragment is 8 octets. > > > > I am always amused when people invent fictional authorities like "The > > Internet" to justify their unjustifiable claims. > > If you prefer: The practical default MTU ceiling of 1500B applies for a > substantial majority of hosts connected to this wide area network-of- > networks colloquially called the Internet, as a side consequence of these > hosts being connected through a layer 2 media which is somehow known as > "Ethernet" which uses an 802.3 or related data framing. > > There may be lower MTUs on portions of the network (e.g. the 1492 of > PPPoE, the 576 of many dialup connections), but I seriously doubt there > are many paths between two hosts on the group of networks colloquially > called the Internet where the MTU is greater than 1500. > > > From owner-namedroppers@ops.ietf.org Wed Aug 19 16:48: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 0F54128C304; Wed, 19 Aug 2009 16:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 3+WIuiBRNTQ6; Wed, 19 Aug 2009 16:48:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 413AA28C154; Wed, 19 Aug 2009 16:48:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdunW-000ODv-3K for namedroppers-data0@psg.com; Wed, 19 Aug 2009 23:42: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 1MdunR-000ODS-Ue for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 23:42: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 076D5E609F; Wed, 19 Aug 2009 23:42:24 +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 n7JNgJwT025054; Thu, 20 Aug 2009 09:42:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908192342.n7JNgJwT025054@drugs.dv.isc.org> To: Florian Weimer Cc: Doug Barton , bert hubert , Paul Wouters , namedroppers@ops.ietf.org From: Mark Andrews References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> <87bpmbzq85.fsf@mid.deneb.enyo.de> Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow In-reply-to: Your message of "Wed, 19 Aug 2009 19:08:10 +0200." <87bpmbzq85.fsf@mid.deneb.enyo.de> Date: Thu, 20 Aug 2009 09:42:19 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <87bpmbzq85.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Mark Andrews: > > > The traffic went from .1 connects/second to 60 connections/second compared > > to 6000 UDP requests/second. > > For .gov? ORG. I don't believe GOV has published statistics. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From finenesshbv373@93-38-168-99.ip71.fastwebnet.it Wed Aug 19 17:20: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 7FF973A6C65; Wed, 19 Aug 2009 17:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.789 X-Spam-Level: X-Spam-Status: No, score=-76.789 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_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbjaPVANeWuA; Wed, 19 Aug 2009 17:20:43 -0700 (PDT) Received: from 93-38-168-99.ip71.fastwebnet.it (93-38-168-99.ip71.fastwebnet.it [93.38.168.99]) by core3.amsl.com (Postfix) with ESMTP id 0A4A428C12F; Wed, 19 Aug 2009 17:20:42 -0700 (PDT) Message-ID: <01ca2134$733b1bb0$63a8265d@finenesshbv373> From: "Hubert Wolfson" To: Subject: Better Job Date: Thu, 20 Aug 2009 01:20:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam: Not detected Now you are getting a 100% verifiable degree in just 4-5 weeks, with the help of your work experience. You can get Bachelors, Masters or Doctorate degree in a few weeks time. Call us right now 1.305.460.5721 Leave your msg, with your full name and number and we will get back to you shortly. From owner-namedroppers@ops.ietf.org Wed Aug 19 17: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 D4C4E3A696E; Wed, 19 Aug 2009 17:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 tqKX3o+JnDqw; Wed, 19 Aug 2009 17:25:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F9403A67AA; Wed, 19 Aug 2009 17:25:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdvNu-00042l-A0 for namedroppers-data0@psg.com; Thu, 20 Aug 2009 00:20: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 1MdvNm-00040B-Ey for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 00:20: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 6510DE609C; Thu, 20 Aug 2009 00:19:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7K0JpvJ025380; Thu, 20 Aug 2009 10:19:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908200019.n7K0JpvJ025380@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: William Allen Simpson , namedroppers@ops.ietf.org From: Mark Andrews References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <20090819173026.GA29179@vacation.karoshi.com.> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-reply-to: Your message of "Wed, 19 Aug 2009 17:30:26 GMT." <20090819173026.GA29179@vacation.karoshi.com.> Date: Thu, 20 Aug 2009 10:19:51 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20090819173026.GA29179@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes: > On Wed, Aug 19, 2009 at 12:52:29AM +1000, Mark Andrews wrote: > > > > In message <4A8A9F8D.4030009@gmail.com>, William Allen Simpson writes: > > > bert hubert wrote: > > > > On Mon, Aug 17, 2009 at 2:28 PM, William Allen > > > > Simpson wrote: > > > >> I'm having trouble counting the number of actual likely bytes in > > > >> NXDOMAIN with DNSsec. It seems to me that the result will never > > > >> fit within 512 bytes? (Assuming SOA, NS, glue, etc.) I'm currently > > > >> getting 1022 bytes with SOA alone, but there's several RRSIGs. > > > > > > > > This is the sad NSEC3 truth, even with 1024 bit keys, SHA-1 DS and > > > > SHA-1 signatures. There are 3 NSEC3's needed mostly, and they all have > > > > an RRSIG. And they are not getting any smaller. > > > > > > > OK. I'm especially concerned for NXDOMAIN, as the last measurements I've > > > seen say they're likely a minimum of 12% of the queries. > > > > > > Add key rollover to larger signatures (2 sets of RRSIGs), and we're alway > s > > > looking at more than 1024 bytes, maybe more than 1400 bytes. Anybody hav > e > > > exact data? > > > > You need to learn how to manage keys so there isn't two sets of > > signatures. The DNSKEY response will have multiple signature but > > the rest of the responses don't need them. > > surely this is a policy choice, not a protocol choice. Yep. The protocol will work fine with multiple signature. The messages however will be bigger than ethernet mtu and if you add enough sets of keys in parallel then you will exceed what can be carried of EDNS/UDP. Eventually you will exceed EDNS/TCP as well. > > Basically you add a new DNSKEY to the DNSKEY RRset before you start > > signing with it. Wait until the on DNSKEY RRset has timed out of > > caches. You then stop signing changes with the old key and start > > signing changes with the new key. Once all the data signed with > > the old DNSKEY has timed out of caches you can remove the old DNSKEY. > > thats a fine way to manage a scheduled keyrollover. > not sure that will work for an unscheduled keyroll. A "unscheduled" key rollover just saves a DNSKEY TTL period at the potential expence of more TCP traffic to get the new DNSKEY signatures out there sooner if you don't want to break validation. e.g. * Add new key and sign zone with it and compromised key. * Start timer for compromised key removal (max ttl of zone). * Wait DNSKEY ttl. * Remove RRSIGs from compromised key. * Wait for compromised key timer to expire. * Remove compromised key. Scheduled: * Add new key to DNSKEY RRset * Wait DNSKEY ttl. * Re-sign the zone with the new key. Remove the signatures from the old key from zone data (not DNSKEY RRset). This can be done incrementally but one needs to keep a running timer (max(timer remaining, ttl of just signed)) of when you can remove the old DNSKEY or just wait the max ttl of the zone excluding the DNSKEY's ttl. * Wait the max ttl of the zone, excluding the DNSKEY's ttl. * Remove the old DNSKEY. > --bill > > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 19 18: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 9544E3A6CC0; Wed, 19 Aug 2009 18:30:50 -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 kqIL8jkRcnwp; Wed, 19 Aug 2009 18:30:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8912D3A6CBF; Wed, 19 Aug 2009 18:30:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdwOn-000Chm-1a for namedroppers-data0@psg.com; Thu, 20 Aug 2009 01:25:05 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdwOi-000CgH-Qm for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 01:25:02 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 338F6762AF3; Wed, 19 Aug 2009 18:25: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 5vI4JxldPbxC; Wed, 19 Aug 2009 18:24:57 -0700 (PDT) Received: from [10.0.1.8] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id E06BE762AE9; Wed, 19 Aug 2009 18:24:56 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: <44354701-C922-4469-9B71-C5A511A20C75@virtualized.org> From: David Conrad To: Mark Andrews In-Reply-To: <200908182220.n7IMKEw9004852@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 v936) Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response Date: Wed, 19 Aug 2009 15:24:56 -1000 References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> <200908182220.n7IMKEw9004852@drugs.dv.isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark, On Aug 18, 2009, at 12:20 PM, Mark Andrews wrote: > They will for plain DNS. Just put 256 byte MTU link, for DNS UDP > packets, between the roots and the rest of the Internet and the > problem will be gone within a week. More likely, the root server operators stupid enough to do this would be gone within a week. The Internet isn't a toy or research tool anymore. Really. Breaking it for a non-trivial portion of its users is just not an option. > Firewalls are about "Can I get way with doing this?". Err, no. For most folks on the Internet today, firewalls (or more generally, CPE devices) are very fragile magical black boxes with demons inside that you hire an expensive consultant to chant incantations at when they stop working and all else (typically unplugging the box and plugging it back in) fails. Expecting the owners of those boxes to have even the slightest idea of how to configure them to allow larger UDP packets is equivalent to expecting a car owner to understand how to adjust fuel injectors. Regards, -drc From owner-namedroppers@ops.ietf.org Wed Aug 19 18:49: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 66D7D3A6A72; Wed, 19 Aug 2009 18:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 jUVdS14zTZyb; Wed, 19 Aug 2009 18:49:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76B7128C14B; Wed, 19 Aug 2009 18:49:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdwhY-000FTL-27 for namedroppers-data0@psg.com; Thu, 20 Aug 2009 01:44:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdwhS-000FSQ-6B for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 01:44: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 4F769E609C; Thu, 20 Aug 2009 01:44: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 n7K1iIgO026758; Thu, 20 Aug 2009 11:44:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908200144.n7K1iIgO026758@drugs.dv.isc.org> To: David Conrad Cc: IETF DNSEXT WG From: Mark Andrews References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> <200908182220.n7IMKEw9004852@drugs.dv.isc.org> <44354701-C922-4469-9B71-C5A511A20C75@virtualized.org> Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-reply-to: Your message of "Wed, 19 Aug 2009 15:24:56 -1000." <44354701-C922-4469-9B71-C5A511A20C75@virtualized.org> Date: Thu, 20 Aug 2009 11:44:18 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <44354701-C922-4469-9B71-C5A511A20C75@virtualized.org>, David Conrad writes: > Mark, > > On Aug 18, 2009, at 12:20 PM, Mark Andrews wrote: > > They will for plain DNS. Just put 256 byte MTU link, for DNS UDP > > packets, between the roots and the rest of the Internet and the > > problem will be gone within a week. > > More likely, the root server operators stupid enough to do this would > be gone within a week. > > The Internet isn't a toy or research tool anymore. Really. Breaking it > for a non-trivial portion of its users is just not an option. I didn't think anyone would take that seriously. Note the root operator would NOT be breaking the Internet. It's the firewall vendors/operators that are breaking things. Fragmentation has been part of the Internet since day one. There is no excuse for any device, including firewalls, to not handle this. > > Firewalls are about "Can I get way with doing this?". > > Err, no. For most folks on the Internet today, firewalls (or more > generally, CPE devices) are very fragile magical black boxes with > demons inside that you hire an expensive consultant to chant > incantations at when they stop working and all else (typically > unplugging the box and plugging it back in) fails. Expecting the > owners of those boxes to have even the slightest idea of how to > configure them to allow larger UDP packets is equivalent to expecting > a car owner to understand how to adjust fuel injectors. I don't care if it is the operator or the vendor. It's still "Can I get way with doing this?" If they didn't feel they could get away with this we wouldn't be having this discussion. Mark > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From templew@uplingua.com Wed Aug 19 20:43: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 C936728C0D0; Wed, 19 Aug 2009 20:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.761 X-Spam-Level: X-Spam-Status: No, score=-23.761 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT2=0.001, 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_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, 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 xhQk9ATjOXSU; Wed, 19 Aug 2009 20:43:31 -0700 (PDT) Received: from pool-173-50-149-208.ptldor.fios.verizon.net (pool-173-50-149-208.ptldor.fios.verizon.net [173.50.149.208]) by core3.amsl.com (Postfix) with ESMTP id F2F5828C0F5; Wed, 19 Aug 2009 20:43:29 -0700 (PDT) Received: from 173.50.149.208 by uplingua.com; Wed, 19 Aug 2009 20:43:34 -0800 Message-ID: <000d01ca2148$647fa7d0$6400a8c0@templew> From: Faye Benavides To: Subject: Click here Date: Wed, 19 Aug 2009 20:43:34 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2148.647FA7D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1478 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA2148.647FA7D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Can't see=20 this email? VIEW IN BROWSER =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Threat Information and=20 Product News for Customers =20 =20 =20 =20 =20 =20 =20 =20 =20 In this Issue: =20   =20 =20 Product=20 News ####High Quality Penis Enlargement Pills. ...= If you're a man, you need to check this trial out#### =A0 =A0 One little click =20 =20 =20 =20 =20 We appreciate your interest in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to = our mailing=20 list. =20 =20 =A0 =20 Copyright=20 ¿ 2009 Oredy, Incorporated. All rights reserved. All other produ= ct=20 orcompany names may be trademarks or registered trademarks of their=20 owners. ------=_NextPart_000_0007_01CA2148.647FA7D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ca= n't see=20 this email? VIEW IN BROWSER

=
Threat Information an= d=20 Product News for Customers
In this Issue:<= /TD>
 
Product=20 News


####High Quality Penis= Enlargement Pills. ... If you're a man, you need to check this trial out####
=A0
=A0
One little click
We appreciate your inter= est in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to our mailing=20 list.
=A0
Copyright=20 ¿ 2009 Oredy, Incorporated. All rights reserved. All other produ= ct=20 or
company names may be trademarks or registered trademarks of the= ir=20 owners.
------=_NextPart_000_0007_01CA2148.647FA7D0-- From owner-namedroppers@ops.ietf.org Wed Aug 19 21:05: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 9EED328C10A; Wed, 19 Aug 2009 21:05:36 -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 Xj1rqd0GQmZ5; Wed, 19 Aug 2009 21:05:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9DBF28C0F6; Wed, 19 Aug 2009 21:05:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdyo0-0009sc-5G for namedroppers-data0@psg.com; Thu, 20 Aug 2009 03:59: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 1Mdynw-0009sC-Bq for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 03:59:13 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DF571B35B3 for ; Thu, 20 Aug 2009 03:59:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Size of DNSsec NXDOMAIN response In-Reply-To: Your message of "Thu, 20 Aug 2009 11:44:18 +1000." <200908200144.n7K1iIgO026758@drugs.dv.isc.org> References: <4A894CD9.7030307@gmail.com> <3efd34cc0908180343u2616b95ep66ea25146b03eb94@mail.gmail.com> <4A8A9F8D.4030009@gmail.com> <200908181452.n7IEqTZ5098762@drugs.dv.isc.org> <3efd34cc0908180836g7e513705ye65fccdd34e963ed@mail.gmail.com> <3efd34cc0908180927t17a0aeacnf3789f9e5ce699ad@mail.gmail.com> <200908182220.n7IMKEw9004852@drugs.dv.isc.org> <44354701-C922-4469-9B71-C5A511A20C75@virtualized.org> <200908200144.n7K1iIgO026758@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 20 Aug 2009 03:59:11 +0000 Message-ID: <59836.1250740751@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Mark Andrews > Date: Thu, 20 Aug 2009 11:44:18 +1000 > > > The Internet isn't a toy or research tool anymore. Really. Breaking it > > for a non-trivial portion of its users is just not an option. > > I didn't think anyone would take that seriously. Note the root operator > would NOT be breaking the Internet. It's the firewall vendors/operators > that are breaking things. Fragmentation has been part of the Internet > since day one. There is no excuse for any device, including firewalls, > to not handle this. since mark works for ISC let me be perfectly clear about ISC's position. 1. we would never break something intentionally in this way. 2. the person who makes the triggering change or who knew what the effect would be is the one at fault, regardless of how screwed up everything was before that triggering change. therefore, see #1. From owner-namedroppers@ops.ietf.org Wed Aug 19 22:49: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 DB2A13A68D9; Wed, 19 Aug 2009 22:49:57 -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 SyN9nVBC3JR4; Wed, 19 Aug 2009 22:49:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AC943A6AAD; Wed, 19 Aug 2009 22:49:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me0Qe-000Nbx-F5 for namedroppers-data0@psg.com; Thu, 20 Aug 2009 05:43:16 +0000 Received: from [80.64.7.197] (helo=mx10.tdc.fi) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me0QZ-000NbH-K6 for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 05:43:13 +0000 X-IronPort-AV: E=Sophos;i="4.43,412,1246827600"; d="scan'208";a="105699" Received: from fi-hel2ex01.nordiclan.net ([194.100.219.27]) by mail-gw1.tdc.fi with ESMTP; 20 Aug 2009 08:43:08 +0300 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: RE: [dnsext] Re: What ELSE relies on UDP fragmentation? Date: Thu, 20 Aug 2009 08:43:07 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F151BAD9E@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Re: What ELSE relies on UDP fragmentation? Thread-Index: Acog469YsWDwi7dmSAOLFb/+zwTZPgAdO40A References: <4A8B9336.9080200@restena.lu> From: "Aki Tuomi" To: "Stefan Winter" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1uYW1lZHJvcHBlcnNA b3BzLmlldGYub3JnIFttYWlsdG86b3duZXItDQo+IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBTdGVmYW4gV2ludGVyDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5 LCAyMDA5IDg6NTMgQU0NCj4gVG86IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmcNCj4gQ2M6IE5p Y2hvbGFzIFdlYXZlcg0KPiBTdWJqZWN0OiBbZG5zZXh0XSBSZTogV2hhdCBFTFNFIHJlbGllcyBv biBVRFAgZnJhZ21lbnRhdGlvbj8NCj4gDQo+IFsgTW9kZXJhdG9ycyBub3RlOiBQb3N0IHdhcyBt b2RlcmF0ZWQsIGVpdGhlciBiZWNhdXNlIGl0IHdhcyBwb3N0ZWQgYnkNCj4gICAgYSBub24tc3Vi c2NyaWJlciwgb3IgYmVjYXVzZSBpdCB3YXMgb3ZlciAyMEsuDQo+ICAgIFdpdGggdGhlIG1hc3Np dmUgYW1vdW50IG9mIHNwYW0sIGl0IGlzIGVhc3kgdG8gbWlzcyBhbmQgdGhlcmVmb3JlDQo+ICAg IGRlbGV0ZSByZWxldmFudCBwb3N0cyBieSBub24tc3Vic2NyaWJlcnMuDQo+ICAgIFBsZWFzZSBm aXggeW91ciBzdWJzY3JpcHRpb24gYWRkcmVzc2VzLiBdDQo+IA0KPiBIZWxsbywNCj4gDQo+IChu b3Qgc3Vic2NyaWJlZCB0byB0aGlzIGxpc3QsIHNvcnJ5IGZvciBicmVha2luZyB0aHJlYWRpbmcp DQo+IA0KPiA+IENhbiBhbnlvbmUgaWRlbnRpZnkgYSBtYWpvciBhcHBsaWNhdGlvbiBvdGhlciB0 aGFuIEROU1NFQyB3aGljaCB1c2VzDQo+IFVEUCBhbmQgYXNzdW1lcyB0aGF0IHBhY2tldHMgZ3Jl YXRlciB0aGFuIHRoZSBFdGhlcm5ldCBNVFUgY2FuIGJlIHNlbnQNCj4gYW5kIHdpbGwgYmUgcHJv cGVybHkgZnJhZ21lbnRlZCBhbmQgcmVhc3NlbWJsZWQgb24gdHJhZmZpYyB0cmF2ZXJzaW5nDQo+ IHRoZSBJbnRlcm5ldD8NCj4gDQo+IG9uZSBvdGhlciBwcm90b2NvbCB0aGF0IHJlbGllcyBvbiBJ UCBmcmFnbWVudGF0aW9uIGZvciBVRFAgcGFja2V0cw0KPiB3b3JraW5nIGlzIFJBRElVUy4gVGhl IG1heGltdW0gZGF0YWdyYW0gc2l6ZSBmb3IgUkFESVVTIHBhY2tldHMgaXMgNGssDQo+IGFuZCBp dCBjYW4gbm90IGJlIHNwbGl0IGludG8gbXVsdGlwbGUgZGF0YWdyYW1zLiBXaGV0aGVyIG9yIG5v dCB5b3UNCj4gY2FsbA0KPiBSQURJVVMgIm1ham9yIiBvciBub3QgaXMgeW91ciBvd24gY2hvaWNl IDotKQ0KPiANCj4gSW4gZGF5LXRvLWRheSBkZXBsb3ltZW50LCB3ZSAoZWR1cm9hbSwgYSBsYXJn ZSB3aXJlbGVzcyBMQU4gcm9hbWluZw0KPiBjb25zb3J0aXVtKSBoYXZlIGhpdCB0aGUgfiAxNTAw IE1UVSBiYXJyaWVyIHJlcGVhdGVkbHkgd2hlbiB1c2luZw0KPiBhdXRoZW50aWNhdGlvbiBwYXls b2FkcyB3aGljaCB0cmFuc2ZlciBsYXJnZSBhbW91bnRzIG9mIGRhdGEgKEVBUC1UTFMsDQo+IG1v c3Qgbm90YWJseSwgd2hpY2ggc2VuZHMgWC41MDkgY2VydGlmaWNhdGVzIGJpZGlyZWN0aW9uYWxs eSBpbiBSQURJVVMNCj4gZGF0YWdyYW1zKS4NCj4gDQo+IEknbSBmb2xsb3dpbmcgdGhpcyB0aHJl YWQgaGVyZSB3aXRoIHNvbWUgaW50ZXJlc3QgLSB0aGUgaGludCB0aGF0IG1vc3QNCj4gT1NlcyBz ZXQgdGhlIERGIGJpdCBvbiBldmVyeSBvdXRnb2luZyBkYXRhZ3JhbSBmb3IgZXhhbXBsZSBpcyBp bXBvcnRhbnQNCj4gbmV3cyBmb3IgdXMgKGFzIGl0IHJ1aW5zIHRoZSBwYXJ0eSBmb3IgbWFueSBF QVAtVExTIHdpcmVsZXNzIHVzZXJzDQo+IHdvcmxkLXdpZGUpLg0KPiANCj4gR3JlZXRpbmdzLA0K PiANCj4gU3RlZmFuIFdpbnRlcg0KPiANCj4gLS0NCg0KV2UgaGF2ZSBzdWZmZXJlZCBmcm9tIHBy b2JsZW1zIHdpdGggUkFESVVTIGRhdGFncmFtIHNpemVzIHdpdGggYXV0aGVudGljYXRpb24uIEl0 IGRvZXMgc2VlbSB0aGF0IHNvbWUgc3lzdGVtcyBhcmUgcmVhbGx5IG5vdCBoYXBweSB3aXRoIGZy YWdtZW50ZWQgUkFESVVTIHBhY2tldHMuIEJ1dCB3aGF0IG15IHdpcmVzaGFyayBzaG93cyBtZSwg aXMgdGhhdCB0aGUgZnJhZ21lbnRhdGlvbiBpcyBub3QgZG9uZSBvbiBNVFUgc2l6ZSwgYnV0IGlu c3RlYWQgUkFESVVTIHBlcmZvcm1zIHRoZSBzcGxpdHRpbmcgaXRzZWxmIChhdCBsZWFzdCBvbiBy YWRpYXRvcikuDQoNCkFraSBUdW9taQ0K From owner-namedroppers@ops.ietf.org Wed Aug 19 23:10: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 93B523A6ABC; Wed, 19 Aug 2009 23:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nacF8l0nMcLy; Wed, 19 Aug 2009 23:10:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C4EF3A6A99; Wed, 19 Aug 2009 23:10:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me0m1-0000jS-2m for namedroppers-data0@psg.com; Thu, 20 Aug 2009 06:05:21 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me0lx-0000in-I6 for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 06:05:19 +0000 Received: by ewy11 with SMTP id 11so5506075ewy.11 for ; Wed, 19 Aug 2009 23:05:15 -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=RbDGV6o7bxGJwOw1bDQuhGSTferwzw0g6jO/h59vlo0=; b=le5tzvMDQSECV7GDqZ/+syIamVpx6693N+w0Rytkr+AJ/H/q3EW8vuovDQJPb0qwRx tHfX3rEFBgqhcnSlnJpw1EzzxupPklyWPJUZDfNBlc1m270e3PdII799xOUblvv3zqbN grxa5cSEx23RMGJetKTGm8Xu3F2uLrQDWZamw= 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=loRVkyXgJ8T6XCuZHAoQG4qG8Kmlkfjvbmi88JNDQN1osqtU7MsQFPtdIajfs5oeTk RYGi5tslH8b1Wr3DY5QIkPhjVoHOhVZKAY4Bz1kpLvgjLLbWnTFrExsyjgMD7Y17a2+C TXrTC49TiUZckJFj7se/StuFVu6bjLz8NYvf0= MIME-Version: 1.0 Received: by 10.210.118.13 with SMTP id q13mr2651339ebc.14.1250748315156; Wed, 19 Aug 2009 23:05:15 -0700 (PDT) In-Reply-To: <87y6pf9u17.fsf@mid.deneb.enyo.de> References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> <87bpmbzq85.fsf@mid.deneb.enyo.de> <200908192342.n7JNgJwT025054@drugs.dv.isc.org> <87y6pf9u17.fsf@mid.deneb.enyo.de> From: bert hubert Date: Thu, 20 Aug 2009 08:04:52 +0200 Message-ID: <3efd34cc0908192304u663a3f11oeae8ed3e8e197bc7@mail.gmail.com> Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow To: Florian Weimer Cc: Mark Andrews , Doug Barton , Paul Wouters , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 20, 2009 at 3:02 AM, Florian Weimer wrote: >>> > The traffic went from .1 connects/second to 60 connections/second com= pared >>> > to 6000 UDP requests/second. >> ORG. =A0I don't believe GOV has published statistics. > > Okay, I just had to ask because of the subject line. 8-) GOV operational numbers would be very interesting given their >1470 NXDOMAIN responses. It would be *really* good if they could share their experiences (perhaps on dns-operations). So if anyone has any influence there.. Bert From attainingva661@ishikawap.com Thu Aug 20 01:45: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 F0CE03A67E3; Thu, 20 Aug 2009 01:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.42 X-Spam-Level: X-Spam-Status: No, score=-28.42 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HELO_MISMATCH_BR=2.4, 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_NONE=0.1, SARE_SUB_FREE_BANG=0.7, 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 k7YHPpVm9gmb; Thu, 20 Aug 2009 01:45:32 -0700 (PDT) Received: from 189-015-67-229.xd-dynamic.ctbcnetsuper.com.br (unknown [187.42.10.108]) by core3.amsl.com (Postfix) with ESMTP id 521613A6B53; Thu, 20 Aug 2009 01:45:29 -0700 (PDT) Received: from 187.42.10.108 by ishikawap.com with smtp 64SI6HUG82890; Thu, 20 Aug 2009 05:44:03 -0300 Message-ID: <000d01ca2172$5eb48e40$6400a8c0@attainingva661> From: Sheron Simon To: Subject: So many people have been telling me about this, and I got it free!! Date: Thu, 20 Aug 2009 05:44:03 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2172.5EB48E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA2172.5EB48E40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Get Acai Berry working for you with your Free Trial of Acai Flush.   http://www.violencizers.biz/?iupvqdrlje =A0 Hey did I tell you about how I am changing my life? click =A0 Enter promptly =A0 =A0 best ragards Simon ------=_NextPart_000_0007_01CA2172.5EB48E40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Get Acai Berry working for you with your = Free Trial of Acai Flush.
 
http://www.violencizers.bi= z/?iupvqdrlje
=A0
Hey did I tell you about how I am changin= g my life? click
=A0
=A0
=A0
best ragards Simon
------=_NextPart_000_0007_01CA2172.5EB48E40-- From owner-namedroppers@ops.ietf.org Thu Aug 20 02:37: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 0C09428C186; Thu, 20 Aug 2009 02:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.719 X-Spam-Level: *** X-Spam-Status: No, score=3.719 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF1HjYljJTFB; Thu, 20 Aug 2009 02:37:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DB5528C0EF; Thu, 20 Aug 2009 02:37:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me3yU-0004DR-Vs for namedroppers-data0@psg.com; Thu, 20 Aug 2009 09:30:26 +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 1Me3yQ-0004CS-PV for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 09:30:25 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Me3yJ-0000YJ-Hq; Thu, 20 Aug 2009 10:30:15 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Me3yE-00052G-0w; Thu, 20 Aug 2009 10:30:10 +0100 Message-ID: From: "George Barwood" To: Cc: "W.C.A. Wijngaards" References: <406156C126454795B38BBC396D4DED73@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Thu, 20 Aug 2009 10:30:13 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At the suggestion of Wouter Wijngaards, I have updated my draft again: http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-02.txt Changes: Option for all pages to be sent immediately ( so response time is 1 x RTT ). Cookie support optional. UDP payload size is independent of EDNS UDP payload size. Page size limited to 4095 bytes. Reserved areas added. Compatibility section added ( oops, just realised I forgot to update the index ). Many thanks to those who have contributed, as always, your feedback is appreciated. George ----- Original Message ----- From: "George Barwood" To: Sent: Tuesday, August 18, 2009 9:51 PM Subject: [dnsext] EDNS Page Option draft updated >I have updated my internet draft : > > Abstract > > Describes an EDNS option to allow large DNS responses to be sent > using small UDP packets. > > http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-01.txt > > Summary of changes: > > - Support for proxies that truncate at 512 bytes. > - Follow-up requests may be sent in parallel, so total response time is 2 > x RTT. > - The MAC has gone. > > As before, your comments are appreciated. > Regards, > George > > > > > > > > > > From owner-namedroppers@ops.ietf.org Thu Aug 20 03:44: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 F21E83A68AE; Thu, 20 Aug 2009 03:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.071, 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 yXHE4JpZdWtL; Thu, 20 Aug 2009 03:44:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9761728C42A; Thu, 20 Aug 2009 03:44:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me51w-000CKc-CM for namedroppers-data0@psg.com; Thu, 20 Aug 2009 10:38:04 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me51s-000CIQ-6M for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 10:38:02 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id A5DC9C2DA5; Thu, 20 Aug 2009 11:29:28 +0100 (BST) Date: Thu, 20 Aug 2009 11:29:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , namedroppers@ops.ietf.org cc: "W.C.A. Wijngaards" , Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft updated Message-ID: <05576F4086A131CF3C9F4464@Ximines.local> In-Reply-To: References: <406156C126454795B38BBC396D4DED73@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: George, > At the suggestion of Wouter Wijngaards, I have updated my draft again: > > http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-02.txt Three comments. 1. Please rename the "secret key" as a "nonce". It isn't a secret if it is sent in the clear. Equally, I think your security statement is overblowing the problem. As far as I can see, the risks are that if the client (a) does not use sufficient randomness in generating the nonce, or (b) the nonce is snooped upon, the client may end up with forged responses. If every response was a DNSSEC signed response, this wouldn't matter much except as a DoS vector. 2. The draft does not seem to define the data structure within the pages. I am taking it that the pages, if byte-wise concatenated, would form a single large DNS packet. My worry about this is that various middleboxes appear to silently pry into DNS packets and drop packets that are not in proper form (Nicholas Weaver and I discovered that Cisco IOS NAT does this even when DNS NAT is turned off). Hence you might find that packets containing pages other than the first get dropped, because they don't look like DNS packets. An alternative would be to make each page of variable size and look like a genuine answer to the original query, but containing a subset of the RRs that would be returned. The client would then concatenate all the RRs (eliminating duplicates if any). This would have more chance of passing through hostile middleboxes. 3. If "Send All Pages" is set by the client and respected by the server, why does the server need to generate a cookie? (i.e. why can't it set No Cookie). 4. I wonder if the "Send All Pages" bit falls between two stools. You say its implementation on the server is optional. However, when/how would the client know how to set it? At the very least, a server not supporting it should behave as if Send All Pages was set to zero (making it "Please Send All Pages" bit). But another way of doing this would simply be to make it *ALWAYS* send all pages, then delete all the stuff about the cookie and so forth; this is no less secure / DoS prone than the existing draft if "Send All Pages" is set and respected, but is far, far, far simpler. I can't help but think you are trying to solve several problems here: transmission of large responses, forged response attacks, and amplification attacks. If introduce SendAllPages as an option, you have already removed resistance to amplification attacks. Moreover, the very same amplification attack could be carried out simply by not specifying the EDNS Page Option, in which case the large packet would arrive as fragments. I would be tempted to drop this. If you had a very simple protocol whereby sending a single query (with a nonce) resulted in more than one UDP packet coming back filled with answers (possibly split bytewise, possibly by RR), I suspect the merits of simplicity would override the loss in functionality. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 20 05: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 878933A68D4; Thu, 20 Aug 2009 05:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.808 X-Spam-Level: ** X-Spam-Status: No, score=2.808 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktVkyUEzrXix; Thu, 20 Aug 2009 05:27:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4557F3A6D30; Thu, 20 Aug 2009 05:27:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me6dZ-0000uT-TZ for namedroppers-data0@psg.com; Thu, 20 Aug 2009 12:21:01 +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 1Me6dT-0000sM-Hx for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 12:20:59 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Me6dS-0003GD-FM; Thu, 20 Aug 2009 13:20:54 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Me6dQ-0004Ah-FC; Thu, 20 Aug 2009 13:20:52 +0100 Message-ID: From: "George Barwood" To: Cc: "Alex Bligh" References: <406156C126454795B38BBC396D4DED73@localhost> <05576F4086A131CF3C9F4464@Ximines.local> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Thu, 20 Aug 2009 13:20:55 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Alex Bligh" To: "George Barwood" ; Cc: "W.C.A. Wijngaards" ; "Alex Bligh" Sent: Thursday, August 20, 2009 11:29 AM Subject: Re: [dnsext] EDNS Page Option draft updated > George, > >> At the suggestion of Wouter Wijngaards, I have updated my draft again: >> >> http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-02.txt > > Three comments. > > 1. Please rename the "secret key" as a "nonce". It isn't a secret > if it is sent in the clear. Equally, I think your security statement > is overblowing the problem. As far as I can see, the risks are > that if the client (a) does not use sufficient randomness in > generating the nonce, or (b) the nonce is snooped upon, the client > may end up with forged responses. If every response was a DNSSEC > signed response, this wouldn't matter much except as a DoS vector. It is secret, in that an attacker that can snoop or guess it can forge responses. Of course this means that it only protects against out-of-path attacks. These do matter - DNS is very vulnerable to spoofing, as you say, for DNSSEC this can cause denial of service. > 2. The draft does not seem to define the data structure within the pages. > I am taking it that the pages, if byte-wise concatenated, would form > a single large DNS packet. That's correct, I think the draft does describe it, by " The client allocates an assembly buffer, and copies the Page data into it, at offset (Page number) x (Page Size)." and "When the client has received all of the pages, the complete assembled response is then processed normally." but possibly I could improve this. > My worry about this is that various > middleboxes appear to silently pry into DNS packets and drop packets > that are not in proper form (Nicholas Weaver and I discovered that > Cisco IOS NAT does this even when DNS NAT is turned off). Hence you > might find that packets containing pages other than the first get > dropped, because they don't look like DNS packets. > > An alternative would be to make each page of variable size and > look like a genuine answer to the original query, but containing > a subset of the RRs that would be returned. The client would > then concatenate all the RRs (eliminating duplicates if any). > This would have more chance of passing through hostile middleboxes. To be clear : the response does have the normal DNS format, since the data is carried in the EDNS option record. Existing servers sometimes do not copy the question back (when there is an error), and in other respects, the packet looks like a NoData response with an EDNS option. The middlebox would have to inspect the EDNS Option record and reject it for, say, having an unknown EDNS option. I don't think that's going to be common at all, most middleboxes are quite dumb. On the other hand proxies that truncate at 512 bytes are almost universal. > 3. If "Send All Pages" is set by the client and respected by the > server, why does the server need to generate a cookie? (i.e. why > can't it set No Cookie). To allow lost packets to be retried without sending the whole response. > 4. I wonder if the "Send All Pages" bit falls between two stools. You > say its implementation on the server is optional. However, when/how > would the client know how to set it? The client should not set it if there may be a proxy that doesn't understand the EDNS Page option ( i.e. all proxies in practice ). Otherwise the client should set it. Note that non-recursive requests are never proxied, so it is always set in this case. > At the very least, a server > not supporting it should behave as if Send All Pages was set to zero > (making it "Please Send All Pages" bit). The bit is indeed a "Please Send All Pages" bit. > But another way of doing this would simply be to make it *ALWAYS* > send all pages, then delete all the stuff about the cookie and > so forth; this is no less secure / DoS prone than the existing draft if > "Send All Pages" is set and respected, but is far, far, far > simpler. This doesn't work with proxies that truncate at 512 bytes, since they will also not proxy multiple responses for a single request. > I can't help but think you are trying to solve several problems here: > transmission of large responses, forged response attacks, and > amplification attacks. Yes, that's correct. You left other problems out, especially the proxies, and fragmentation problems. > If introduce SendAllPages as an option, you > have already removed resistance to amplification attacks. No, because servers don't have to honour it, provided they implement cookies. A server under amplification attack will probably ignore SendAllPages = 1. > Moreover, > the very same amplification attack could be carried out simply by > not specifying the EDNS Page Option, in which case the large packet > would arrive as fragments. Servers that are under amplification attack may choose to not respond to queries that don't have an EDNS Page option. Best wishes, George > I would be tempted to drop this. If you had > a very simple protocol whereby sending a single query (with a nonce) > resulted in more than one UDP packet coming back filled with answers > (possibly split bytewise, possibly by RR), I suspect the merits > of simplicity would override the loss in functionality. > > -- > Alex Bligh > From owner-namedroppers@ops.ietf.org Thu Aug 20 05:40: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 BF4AF3A6E32; Thu, 20 Aug 2009 05:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.078 X-Spam-Level: X-Spam-Status: No, score=-5.078 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 u1ug1vKdZe6m; Thu, 20 Aug 2009 05:40:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AC303A67B5; Thu, 20 Aug 2009 05:40:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me6sD-0004J3-IH for namedroppers-data0@psg.com; Thu, 20 Aug 2009 12:36:09 +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 1Me6s9-0004IS-Ue for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 12:36: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 n7KCZmIq000167; Thu, 20 Aug 2009 05:35:48 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , namedroppers@ops.ietf.org, "W.C.A. Wijngaards" Message-Id: <22290964-703C-4F75-A29E-B796BFE7B3C0@icsi.berkeley.edu> From: Nicholas Weaver To: Alex Bligh In-Reply-To: <05576F4086A131CF3C9F4464@Ximines.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS Page Option draft updated Date: Thu, 20 Aug 2009 05:35:48 -0700 References: <406156C126454795B38BBC396D4DED73@localhost> <05576F4086A131CF3C9F4464@Ximines.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 20, 2009, at 3:29 AM, Alex Bligh wrote: > 2. The draft does not seem to define the data structure within the > pages. > I am taking it that the pages, if byte-wise concatenated, would form > a single large DNS packet. My worry about this is that various > middleboxes appear to silently pry into DNS packets and drop packets > that are not in proper form (Nicholas Weaver and I discovered that > Cisco IOS NAT does this even when DNS NAT is turned off). Hence you > might find that packets containing pages other than the first get > dropped, because they don't look like DNS packets. > > An alternative would be to make each page of variable size and > look like a genuine answer to the original query, but containing > a subset of the RRs that would be returned. The client would > then concatenate all the RRs (eliminating duplicates if any). > This would have more chance of passing through hostile middleboxes. Agreed: I think this is absolutely, 100%, totally essential. IT may add one packet (which will hurt reliability), but there are far too many processes that will block "non DNS on port 53", which means it is essential that any user-level fragmentation produce fragments that are semantically DNS packets on their own. Thats as if not more endemic than "Block fragments" > 3. If "Send All Pages" is set by the client and respected by the > server, why does the server need to generate a cookie? (i.e. why > can't it set No Cookie). > > 4. I wonder if the "Send All Pages" bit falls between two stools. You > say its implementation on the server is optional. However, when/how > would the client know how to set it? At the very least, a server > not supporting it should behave as if Send All Pages was set to zero > (making it "Please Send All Pages" bit). > > But another way of doing this would simply be to make it *ALWAYS* > send all pages, then delete all the stuff about the cookie and > so forth; this is no less secure / DoS prone than the existing > draft if > "Send All Pages" is set and respected, but is far, far, far > simpler. > > I can't help but think you are trying to solve several problems here: > transmission of large responses, forged response attacks, and > amplification attacks. If introduce SendAllPages as an option, you > have already removed resistance to amplification attacks. Moreover, > the very same amplification attack could be carried out simply by > not specifying the EDNS Page Option, in which case the large packet > would arrive as fragments. I would be tempted to drop this. If you > had > a very simple protocol whereby sending a single query (with a nonce) > resulted in more than one UDP packet coming back filled with answers > (possibly split bytewise, possibly by RR), I suspect the merits > of simplicity would override the loss in functionality. Agreed. That describs what we need: An application layer fragmented response which a) Each fragment still parses as valid DNS. (fools middleboxes) b) All fragments are sent instantly. (doesn't add latency, doesn't require state) The amplification factor is low, the protocol is simple, but the utility is high. The ONLY thing it might screw it up is some stupid statetful things which will go "the second response doesn't match the first, same transaction ID, different payload", but even THOSE devices could be fooled with a tweak where the sender recognizes that this happens and sends one request and a burst of pseudo-requests, with the fragments being responses to the pseudo-request. From owner-namedroppers@ops.ietf.org Thu Aug 20 05:45: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 371603A68ED; Thu, 20 Aug 2009 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=0.068, 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 pPyO1DTnKJ7h; Thu, 20 Aug 2009 05:45:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51D673A680A; Thu, 20 Aug 2009 05:45:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me6xE-0005f7-74 for namedroppers-data0@psg.com; Thu, 20 Aug 2009 12:41:20 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me6x9-0005cx-CP for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 12:41:18 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id A3C5CC2DA3; Thu, 20 Aug 2009 13:41:13 +0100 (BST) Date: Thu, 20 Aug 2009 13:41:08 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] EDNS Page Option draft updated Message-ID: <1D374B65F0C497762A3994AC@Ximines.local> In-Reply-To: References: <406156C126454795B38BBC396D4DED73@localhost> <05576F4086A131CF3C9F4464@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: George, > To be clear : the response does have the normal DNS format, since the > data is carried in the EDNS option record. Yes, I'd totally missed that; that addresses the concern completely. You could clarify by adding that the response to a followup request is in the same format as 2.2, and that the format of the "page data" is the complete response packet (presumably without the UDP headers) - currently you just say it is "processed as normal". I note this will break some NATs which rely on rewriting DNS A and PTR records as they pass through the NAT, unless they are modified to also do their rewrites within the EDNS page data. I also note that (a) this might be considered an advantage of the proposal, and (b) DNSSEC would break this behaviour too. >> 3. If "Send All Pages" is set by the client and respected by the >> server, why does the server need to generate a cookie? (i.e. why >> can't it set No Cookie). > > To allow lost packets to be retried without sending the whole response. Sure. That's why you may want to have a cookie. But why are you preventing "No Cookie" from being set if the server wants to (so it doesn't have to retain state at all, but can just send all the packets at once). >> 4. I wonder if the "Send All Pages" bit falls between two stools. You >> say its implementation on the server is optional. However, when/how >> would the client know how to set it? > > The client should not set it if there may be a proxy that doesn't > understand the EDNS Page option ( i.e. all proxies in practice ). > Otherwise the client should set it. And the stub resolver client, presumably, needs to discover this somehow? >> But another way of doing this would simply be to make it *ALWAYS* >> send all pages, then delete all the stuff about the cookie and >> so forth; this is no less secure / DoS prone than the existing draft if >> "Send All Pages" is set and respected, but is far, far, far >> simpler. > > This doesn't work with proxies that truncate at 512 bytes, since they will > also not proxy multiple responses for a single request. Really? Have you tested that? I would have thought they might just treat it as a retransmission. I appreciate they /might/ do this, but then they might also strip unknown OPT RRs (e.g. in an attempt to stop covert communication channels). -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 20 06:48: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 2C9833A6B78; Thu, 20 Aug 2009 06:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=-0.906, 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 UR6nX-bW-7iY; Thu, 20 Aug 2009 06:48:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECB5E3A69C1; Thu, 20 Aug 2009 06:48:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me7v0-000GTt-VG for namedroppers-data0@psg.com; Thu, 20 Aug 2009 13:43:06 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me7uw-000GTG-Fj; Thu, 20 Aug 2009 13:43:04 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=bBiwYP+Jo6cRDS7mDE1UDSQXNYTuthA6BujGFZ74uMdPaUvv0MWuT5NN 7AQzS+XQLxiSKs2u96B2dv3QzPVa2hbikWeG/i8yJDK+hiHKaPghEpjtr oiTsJayECGCR2A5; 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=1250775782; x=1282311782; 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]=20EDNS=20Page=20Option=20draft=20updated|Date:=20Thu, =2020=20Aug=202009=2015:42:51=20+0200|Message-ID:=20|To:=20Alex=20Bligh=20|Cc: =20Alex=20Bligh=20,=0D=0A=09George=20Ba rwood=20,=0D=0A=09namedr oppers@ops.ietf.org,=0D=0A=09owner-namedroppers@ops.ietf. org|MIME-Version:=201.0|In-Reply-To:=20<1D374B65F0C497762 A3994AC@Ximines.local>|References:=20<406156C126454795B38 BBC396D4DED73@localhost>=20=20<05576F4086A131CF3C9F4464@Ximines.local> =20=20<1D374B 65F0C497762A3994AC@Ximines.local>; bh=FaYyHaANiuYWgL+uiDhP9cgB23EWx4QjTsVaKQaB3Ew=; b=jebE2UZSux1l2I0L737xA9chUOxMpUKluQhMWqVSdSSdASroqegbpFni ZnyqSHq8YBn9UXvvqjteg0ZKDj7Pel5AxdXp/o770kirjbw++mjyM6u7/ dQnyT3jP+IcwlDT; X-IronPort-AV: E=Sophos;i="4.43,414,1246834800"; d="scan'208";a="16879826" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 20 Aug 2009 14:42:56 +0100 In-Reply-To: <1D374B65F0C497762A3994AC@Ximines.local> References: <406156C126454795B38BBC396D4DED73@localhost> <05576F4086A131CF3C9F4464@Ximines.local> <1D374B65F0C497762A3994AC@Ximines.local> To: Alex Bligh Cc: Alex Bligh , George Barwood , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft updated MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 20 Aug 2009 15:42:51 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/08/2009 02:42:59 PM, Serialize complete at 20/08/2009 02:42:59 PM Content-Type: multipart/alternative; boundary="=_alternative 004B55AFC1257618_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 004B55AFC1257618_= Content-Type: text/plain; charset="US-ASCII" > Really? Have you tested that? I would have thought they might just > treat it as a retransmission. I appreciate they /might/ do this, > but then they might also strip unknown OPT RRs (e.g. in an attempt > to stop covert communication channels). I'm not in a position to test this myself at the moment but IMHO it's extremely likely that any proxy style middlebox will barf on multiple responses received for the same request. Whilst the proxies are generally pretty dumb, they often at least create their own transaction ID. I would expect that any proxy as soon as it receives the (initial) response for any given request will immediately remove any local state associated with that particular transaction. Ray --=_alternative 004B55AFC1257618_= Content-Type: text/html; charset="US-ASCII"
> Really? Have you tested that? I would have thought they might just
> treat it as a retransmission. I appreciate they /might/ do this,
> but then they might also strip unknown OPT RRs (e.g. in an attempt
> to stop covert communication channels).
I'm not in a position to test this myself at the moment but IMHO it's extremely likely that any proxy style middlebox will barf on multiple responses received for the same request.

Whilst the proxies are generally pretty dumb, they often at least create their own transaction ID.  I would expect that any proxy as soon as it receives the (initial) response for any given request will immediately remove any local state associated with that particular transaction.

Ray
--=_alternative 004B55AFC1257618_=-- From owner-namedroppers@ops.ietf.org Thu Aug 20 07:05: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 CF6423A6808; Thu, 20 Aug 2009 07:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=-0.936, 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 LxKHcMpLnoXR; Thu, 20 Aug 2009 07:05:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 18ECC3A67FE; Thu, 20 Aug 2009 07:05:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me8DV-000K5s-Vk for namedroppers-data0@psg.com; Thu, 20 Aug 2009 14:02:13 +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 1Me8DS-000K5M-AN for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 14:02: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 D51EB2FE8CB6 for ; Thu, 20 Aug 2009 14:02:08 +0000 (UTC) Date: Thu, 20 Aug 2009 10:02:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow Message-ID: <20090820140203.GA6466@shinkuro.com> References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <200908190202.n7J22PdU007627@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: <200908190202.n7J22PdU007627@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Wed, Aug 19, 2009 at 12:02:25PM +1000, Mark Andrews wrote: > Named just falls back to something that works. It tries EDNS@4096. > If that fails (times out), it tries EDNS@512. I just want to highlight that step 2 is controversial. In particular, the claim that EDNS0 at 512 "works" is the one about which people disagree. As usual, this all hinges on the value of "works". The Internet has made even more true than ever the observation starting, "The nice thing about standards…." A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 20 07:16: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 671C73A6EF6; Thu, 20 Aug 2009 07:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.758 X-Spam-Level: ** X-Spam-Status: No, score=2.758 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFdyuPxyHoey; Thu, 20 Aug 2009 07:16:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 735E23A6EEB; Thu, 20 Aug 2009 07:16:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me8O3-000LgI-UK for namedroppers-data0@psg.com; Thu, 20 Aug 2009 14:13:07 +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 1Me8O0-000Lfe-6a for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 14:13:05 +0000 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Me8Nz-0008Gx-5b; Thu, 20 Aug 2009 15:13:03 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Me8Ny-0005xs-KF; Thu, 20 Aug 2009 15:13:02 +0100 Message-ID: From: "George Barwood" To: Cc: "Alex Bligh" References: <406156C126454795B38BBC396D4DED73@localhost> <05576F4086A131CF3C9F4464@Ximines.local> <1D374B65F0C497762A3994AC@Ximines.local> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Thu, 20 Aug 2009 15:13:05 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Alex Bligh" To: "George Barwood" ; Cc: "Alex Bligh" Sent: Thursday, August 20, 2009 1:41 PM Subject: Re: [dnsext] EDNS Page Option draft updated [snip] >>> 4. I wonder if the "Send All Pages" bit falls between two stools. You >>> say its implementation on the server is optional. However, when/how >>> would the client know how to set it? >> >> The client should not set it if there may be a proxy that doesn't >> understand the EDNS Page option ( i.e. all proxies in practice ). >> Otherwise the client should set it. > > And the stub resolver client, presumably, needs to discover this somehow? It can do this by setting the bit, and then observing that only 1 packet is received, even though the server has set All Pages Sent on a multi-page response. After this has happened a few times, it's reasonable to conclude that there is a proxy in path that will not pass multiple responses. >>> But another way of doing this would simply be to make it *ALWAYS* >>> send all pages, then delete all the stuff about the cookie and >>> so forth; this is no less secure / DoS prone than the existing draft >>> if >>> "Send All Pages" is set and respected, but is far, far, far >>> simpler. >> >> This doesn't work with proxies that truncate at 512 bytes, since they >> will >> also not proxy multiple responses for a single request. > > Really? Have you tested that? No, I haven't. But that is the natural way for a proxy to proceed, IMO. Once it has got the response, why would it retain the state required to forward a second response? > I would have thought they might just treat it as a retransmission. I > appreciate they /might/ do this, > but then they might also strip unknown OPT RRs (e.g. in an attempt > to stop covert communication channels). I hadn't considered that - it's possible, where the ISP is trying to stop DNS tunnelling at a public access points. But home and small business users should be fine. I guess DNSSEC records can be used for tunnelling in any case, so it would strip those as well, so DNSSEC is in that case impossible I think. George > -- > Alex Bligh > From owner-namedroppers@ops.ietf.org Thu Aug 20 07: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 E11FD3A7012; Thu, 20 Aug 2009 07:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.920, 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 ebtS+BAkM4nL; Thu, 20 Aug 2009 07:36:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 023273A701E; Thu, 20 Aug 2009 07:35:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me8ft-000Orv-2U for namedroppers-data0@psg.com; Thu, 20 Aug 2009 14:31:33 +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 1Me8fo-000OrA-2P for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 14:31:31 +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 AA45E2FE8CB6 for ; Thu, 20 Aug 2009 14:31:26 +0000 (UTC) Date: Thu, 20 Aug 2009 10:31:25 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow Message-ID: <20090820143124.GG6466@shinkuro.com> References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> <87bpmbzq85.fsf@mid.deneb.enyo.de> <200908192342.n7JNgJwT025054@drugs.dv.isc.org> <87y6pf9u17.fsf@mid.deneb.enyo.de> <3efd34cc0908192304u663a3f11oeae8ed3e8e197bc7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3efd34cc0908192304u663a3f11oeae8ed3e8e197bc7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 20, 2009 at 08:04:52AM +0200, bert hubert wrote: > GOV operational numbers would be very interesting given their >1470 > NXDOMAIN responses. It would be *really* good if they could share > their experiences (perhaps on dns-operations). I have reason to believe (but not personal evidence) that Requests Have Been Made. I have no evidence one way or the other whether those requests will be satisfied. As list moderator, I agree that an operational forum may well be the best place to deliver those statistics. If the zone operator wanted some control over who got them, I have a hunch (but I haven't asked) that OARC might be co-operative. It would be quite a bit more helpful to the DNSSEC community, however, if they were published in a more-accessible forum. Some of us aren't OARC members, and likely don't qualify to be. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From otherwhiles@lapook.com Thu Aug 20 08:53: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 54E0928C0E6 for ; Thu, 20 Aug 2009 08:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.092 X-Spam-Level: *** X-Spam-Status: No, score=3.092 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyzDn+KeHQVc for ; Thu, 20 Aug 2009 08:53:00 -0700 (PDT) Received: from zqxm.tiscali.it (unknown [82.84.141.27]) by core3.amsl.com (Postfix) with SMTP id 0AD153A67FE for ; Thu, 20 Aug 2009 08:52:57 -0700 (PDT) Message-ID: <466E8D4A.4090106@lapook.com> Date: Thu, 20 Aug 2009 17:53:05 +0200 From: Harwick User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: dnsext-archive@lists.ietf.org Subject: l instability.' Psychological te Content-Type: multipart/mixed; boundary="------------050806030602030803010908" This is a multi-part message in MIME format. --------------050806030602030803010908 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Ybody know where the nearest Army headquarters is?" "There's a recruiting station down on the thirty-something floor," Quillen said. "It's probably closed, now, though." "Ground Defense Command; Midtown City," Leighton said. "They have a medical section of their own; they'll be glad to get Dr. Rives, too." Melroy helped her on with her coat and handed her her handbag, then shrugged into his own overcoat and belted it about him, the weight of the flashlight and the automatic sagging the pockets. He'd need both, the gun as much as the light--New York had more than its share of vicious criminals, to whom this power-failure would be a perfect devilsend. Handing Doris the light, he let her take his left arm. Together, they left the room and --------------050806030602030803010908 Content-Type: image/jpeg; name="semeiology.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="semeiology.jpg" /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDADIiJSwlHzIsKSw4NTI7S31RS0VFS5ltc1p9tZ++u7Kf r6zI4f/zyNT/16yv+v/9////////wfD/////////////2wBDATU4OEtCS5NRUZP/zq/O//////// ////////////////////////////////////////////////////////////wAARCAEgARwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSpaSi gQDpS0g6UHigBaSkJppanYVx+RRkVEWpN9OwXJ6KiEmKkBDDIpWGmHeijvS0gEpaKSgAoHSigUAG KKWkoAPwo59aM80ZoGHPrRn1paSgBaKQUtAg7Ug6UtJmgYYoNGRQTQIQ9KXFJS0ABooxRn1oAKT+ IUtJ/EKYC1j6x/x9L/uD+ZrYrH1j/j6X/cH8zSGbFFLRQITOBTSaGaomeqSJbFZqYWphbmmkk9+l VYhseXA700vg03qeO9H1piuO3VLbyfvNvrVcmpLUbps9lGaGtBp6lzvRmjvRisjUWikpGbauT+FF wHUY4qElj1Y/hSfifzqOcrlJ6afSmBmH8R/GlD88j8qakg5R9LSAg9KWqJExQDS0hoAKWkpaAEPA oo7UUAGKPSlpDQAUtJRj1oAKKKKADHpSfxCnU0/eFMB1Y2sf8fS/7g/ma2OlY+sf8fS/7g/maQGx SOcD606q8z/MR6cU0ribsI71CzH8qD831pPr3rRIybAjJNHFGaTNMQuaaTSE0mc0ALyTgVegi8pO fvHrTLa32fO4+bsPSrFRJ9DWKsJ3paTvS1BQlRzHlRUtRT9FP4VM9io7jM0ZpmaASawuaWJKWmA8 0uaq4hwNPV/Xn3qIMCOtGaalYTRP15HSlqEPg/55qRWDex9K0UkyWrCjqaWkHc0tUSFJS0UAJj3p hkUdOac/3DioVR27YHvQMcJT9KkQ5QUxYgB8zE1IpAwoHFAC0lGaOtAgzRjJzRRTAKx9Y/4+l/3B /M1s1jax/wAfS/7g/maQGzVCUkOwPrV+o5YUk5PB9RVJ2FJXKOaTdVj7GezCj7G395avmRnysr7q TJNWxaDu/wCQp620Y65P1NLmQ+RlJUZ2woJP8quQ26x8n5m/lUqqFGFAFOqXK5SjYSiloqShO9FH eloASmuu9Sv5U6jvStcaKecHFKD6U+4j/jX8agDVztWZstSXv+FAOCP1pgNO3UrgLnA/Glyc4pua Mii4Ds0b8HI7UwtTCxJwOpouFi+pDKCO9LTUXbGoPUClrqWxixaKSigQjPg4pu40yVwjnPpmog0s krRghAoBJHXn0oHYnzTI23XXX5dpA/OoELSRlGYs4cqrDjOO9TwIQ65AG0FeO/vQO2hPRS0lBItJ S0UAJWPrH/H0v+4P5mtisfWP+Ppf9wfzNAGxRS0UAIOlFRSzCJ4lKkiRtufQ9qrzTv8AawABsWRE 5GRk8kj37UAXqiluIos75AMdR1IqneOZRKIgTIjAAZO7Ix0Hb696bOsvl3Fuqhnkl3cMDwcY/l3o GXfPBuGhVHZlxuIHApFuQZkjZQC+cYYHpSiDE1w5b5ZQBgdRgYpkdoEkibfnygQPlAzxjmgCzRRR QITvS0neloASjvRQetAxD1FQS2+fmj/Kp8ZFJ8wHqKTimNOxQOVPIxS7qvHa4wwH41GbWNjkZFZO my+ddSruo3VObQZ4enLaKOrE0uRj5kVhlzhRmrUEAj+Z+W/lT8LGuEGKfVxhbchyDNFLSVoQFLSU UAQzIHfnsQarmMPdSk7ui9DjNWJHUSkFwCMcZqJ54l/5aA/Q5oKHqu0AKMAcACnoQsignlunvVQ3 LMcQoSfU/wCFS2sDed5krbnA/KkNruXKSiimQFFLSUAFY+sf8fS/7g/ma2axtY/4+l/3B/M0AbNF FFAEU8IngKHg9VPoexpI7dVjVXw7B9+7GMt60+RxHGXIJAHaorWRpYstIGODkDqOaLlKLtcnGOcY 681HPL5MZfaWxTLTAMqA8iRuM5OKWZXmt9oXaW67j05pX0K5bSs9h0zuroEHBzk7ScUsTh1PzZwS DkYxSkOQCGCnuAMg0kaCMEcksxYn3oE7WH0ZoopkB3oo70YoAKDmiigAzUAndrh40i3CMDcd2Cc+ lT1EUKSmWNd24AOM4Jx0IoAcrrKAVBIIznH+eaXBHQ5FV1lb7bucMieRuKsemDR9sURtyjNsZlI6 HAzyOooGWQ3PPFL9KZE/mRoxQjcgbPb6U7bjocUANbvT6Yc80+hgLSUUUCDvS0lFAFW5tVkl3tnn uKZ5EMeA3XsD1P4dTUjzG3uyZG/dOmVz2I6gfhVdI5Eks84ErmRmJHcjuKViuZkomhRVPIQsVZsY 2ketI0knlQOCUEk64A/unpmpDbHaI+GSRy8p6ZPUYHpml+zxpDtlJZFbcu4n5fQUxbk4dWYgEEr1 x2paZGeMKm1AOO36U/rQFgozRiloATPtWPrH/H0v+4P5mtjOKx9X5ul/3B/M0AbFFFLQIaQdvGM+ /SobaDy4xv8AvldpHoM1OOlLRYpSaVhoAHAAA9BS96P4qO9AmLRRRQIKSlpKADvS0neigAoopaAE qus7/anjZDtVeMc/jVmqskcxud8fPy8EnAHPTjrSZcLbMsblJKZBPcZqrLZF9ux8BVZVVu2RjrUk pH2yEdxu7e1SSyCKJnIzjtRcTjtbqUzHMkgVDsYWwXcemQatwOW3BmyVOCCMMPr2/KnBg5KMuCOS ppEhjiLGNQpbrimJjh1NLQBS0CEooooBh3paTvS0ARSLFPmOQBthBIPY9qSS4CBjhmCnDEY4qvDi O7dTiViww2eR15/xp5idkmiKkb5M7uMYyKm5tyJPUsSOI0LHOB+tVEy7TiXLA7S2ARj2A/z61c5D MSw29hjp61GZVDMY0MjEBjsx07c02rkxkoiRxjzzIAQNu3nqeev/AOunyyrEAWySWCgDuT2qGG68 65UJnyzFuwRzndiq4iaROFJU3ZbI9PXNMlu5cimd5JUePbsIAIOc5Gak5NRQW/kFgrlozyFYcg/W pqBBisfWP+Ppf9wfzNbNY2sf8fS/7g/maANmiimlgOO/oKBCjpQTjrTfmP8Asj360oQdTyfegBN+ T8oLfSj5z/dX9ad/FUdzN9ngaXbu29s470DH7WPVz+AxRs/2m/Oqkl48SRSvGvlSY6Hlc8/405J5 J7qWOMhUi4Jxkk/5zQBY2f7TfnRtPZ2/SobO4aYSLIAJI22tjof84NRxXrfamilUBS7IjD1HY/mK ALXzg9VP6UbsfeUj9agN7GiyPICoWQxgDnOKmSVXJHKkDJDDBA9aBDwQwyCCPaikKgnJHPr3oww6 Hd9eDQA6k7UgYE46H0NKOlACMoYYYAj3pGQtuycqVI2HoT9adRQNMriKR5nJyAYygLEZz+FJGxjk hj5GVIYH1A7VZpqxIr7gvPQe309KVi+e+46oppzHLFGqbjJnvjGKlqvcwNJLC4AYJuypOCcimQPN wiMiyKyNIcKDg/yz604zRh9hcBgQuPc9KqzW3nyQq0cgjG7dubJHAxzk1WHm+ezTKdwmj3EDg4B5 oA1WIUFmOABkmm+dH5Pnbx5Y53VXupBOqQxZbe3zdvlHJ5qFo5RKVETbFkWcKOeO4Hv6CgC0HSPz XEUikLuOVwDilimMmws0a7hkJnLHjPt/Ko2jlleYguEaIqFc/wAR9qfBG8EShvKRVX5sDrx1zxQG 5FN5huPIZ8xTnj1XHJH406IyxvOpidmMhZScYx25z7VI8kP7qQ4bL7EYc8niopJp3a5jiUbowAoH U57/AJf5NAD47OJFjAJ3RjG4EgkH/JqdQFUKowBwBUEOFumXyAh2bt+cnr0J/wDr9qsUALRRRQIK xtY/4+l/3B/M1s1jax/x9L/uD+ZoGa5BJ64Ht1pQoXoKWigQg6UkjiOMu3QUo6VXnIlmWL+FPmb+ goZUVdjUuJFlUTgBX6Y7Gn30bS2skaDLHGBnHcU24UOm1vwpbOYuDE/30/UUky5R0uiL7NJNFBHI AiRAFh13Ef5NSi3aO4eWIgeZ95T0z6/z/OrNRlyJwp+6VyPrTM9yO1t/s6tzvdzlmPc/5zTDaFoZ 0LAF5C6n06U5J2MUrN1Xlfp2qRXYSqjY5TOffvSuU4tGeLS4WJZGXdLHKX2gj5hx/hUlw6y39t5O GYcMfb0/LNW45w6uxGAufxHrUiurHjqQD74piaaKMYYanNFG5jRVBCr0B47dKvSSLGhdztUdTTFt 0W5acZ3su088dv8ACotRgae12pyykMB6/wCc0CJkkjmTKEMKXaR90/gai2RzNbyxv5ZAyoGOV4yM f5xTNNnknty0hywYjOMdhQBZ34+8Cv16UtNEqM5jz8w/hIwT/jRtx907fbtQIUHk8UtMDbSdw/Ed KfwRkc0DCijHvRn2oEFLSZFGRQAtQ3crQWzyKASuMA9OtS5qK5iE8DRbtu7HOM96AIXmlV5lEgdV hLBgOh5pgUtZGQxcmIku7Zb7vbr/ADFXGRDGyYwrAggDFMSGOMqVQZAwCTkigZRjt5lFr5fzQkrI R/dPergtyZZ3dvllwMKcYx05qekLBepAoEIiKgIUYz1Pc/U07IAJJwKblj0GB6n/AAoC85PJ9TQM UNk8A49TS59KMUtACY9ax9X/AOPpf9wfzNbNY2r/APH0v+4P5mgDZooooEMdxHGXboBVePKRNIwy xBdqW4O+RYuy/M39BUu39w/qyml1NFpEpWVxLeNIrkcDIwOlMcskgZeHU/5FLog+aY+wqe/i48xB yOtJoqnJbMsxSrNGHXoe3pTLlWKq0fLA/wAxVG0uPKkwx/dt19j61qcU1qiWuSRXljO+NVHykAN9 Aadc5VVdQSVJ/UYqbApGO3nBPHQDmiwubYqyrsZYh0kUL+R5/SppCI5kfoMFT/P+lJHdQSjeHGF6 luMfnT5Y1mj2k8dQRRYfNfchjcxRSFuuN4/H/wCvVhclRu645qKaEvIhGNo4Ye3WpQwLMvdetCFK z1IhDbzskwUEg5BHHNR2sLWcZTBkQnduUcj8P8M02B/JhHfeuVHv0/wqe3djEfMOSrEE0JhKNipK Y59WhAKuuwg/Xmn211cTxyTBUKqThO574/l2qwPKuAHHJXow4IpnlyQGVoV3+Zltpbo3+HSmTsOh uI5CoDYZxuCng98/yNSlATnofUVl3Ek/22FxFibyz8mc/wB6rliHaITPMZDIM47CgCx847hvrwaT fjqGH4U6oxcRFtu8K3o3yn8jQA8MrdGB+hpaCob7wB+oppjT+6KBDuPajim+Wn92jy1/uL+IzQMD Ig/iFIWJ6Kfx4px+VScgD8qiW4hdwiyoX9AetAEmGPU49hShQuT09SaiErSSyRJhTHtyx56j0rPL tcaZNLKdzhgAT26dBQBpLIHI8tS47t2/+v8AhWc92J7OVpWIYnaqKcD8f/r+lW7XYYocs0jBV4HR ePb+vNLY2xgtjHLtbc2SOo7UASWoAt0CyeYAPvZzmpqaiLGoVFCqOwFLQIKx9X/4+l/3B/M1sVj6 v/x9L/uD+ZoGbNNdgiMzdAM06ql9JgCP/gR/p/n2obsOKu7EULvJOf8AaOW9var4Ixz0qlbBY497 nBb1pZL1QCEUt/KpTstTSScnZDdOaANKkG49yx7irTsoHzEAe9ZkZcZWEbc9QgyaeLOd+WGPdjRc XJbdkMwRJWCHK1oWE3mR7GPzp+oqJdNP8Uij6DNT29msEm8OScYxQkxzlFqxYpGYJ8zHAFLikxyK oxMiLjSJ1PXf079VqaaV7SGa33lSuGiOeduen+f5VoMivkMqtkdxmorq1julAfII6MOtAXHXUxt1 WTblN2H9QPWntLGjhGdQx6Ank04hXBUjIPBFZtjbuInmZX89AVQN2444/GgDQWNFVQBwvT2quwdY mjA+aRzj6VFavMtj9oMjSHqVb0HB/kasQXcU8hjTOQob8OP8aVilKwQnbMV2FAVBAPtx/hSuXhXI O8ZwFPX86kZNzKc4KnNMCM05d/urwo/rQVdN3F3R+Zhiu4dM9RVa5guFcNaMQHfcwzwD6/T1qYri RyU3q3XHan27FoFJ+nNCE1pdDyQiZYkgdTj/AArH1RlmuQYiHCpyV5A5P+NarTBZxGR1HB/z9KeC pZhxn+KmTZoz7t2j0y3ZGKn5eQcfwmnTzSpPMJndFA/d7Bx9TU/2KD5RtJVDkKWJFI9pnzdsrKsv 3h1+tAFe7eWGyjkWcsxIG5TwRg1oKuwY3M3uTmoJrOOS2SAEoqnIx+P+NWaAMy2VpLu6OxHKvgF/ 4eT0pDa/aZrpXYeYNpVgMDOD9eKuC1hVnYA5c5PzHn8KlRFRMIqqPYYoEVbBJxJNJcLhmKjPHOKf b2aRWxhc+YrNuORj0/wqzQaBiABQFUAAdh2pelGKAKADmjFFFAhaxtX/AOPpf9wfzNbFY+r/APH0 v+4P5mgZsEgAknAHJrKlcySFum49/wBK05E8yNkJK7hjimpCkQJUZbH3jyaTVy4SUdSjHayygHGB 2Lf4Vajso1+/lz78CrA6CjIFCSQSqSYihVGFAA9AMUDJOfyqKS5ij4Zx9OtV31FP4ULfWqszMvfj Rx61mG/mfPloOBk45wKZ9um9R+VPlYXRrcetJ361lfbpvUflTlv5R1CkUcrC6NTvRVBNRH8SEfSr Ed3E/RwD6GlZoCfrRzSAg0v60gK0lswikjgZYxJ1BHA9cVBa232O8UMeJI8A/wC1xkVoU1wuw7gC uOQRkUAZBuJIWuXibH74e4P3q1FmKyiKUAMwyrDo3/16q+VBd23lQgREHd07/wCTSywJDeRzMCYu gGeEPY/SgbTTsy00e9idzL24PWnAeWqqi8Zx9BVO/kdJ7fazDLkHaeo4p8V5+9mRgWWJd27GCRjo R6/lQO5JIm+4Ze/ljB9Dk0W7+ZLI3TIXI9DzSxXUUqqwJXdwNwxn2Hr+FSLGqOzKOW60rD5tLFW3 CCJCUdTjqO/5VLMpDJiRwGfBGaWOOWJQoZWA9RinyoWMeP4WyaLaFOXvXFWPaMbifrS7adSDpTMg 2ig9KWmsQqksQAOpNAC9qB60UUALSUUlAC0Z/GkpcUAIelZGr/8AH0v+4P5mtg9DWPq//H0v+4P5 mgaNimSSJGpLEAe9OfpWPFuuJt0rEhRk5ppC2Lr3gIPljIH8R6fhVOWaeYO24lFwTjjGaf553/KP lxwo9KZazrFM4lGY3yGHWqStqTzXdhws9rOrtyGVRjoSfenrZoZFVmILlgMDpjNRPeO6xZ5ZG3En +I54pR9qlIIDDBJBHGM9eaeoyeKIRxOVXO63LFvc9qHSBdxKrsUpsI6sO9QrZTMAGIAHYmnfYG/v j8qV13Alkjt1WXG0lAenqTx+VRXUSLEjooXJxg5z0/I0v2Bv74/KmmxkHQqaLruA9YRNFbKNqs+7 LBfSo0tS+SG+UoWU4647U7F1EVxuO37vfHampcsiCNl+UKy++DT9AGJLJE2AxGOxq1Ff/wDPRfxF NjljMKx4DYLAgnBOeh9P6+lIbZHaFFYq7oD0yOh/woduoF+OVJBlSDUV6+y3Izy3FZxDREMG68hh 3pZJnlUBznFZzVka0lzSRc05MIznucCrlVrSWPylRWGQORVkUkrIVR80myCa3WdkYkho2ypH+fao ZbecyTS7kwYiuEXl+D+v/wCqri9TS4pkmSyzLpsSsFCFsElSDHz1qe286a6mE0rjy8KAPlz7/p+t XmXcpU8gjBBqEWqIwaLMbAYz1yPfP0oEVvts620h+QyQuFbjgjpn86lOoIblVTDRHAL+hPSlFki2 ssQYs8gyWY9T2/Wok04LYvExUysd2R6jp/n3oGO/tDEU0mzKI21CP4v88Uk93cRIWEcbKFBJDZwS aWO1li0/ykCeYTlg3IP+eKil09pWcoFhG0BVB4PPOaALMEpkWNmkkJIBIVPl/PH9az0ffYSvJG0r 7sbzzt4HetOJJY0RS6bUAHCnJx75/pRbQLbxbI92Cc5JoALXyxbRiN96gYz61L+lCqFXCgKPQDFL 0oEGKKKTIFAC5opiSK7EKc460+gAPQ1j6v8A8fS/7g/ma2D0NY+r/wDH0v8AuD+ZoGa79Kx4/lty AMl25+grYfpVOO2jhXnLn39fpQBVVXkBECYB6t61LHYKOZHz7CrYjdh8x2DsB1oaEAZDFvrVOTZK ikMVYovuKM+w5p4V5BnOxfXvQqDIHSpCS33RmpKGeT6SnNIpIOG6ipmX5cjgiotwdgfagCOMTSRh wygEkAYp22cdkP5imLL5Voh9z/M1LE0juUcNtxnOMUANLSL96Fv+A800tFLw20n0Yc1ZDhdqk8nO PwoxFMoOFcEcGgClJZIfuEqfzFQeXNbuHHO3oRyBWgbbbzE7L7HkVG+9QRLGSCOqcind2BWTuVoL hVVUYY2qwBPvUDENISRgewHFKoTa+7qBwRSxJIQXjGcde/6VF+ayOnl5OaX3BFFvR33BdmOvvUkd 3JH8rYYD3psEvlpIhyu/HzDtipUijkRCzKT83CDlh/n9K2fmchYiuo5O+D6GpgfQ1mPAUUMCGyoY juAaczyWspQPkLU8vYdzS3etLmqUd9/fX8RU6zxP0YUrNATUYpuR60fjSCw7AoApvPrR+NA7Dj0N NB+UUhIA5P61G1zEvQ5PtQBP2pCwH/16pveE/cGPc1Azs/3iTVKLFcuSXSjhfmqrJM8nU4HoKjpa pJIVy1Y/x/Uf1q3VSx/j+o/rVuoe40B6GsfWP+Ppf9wfzNbB6GsfWP8Aj6X/AHB/M0hmu/3ajQc7 z9BUjjIxUSucrxkDtQBIykgYHJqN2KEjIPHNOZjIQBkCkCKW2jGB1piEdSqqe/Q0oV9mAx+lSMVI IPIqMts6Pge4pDFIZl+bIApqjAJ9f5UZ3HPL/QHFL8391vyoAiWDfBHkHIJ4/E1LGBGSdrEnvkGj Lf3Wo3EdQw/A0BYJY2mgwvytk4J7dR/I1CYGjLNt+WI5jx6Zyf8ACphJ6EU8SUAVUnlQY6sMyNns uM4/Mn8qsrcIzOOmxgufXPH86d8jEkqMkYJ9qhFqEaMxncqA5BPLHnH8zQBXvLaQzl0UkN6VF9mu FXIRgParTB43kkUlWMqgZ6EEAVMkxCv5nJV9pKqeeM9PxqeU2VZpWKFvH5jnfgg9eeRTntXRt0Tf TnBq7J5EiBmK4JwGzjB+tNMUqfdIkX34NUtDKT5ndlRrgqNpiw3l+Xkmpd8c7naASzrkN124p5KS fK64I7MOaiezU8ocexqromwx7dAqlHOWYhQec84prW0isBjdk44pGimjx1IU8Y5xT0uQJQ5U9SSA eO/b8aoRCCyHglf0pwmkH8ZphYscsST6mimIk86T++aTzZD/ABt+dMoosApJPU5oopQCTgDJoAKK kS3kbtge9Tpbov3vmpNodisqM/3QTU6Ww6uc+wqwBx8o4/SnBPXmpcmOwkYAGFGBntUlMT7zY9f6 U+pAD0NY+sf8fS/7g/ma2G6GsfWP+Ppf9wfzNAzXbpUeMElcEHse1SP0pgRj944HoOtAAznvhfpy aAGIwBge9PVQoyB+PelFAhgiH8RJ+nFOCqp4AFLR3oAWkoooAKKKKAEIDHkA/UU0xDsSv0p/eigC Mq49G+nBoD8+/vwakpGUNgEA/WgYbgwwwB781HJCGBKEg7t5GSM8Y/ClMZH3Tn2NIGKkAgj60ANi BginaVeMluTnIwP8KRQ8EMajAZ25zyFz2A9KmD5GD096JFEqbcgfUZB/xoAAFnUiRQSpwR6GmG3Z f9U//AW5FLDH5KMD1diflHA4/wDrVDDM0ccZkcuph8w56jGP8aAHFpE/1kZx6ryKTMMv91qeboCJ nZTlV3YByCPYipWjjlAYqrA8g0AVTaxHoCPoab9kXsxqz9lj/hLr9G/xpPszdpnx74p3YWK/2Rf7 xoFondmqVoWB/wBc35UnlHvM/wCFF2FhBbxj+HP1NSKAPuj8hTLfmNc9yev41K0gV1UnHek2GwBS fakx82Dzz/Sk85TN5fJPqKX+P8f6UBcc7lOSMr3PpTEcPlgQT6egoZC7LnGwckep/wAKXbGjlgoD EYOKB6WHKcFs+o/lTsk9BTU5JPqafQIQDPJ5rI1j/j6X/cH8zWwO/wBax9Y/4+l/3B/M0AbNJRRQ IBzRR2ooAKO9LUEl3BH96VfoDn+VAE1FUn1S3X7odvoKj/teP/nk350AaVFZv9rx/wDPJvzp66tA cbldfwzQBe70tVkvrZzxKo/3uKsAgjIII9qACilpPSgAoxkYIyKKB0oAYYx/Ccex5FNyU+8MfyqW igBqvQypJncAcqV/A0GMHkfKfao/mB6Z+n+FAxr2uUl2lSzIVB24P4nvVoHIBII9j2qEPz15/WnC SgCSimhxS7hQBFOGKkIcN2JFV7bzzkzkDsAB+tTSmQt8iAj1Jpn78/woPq1ACW/+rX6n+tS+Wvme Zj5v880yNDGigkEgk8VJuPsKAESPDs2AM8DHpR/Fkc8/0pCcnGSx9KcEY+ij86AELHucChVZvujA 9TT1RVPqfU06gBFQL3JPvS0mfQUo5oEIO/1rI1j/AI+l/wBwfzNa47/WsjWP+Ppf9wfzNAzZpKr3 F9Db5Bbc/wDdWsu41GabIB8tPRf8aBGtNdQwf6xxn0HJqhNqzHiFAvu3P6VnE5OTRQMkluJZv9ZI ze3ao6KKACiiigAooooAKdHLJEcxuy/Q02igC9DqsqkCUBx69DV+G+gm6PtPo/FYVFAHT0g6Vg29 9Nb4Abcn91q0bfU4Zflf923uePzoEXaKAcjI6UUAFBAPWlpKAGsgPv8AXmmmMjpkfjn+dSUdaAIt reoP1GKT5vQfnUp7UuKBkPzeg/Oj5vRfxNTYHpRQBEFYn72Pwp4iXvlvqace1FAAAAMAYHtRj0oo oEJnmjvil70mDnigB1IOpNNeRUUtIwVR3JqjPqsajEK7j6ngUAX8gAkkAZ71i6pKktyDGwYBcEj1 yagmuJZ2zI5Pt2FR0DP/2Q== --------------050806030602030803010908-- From jerrileeraddie@21plus.org Thu Aug 20 09:27: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 9AAF03A6AA9 for ; Thu, 20 Aug 2009 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.587 X-Spam-Level: X-Spam-Status: No, score=-21.587 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_IS_SMALL6=0.556, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6hSNbx55J-u for ; Thu, 20 Aug 2009 09:27:00 -0700 (PDT) Received: from adli.es (unknown [187.11.146.113]) by core3.amsl.com (Postfix) with SMTP id CE86D3A6A4B for ; Thu, 20 Aug 2009 09:26:58 -0700 (PDT) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090820162658.CE86D3A6A4B@core3.amsl.com> Date: Thu, 20 Aug 2009 09:26:58 -0700 (PDT) Click here to view as a webpage. From owner-namedroppers@ops.ietf.org Thu Aug 20 13:36: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 5A19E3A6DAA; Thu, 20 Aug 2009 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=3.744, 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 C9Rw86n0J6aB; Thu, 20 Aug 2009 13:36:33 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A01A73A6CF5; Thu, 20 Aug 2009 13:36:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeEHG-0008Pj-NO for namedroppers-data0@psg.com; Thu, 20 Aug 2009 20:30:30 +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 1MeEHD-0008Ok-7y for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 20:30:29 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7KKURHq019869 for ; Thu, 20 Aug 2009 16:30: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 n7KKURF0019868 for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 16:30:27 -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 1Mdw3H-0009iY-7Z for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 01:02:53 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Mdw3A-0003eo-RG; Thu, 20 Aug 2009 03:02:44 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Mdw3A-0001k0-8i; Thu, 20 Aug 2009 03:02:44 +0200 From: Florian Weimer To: Mark Andrews Cc: Doug Barton , bert hubert , Paul Wouters , namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> <87bpmbzq85.fsf@mid.deneb.enyo.de> <200908192342.n7JNgJwT025054@drugs.dv.isc.org> Date: Thu, 20 Aug 2009 03:02:44 +0200 In-Reply-To: <200908192342.n7JNgJwT025054@drugs.dv.isc.org> (Mark Andrews's message of "Thu, 20 Aug 2009 09:42:19 +1000") Message-ID: <87y6pf9u17.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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] * Mark Andrews: > In message <87bpmbzq85.fsf@mid.deneb.enyo.de>, Florian Weimer writes: >> * Mark Andrews: >> >> > The traffic went from .1 connects/second to 60 connections/second compared >> > to 6000 UDP requests/second. >> >> For .gov? > > ORG. I don't believe GOV has published statistics. Okay, I just had to ask because of the subject line. 8-) From owner-namedroppers@ops.ietf.org Thu Aug 20 13:36: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 C8F413A6CF5; Thu, 20 Aug 2009 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.556, 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 xxKLv4M1Gu3l; Thu, 20 Aug 2009 13:36:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC4F03A6EFB; Thu, 20 Aug 2009 13:36:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeEH1-0008Mu-75 for namedroppers-data0@psg.com; Thu, 20 Aug 2009 20:30:15 +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 1MeEGu-0008LZ-OA for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 20:30:12 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7KKU8el019856 for ; Thu, 20 Aug 2009 16:30:08 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n7KKU8Fc019855 for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 16:30:08 -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 1MdoeF-0009ss-Ud for namedroppers@ops.ietf.org; Wed, 19 Aug 2009 17:08:34 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Mdodv-0004jD-Hz; Wed, 19 Aug 2009 19:08:11 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Mdodu-0000Dd-EU; Wed, 19 Aug 2009 19:08:10 +0200 From: Florian Weimer To: Mark Andrews Cc: Doug Barton , bert hubert , Paul Wouters , namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> Date: Wed, 19 Aug 2009 19:08:10 +0200 In-Reply-To: <200908190546.n7J5kZJr009870@drugs.dv.isc.org> (Mark Andrews's message of "Wed, 19 Aug 2009 15:46:35 +1000") Message-ID: <87bpmbzq85.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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] * Mark Andrews: > The traffic went from .1 connects/second to 60 connections/second compared > to 6000 UDP requests/second. For .gov? From owner-namedroppers@ops.ietf.org Thu Aug 20 14:05: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 5CA573A6F77; Thu, 20 Aug 2009 14:05:24 -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 xt9lJYruAqz6; Thu, 20 Aug 2009 14:05:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1EE828C1CF; Thu, 20 Aug 2009 14:05:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeEkr-000DQt-QJ for namedroppers-data0@psg.com; Thu, 20 Aug 2009 21:01:05 +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 1MeEkm-000DNq-4S for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 21:01:03 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id DC97618C7F for ; Thu, 20 Aug 2009 17:00:57 -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 D3D7D2420FB for ; Thu, 20 Aug 2009 17:00:57 -0400 (EDT) Date: Thu, 20 Aug 2009 17:00:57 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: DNS-OARC (was Re: [dnsext] all .gov do=1 nxdomain answers already appear to befragmented.. and it works somehow) Message-ID: <20090820210057.GI14855@dul1mcmlarson-l1.labs.vrsn.com> References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> <87bpmbzq85.fsf@mid.deneb.enyo.de> <200908192342.n7JNgJwT025054@drugs.dv.isc.org> <87y6pf9u17.fsf@mid.deneb.enyo.de> <3efd34cc0908192304u663a3f11oeae8ed3e8e197bc7@mail.gmail.com> <20090820143124.GG6466@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090820143124.GG6466@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 20 Aug 2009, Andrew Sullivan wrote: > On Thu, Aug 20, 2009 at 08:04:52AM +0200, bert hubert wrote: > > > GOV operational numbers would be very interesting given their >1470 > > NXDOMAIN responses. It would be *really* good if they could share > > their experiences (perhaps on dns-operations). > > I have reason to believe (but not personal evidence) that Requests > Have Been Made. I have no evidence one way or the other whether those > requests will be satisfied. As list moderator, I agree that an > operational forum may well be the best place to deliver those > statistics. If the zone operator wanted some control over who got > them, I have a hunch (but I haven't asked) that OARC might be > co-operative. Wearing my OARC board member hat, what you are describing is exactly what OARC was designed to do. OARC would be happy to accept this data and redistribute it according to its owners restrictions, if any. > Some of us aren't OARC members, and likely don't qualify to be. I'm not sure what you mean by "don't qualify": OARC membership is open to DNS operators, implementers and researchers. I think anyone interested enough in DNS to read namedroppers could make a compelling case for membership. While it would be ideal that if you support OARC's mission, you'd choose a paying membership category, it's also possible to apply as a beneficial member (which requires a yearly material, non-financial contribution, such as contributing data or presenting research). More information about OARC is available at www.dns-oarc.net or please feel free to contact me privately. Matt From owner-namedroppers@ops.ietf.org Thu Aug 20 15:12: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 C4DF03A6A0C; Thu, 20 Aug 2009 15:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjNhvBaCo-hP; Thu, 20 Aug 2009 15:12:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E5C393A6EFE; Thu, 20 Aug 2009 15:12:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeFn6-000MXM-08 for namedroppers-data0@psg.com; Thu, 20 Aug 2009 22:07:28 +0000 Received: from [209.85.216.173] (helo=mail-px0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeFmz-000MWU-4P for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 22:07:25 +0000 Received: by pxi3 with SMTP id 3so4250909pxi.32 for ; Thu, 20 Aug 2009 15:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HaR7mULFJchcBTcc6VRMTvBxYK3lzw8fv4Q4WI+tyis=; b=gXiuWySHdwq3N+fIRXDkbWEgnMia7JdgcU29+noY/eztr8vGEz/rpusVSvFZFprZly yntoiHMwUkH+w+v0i0CIQ1G/9YqCc+y6+eD4DaTl3W5hYx3Qc+ryVAttd6QYyHUiZhqh 6EeJzh5WvTVB0JEKU7jo3OTcm32iiOL5LsMRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xcbKAsDpgL91IH5vFEfYBe9M9vGDxtk3ZlHuVXDt+8bH5cTGcDyYS86JEDSed9KEXJ FUBPR15TQ6lYB3TEJAnU7zd6vWENy+Uah4nJBrLKlBFv0jje64kX8Y7CARAO+Y8pME7C QiID3KsBIohOO6c3KrgNEzhZEqNIILrW6sJ6E= Received: by 10.114.163.24 with SMTP id l24mr430259wae.106.1250806040945; Thu, 20 Aug 2009 15:07:20 -0700 (PDT) Received: from SJC-Office-NAT-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id j34sm23065waf.26.2009.08.20.15.07.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Aug 2009 15:07:20 -0700 (PDT) Message-ID: <4A8DC915.9000304@gmail.com> Date: Thu, 20 Aug 2009 15:07:17 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org, "W.C.A. Wijngaards" Subject: Re: [dnsext] EDNS Page Option draft updated References: <406156C126454795B38BBC396D4DED73@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/20/09 2:30 AM, George Barwood wrote: > At the suggestion of Wouter Wijngaards, I have updated my draft again: > > http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-02.txt > > Changes: > > Option for all pages to be sent immediately ( so response time is 1 x RTT ). This change _greatly_ increases network amplification risks! > Cookie support optional. > UDP payload size is independent of EDNS UDP payload size. Perhaps this should be described as the Path MTU, since it is not describing a payload reassembly size, which can be noted independently. > Page size limited to 4095 bytes. Why not constrain the page size to fit within the Ethernet MTU? This would limit this option to a maximum of 1460 or less. Such limit would better retain Ethernet CRC error detection performance, where the IEEE CRC Hamming Distance for small packets drops from 7 to 3, (detects two bits in error instead of six). The reduction in error detection performance occurs while greater amounts of data is being exchanged. DNSSEC helps retrain data integrity, but not everything exchanged will have been signed. As it is now, the maximum exchange this might cause would be 255 x 4095 = 1,044,225. If limited to 1460, the maximum would be 255 x 1460 = 372,300. A 50 byte query might then result in a 20,000 : 1 or 7,500 : 1 amplification. Perhaps the page number should be limited to 2 bits, instead of 8 with the payload limited to 1460. -Doug From sleepyheadtgr6@isisband.com Thu Aug 20 15:33: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 075C43A68E1; Thu, 20 Aug 2009 15:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.954 X-Spam-Level: X-Spam-Status: No, score=-19.954 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, 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_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_8627E=3.462] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH5nqIuBiKFl; Thu, 20 Aug 2009 15:33:52 -0700 (PDT) Received: from host81-149-63-45.in-addr.btopenworld.com (host81-149-63-45.in-addr.btopenworld.com [81.149.63.45]) by core3.amsl.com (Postfix) with ESMTP id A17E03A6C4F; Thu, 20 Aug 2009 15:33:51 -0700 (PDT) Received: from 81.149.63.45 by isisband.com with smtp LNL13191; Thu, 20 Aug 2009 23:33:40 +0000 Message-ID: <000d01ca21e6$4448b210$6400a8c0@sleepyheadtgr6> From: Myles Whitman To: Subject: Get ready, I am not turning back, my free trial is on its way :) Date: Thu, 20 Aug 2009 23:33:40 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA21E6.4448B210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA21E6.4448B210 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Daily=20 Newsletter dnsext-archive =20 Breaking=20 News Lose those pounds immediately A chance to visit MylesWhitman If you no longer wish to receive email=20 from us or your details are incorrect, you can login=20 and edit your profile or alter your newsletter=20 subscriptions. ------=_NextPart_000_0007_01CA21E6.4448B210 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Daily=20 Newsletter

dnsext-archive

 =20 Breaking=20 News

Lose those pounds immediately

A chance to visit

Myles
Whitman

If you no longer wish to receive = email=20 from us or your details are incorrect, you can login=20 and edit your profile or alter your newsletter=20 subscriptions.

------=_NextPart_000_0007_01CA21E6.4448B210-- From owner-namedroppers@ops.ietf.org Thu Aug 20 15:52: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 E0B5E3A6D9D; Thu, 20 Aug 2009 15:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuNzRYM3qCE1; Thu, 20 Aug 2009 15:52:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 024BE3A6D9C; Thu, 20 Aug 2009 15:52:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeGQv-0002sX-3A for namedroppers-data0@psg.com; Thu, 20 Aug 2009 22:48:37 +0000 Received: from [209.85.146.178] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeGQr-0002sA-Kg for namedroppers@ops.ietf.org; Thu, 20 Aug 2009 22:48:35 +0000 Received: by wa-out-1112.google.com with SMTP id j37so47132waf.9 for ; Thu, 20 Aug 2009 15:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.119.6 with SMTP id r6mr505669wac.45.1250808512139; Thu, 20 Aug 2009 15:48:32 -0700 (PDT) In-Reply-To: References: <406156C126454795B38BBC396D4DED73@localhost> Date: Thu, 20 Aug 2009 15:48:32 -0700 Message-ID: Subject: Re: [dnsext] EDNS Page Option draft updated From: Matthew Dempsky To: George Barwood 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 20, 2009 at 2:30 AM, George Barwood wrote: > Option for all pages to be sent immediately ( so response time is 1 x RTT ). Adding EDNS options like this stands in opposition to draft-ietf-dnsext-dnsproxy-06, which currently recommends that DNS proxies should copy OPT records blindly. If a DNS proxy unaware of the Page option blindly copies a request with the Send All Pages flag set, it won't know to forward the subsequent response packets. People have expressed concerns about the Send All Pages flag, but I don't see anyone arguing a priori that EDNS options cannot alter the response format this way. If no one feels that way, then I think the dnsproxy draft should be updated to require DNS proxies to strip unknown option codes. The EDNS RFC says EDNS options are defined for hop-to-hop purposes, and I think it's a mistake to try to handwave a DNS proxy as not counting as a hop. The HTTP RFCs go to some effort distinguishing which header fields are hop-to-hop versus client-to-origin, so that HTTP proxies and caches know how to handle them. I think it would be a good idea to standardize a way for DNS proxies to know whether or not an unrecognized option can be handled opaquely. From anthraxcx3@cable200-58-221-167.epm.net.co Thu Aug 20 17:49: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 728973A6A4D; Thu, 20 Aug 2009 17:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.995 X-Spam-Level: X-Spam-Status: No, score=-77.995 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_4BF4C=0.161] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZLvqwnOwWuL; Thu, 20 Aug 2009 17:49:40 -0700 (PDT) Received: from cable200-58-221-167.epm.net.co (cable200-58-221-167.epm.net.co [200.58.221.167]) by core3.amsl.com (Postfix) with ESMTP id E8D5C3A6CD6; Thu, 20 Aug 2009 17:49:31 -0700 (PDT) Received: from 200.58.221.167 by reidlawfirm.com.s5b2.psmtp.com; Thu, 20 Aug 2009 19:49:39 -0500 From: "Latisha Gadberry" To: Subject: New job Date: Thu, 20 Aug 2009 19:49:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6Q2UEI8TFY8FTIMDS0Z5QQAROO4== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <01ca21cf$5ac77b50$a7dd3ac8@anthraxcx3> X-Antivirus: avast! (VPS 090820-0, 20/08/2009), Outbound message X-Antivirus-Status: Clean Now you are getting a 100% verifiable degree in just 4-5 weeks, with the help of your work experience. You can get Bachelors, Masters or Doctorate degree in a few weeks time. Ring right now 1.305.460.5721 Drop us your msg, with your full name and contact number so we can call you back. From tykemwh35@61-231-229-17.dynamic.hinet.net Thu Aug 20 18:37: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 19D2B3A6D4A; Thu, 20 Aug 2009 18:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -70.495 X-Spam-Level: X-Spam-Status: No, score=-70.495 tagged_above=-999 required=5 tests=[BAYES_60=1, DNS_FROM_AHBL_RHSBL=0.692, 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, FM_SCHOOLING=5.657, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, UNPARSEABLE_RELAY=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 gxYplKrply40; Thu, 20 Aug 2009 18:37:29 -0700 (PDT) Received: from 61-231-229-17.dynamic.hinet.net (61-231-229-17.dynamic.hinet.net [61.231.229.17]) by core3.amsl.com (Postfix) with ESMTP id 645123A6D46; Thu, 20 Aug 2009 18:37:28 -0700 (PDT) Received: from 61.231.229.17 by ; Fri, 21 Aug 2009 09:37:34 +0800 Message-ID: <01ca2243$03653cc0$11e5e73d@woofersgmy0> From: "Micah C. Just" To: Subject: Better Job Date: Fri, 21 Aug 2009 09:37:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Now you will easily get legal degree in only 4-5 weeks on base of your professional experience We provide the following programs:- Bachelors, Masters and PhD Give us a call now. [1.305-460-5721] Drop us your msg, with your full name and contact number so we can call you back. From owner-namedroppers@ops.ietf.org Thu Aug 20 18:55: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 515EF3A6B43; Thu, 20 Aug 2009 18:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.505 X-Spam-Level: X-Spam-Status: No, score=-4.505 tagged_above=-999 required=5 tests=[AWL=-0.368, 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 ydhZHeCd5LQK; Thu, 20 Aug 2009 18:55:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51BF13A6885; Thu, 20 Aug 2009 18:55:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeJF3-000Pji-5H for namedroppers-data0@psg.com; Fri, 21 Aug 2009 01:48:33 +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 1MeJEz-000Phy-6i for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 01:48:31 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 97943A9443A; Fri, 21 Aug 2009 01:48:28 +0000 (UTC) Message-ID: <4A8DFCEC.7090403@mail-abuse.org> Date: Thu, 20 Aug 2009 18:48:28 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: IETF DNSEXT WG , =?UTF-8?B?TWljaGFlbCBUw7x4?= =?UTF-8?B?ZW4=?= Subject: [dnsext] DNS over SCTP and correcting security concerns Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mea copa. A statement made regarding what was thought to have been security concerns related to SCTP tie-tags turned out to be based upon a dated understanding of SCTP. In reading recent drafts, important changes escaped notice. Michael Tüxen clarified how these issues have been resolved, and also mentioned these improvements have been incorporated in current releases of FreeBSD. FreeBSD also supports SCTP tunneling over UDP port 9899. http://tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt Although Intel offers 1Gb NICs (82576) and 10Gb NICs (X520) that off-load SCTP checksum calculations, and offer i7-core processors that have CRC32c functions contained within the new SSE4 math coprocessor, it seems doubtful SCTP checksum offloading will work with tunneling. Nevertheless, use of the SSE4 math coprocessor should reduce the overhead for handling an SCTP tunneling option. The SCTP_AUTOCLOSE option in the one-to-many Socket mode appears ideal for DNS. When the SCTP_AUTOCLOSE option is set in a one-to-many socket, the application (DNS) is able to reuse assigned association IDs once the associations terminate automatically. The application would receive association change notifications to track unused association IDs. http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19 Using SCTP_AUTOCLOSE should allow associations to remain persistent until no longer being used. This approach should reduce the overhead related with establishing an association, where repetitive transactions should obtain a significant benefit. In addition, any number of DNS messages can be bundled into a single packet that fits within the PMTU. Such bundling should also improve performance as well. -Doug From owner-namedroppers@ops.ietf.org Thu Aug 20 21: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 563423A6B21; Thu, 20 Aug 2009 21:00:39 -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 dMAFLhT4QgRL; Thu, 20 Aug 2009 21:00:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 005D63A69E3; Thu, 20 Aug 2009 21:00:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeLED-0005x9-AP for namedroppers-data0@psg.com; Fri, 21 Aug 2009 03:55:49 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeLE9-0005wS-An for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 03:55:47 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id EC4F97678FC; Thu, 20 Aug 2009 20:55: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 46Y6U+7c6XwI; Thu, 20 Aug 2009 20:55:43 -0700 (PDT) Received: from [10.0.1.8] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 674897678F1; Thu, 20 Aug 2009 20:55:43 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <1688F9EB-2412-4CDD-A34A-0E749EDD4962@virtualized.org> From: David Conrad To: Andrew Sullivan In-Reply-To: <20090820140203.GA6466@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow Date: Thu, 20 Aug 2009 17:55:42 -1000 References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <200908190202.n7J22PdU007627@drugs.dv.isc.org> <20090820140203.GA6466@shinkuro.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 20, 2009, at 4:02 AM, Andrew Sullivan wrote: >> Named just falls back to something that works. It tries EDNS@4096. >> If that fails (times out), it tries EDNS@512. > > I just want to highlight that step 2 is controversial. In particular, > the claim that EDNS0 at 512 "works" is the one about which people > disagree. As usual, this all hinges on the value of "works". I believe the controversy is less with "it works" than with "it violates RFC 3226". It seems pretty clear to me that any normal reading of that RFC would indicate that BIND is in violation of 3226. The question is whether that matters. Right now, in an analysis done for the "L" root server replaying modified live data, we see a large jump in TCP queries largely due to the "fall back to EDNS@512" BINDism, but the number of TCP queries is still pretty much in the noise and well within the tolerances of "L" (can't speak to other root servers of course). However let's posit an alternative reality in which people actually turn on validation. A root DNSKEY response is 1749 bytes. What does this imply? Thanks, -drc From owner-namedroppers@ops.ietf.org Thu Aug 20 23:41: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 1B3FE3A6971; Thu, 20 Aug 2009 23:41: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 sa9yT4lGlmbP; Thu, 20 Aug 2009 23:40:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A12A53A67A7; Thu, 20 Aug 2009 23:40:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeNiJ-0002u3-Rl for namedroppers-data0@psg.com; Fri, 21 Aug 2009 06:35:03 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeNiE-0002sh-VD for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 06:35:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9DAD5B37D7 for ; Fri, 21 Aug 2009 06:34:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow In-Reply-To: Your message of "Thu, 20 Aug 2009 17:55:42 -1000." <1688F9EB-2412-4CDD-A34A-0E749EDD4962@virtualized.org> References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <200908190202.n7J22PdU007627@drugs.dv.isc.org> <20090820140203.GA6466@shinkuro.com> <1688F9EB-2412-4CDD-A34A-0E749EDD4962@virtualized.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 21 Aug 2009 06:34:58 +0000 Message-ID: <23189.1250836498@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: David Conrad > Date: Thu, 20 Aug 2009 17:55:42 -1000 > > I believe the controversy is less with "it works" than with "it violates > RFC 3226". It seems pretty clear to me that any normal reading of that > RFC would indicate that BIND is in violation of 3226. The question is > whether that matters. speaking for RFC 2671, if EDNS0 @4096 does not work then EDNS0 should be negatively cached for that server, which means use DNS if it can carry the response data you need (which is DNSSEC metadata in this case, so, "don't"). fallback to 1500, 1480, 1420, 1400, 1280, 1024, or especially 512, is too much initiator-side state, too much complexity, too much application delay, too much DNS traffic, and too much namedroppers traffic. so, we should not do it. (note, i'm not speaking as president of ISC here.) speaking for RFC 3226, the DO bit is being treated as by some as "DNSSEC would be understood so it's safe to send it" and by others as "DNSSEC is wanted so please do send it." i prefer the former interpretation since it is minimally specificative. (is that a word?) the former interpretation would allow a responder to say, if the buffer size isn't large enough to carry DNSSEC metadata, then pretend DO=0. the latter interpretation would require an initator to say, if i really do want DNSSEC metadata than i need a buffer size of 1220 or more, so i should not set bufsize=512 and DO=1. > However let's posit an alternative reality in which people actually turn > on validation. A root DNSKEY response is 1749 bytes. What does this > imply? yipe! From owner-namedroppers@ops.ietf.org Fri Aug 21 00: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 1EF6A3A68DB; Fri, 21 Aug 2009 00:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.459 X-Spam-Level: *** X-Spam-Status: No, score=3.459 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsnhF5oFlwV8; Fri, 21 Aug 2009 00:26:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C3DF3A659C; Fri, 21 Aug 2009 00:26:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeOSg-000AFx-7n for namedroppers-data0@psg.com; Fri, 21 Aug 2009 07:22:58 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeOSc-000AEp-6A for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 07:22:55 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MeOSX-0004uh-C6; Fri, 21 Aug 2009 08:22:49 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MeOSW-0000pi-S1; Fri, 21 Aug 2009 08:22:48 +0100 Message-ID: <7C91A7FA83024D79BC90E624BD87AD4D@localhost> From: "George Barwood" To: "Matthew Dempsky" Cc: References: <406156C126454795B38BBC396D4DED73@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Fri, 21 Aug 2009 08:22:51 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Matthew Dempsky" To: "George Barwood" Cc: Sent: Thursday, August 20, 2009 11:48 PM Subject: Re: [dnsext] EDNS Page Option draft updated > On Thu, Aug 20, 2009 at 2:30 AM, George > Barwood wrote: >> Option for all pages to be sent immediately ( so response time is 1 x >> RTT ). > > Adding EDNS options like this stands in opposition to > draft-ietf-dnsext-dnsproxy-06, which currently recommends that DNS > proxies should copy OPT records blindly. If a DNS proxy unaware of > the Page option blindly copies a request with the Send All Pages flag > set, it won't know to forward the subsequent response packets. > > People have expressed concerns about the Send All Pages flag, but I > don't see anyone arguing a priori that EDNS options cannot alter the > response format this way. If no one feels that way, then I think the > dnsproxy draft should be updated to require DNS proxies to strip > unknown option codes. Better I think would be to define a standard that allows the client of a proxy to cleanly determine it's capabilities, instead of resorting to trial and error. But that's a bit pie in the sky for me. > The EDNS RFC says EDNS options are defined for hop-to-hop purposes, Well yes, the wording is "OPT RRs shall never be cached, forwarded, or stored in or loaded from master files." That actually seems rather unrealistic, given that all proxies do actually forward verbatim. > and I think it's a mistake to try to handwave a DNS proxy as not > counting as a hop. Maybe, but on the other hand this is what proxies do. I think trying to establish a standard that is in opposition to a what is currently deployed is likely to be futile. I think the best thing would be to encourage proxies to limit the UDP response size to the MTU, rather than 512 bytes. Some proxies already do this, and it seems realistic. Besides, proxying DNS over TCP should probably be deprecated, since that's clearly a hopeless thing to wish for, even if it is the offical standard. At any rate, I want to see a standard that allows DNSSEC to work using the existing deployed middleboxes, simply by users installing a validating stub resolver. > The HTTP RFCs go to some effort distinguishing which header fields are > hop-to-hop versus client-to-origin, so that HTTP proxies and caches > know how to handle them. I think it would be a good idea to > standardize a way for DNS proxies to know whether or not an > unrecognized option can be handled opaquely. > From owner-namedroppers@ops.ietf.org Fri Aug 21 01:29: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 0FA893A6E06; Fri, 21 Aug 2009 01:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 gSnMXpwKEnJL; Fri, 21 Aug 2009 01:29:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39DA03A6A1E; Fri, 21 Aug 2009 01:28:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MePPi-000JbO-GA for namedroppers-data0@psg.com; Fri, 21 Aug 2009 08:23:58 +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 1MePPe-000Jaf-Fy for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 08:23:56 +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 68C80E6059; Fri, 21 Aug 2009 08:23:51 +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 n7L8NkCU018970; Fri, 21 Aug 2009 18:23:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908210823.n7L8NkCU018970@drugs.dv.isc.org> To: "George Barwood" Cc: "Matthew Dempsky" , namedroppers@ops.ietf.org From: Mark Andrews References: <406156C126454795B38BBC396D4DED73@localhost> <7C91A7FA83024D79BC90E624BD87AD4D@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated In-reply-to: Your message of "Fri, 21 Aug 2009 08:22:51 +0100." <7C91A7FA83024D79BC90E624BD87AD4D@localhost> Date: Fri, 21 Aug 2009 18:23:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <7C91A7FA83024D79BC90E624BD87AD4D@localhost>, "George Barwood" writes: > > On Thu, Aug 20, 2009 at 2:30 AM, George > > Barwood wrote: > >> Option for all pages to be sent immediately ( so response time is 1 x > >> RTT ). > > > > Adding EDNS options like this stands in opposition to > > draft-ietf-dnsext-dnsproxy-06, which currently recommends that DNS > > proxies should copy OPT records blindly. If a DNS proxy unaware of > > the Page option blindly copies a request with the Send All Pages flag > > set, it won't know to forward the subsequent response packets. > > > > People have expressed concerns about the Send All Pages flag, but I > > don't see anyone arguing a priori that EDNS options cannot alter the > > response format this way. If no one feels that way, then I think the > > dnsproxy draft should be updated to require DNS proxies to strip > > unknown option codes. > > Better I think would be to define a standard that allows the client > of a proxy to cleanly determine it's capabilities, instead of resorting > to trial and error. But that's a bit pie in the sky for me. > > > The EDNS RFC says EDNS options are defined for hop-to-hop purposes, > > Well yes, the wording is > > "OPT RRs shall never be cached, forwarded, or stored in or loaded from > master files." > > That actually seems rather unrealistic, given that all proxies do actually > forward verbatim. > > > and I think it's a mistake to try to handwave a DNS proxy as not > > counting as a hop. > > Maybe, but on the other hand this is what proxies do. > > I think trying to establish a standard that is in opposition to a what is > currently deployed is likely to be futile. > > I think the best thing would be to encourage proxies to limit the UDP > response size to the MTU, rather than 512 bytes. Some proxies already > do this, and it seems realistic. Besides, proxying DNS over TCP should > probably be deprecated, since that's clearly a hopeless thing to wish for, > even if it is the offical standard. Proxying DNS over TCP is easier than UDP. You don't have to do anything at all to the data stream. Once you have succeeded in connecting to a upstream you just shuffle bits from one socket to the other. When either end closes you pass that on using shutdown(2). When both sides have said they have no more to send you close(2) the sockets. > At any rate, I want to see a standard that allows DNSSEC to work > using the existing deployed middleboxes, simply by users installing > a validating stub resolver. > > > The HTTP RFCs go to some effort distinguishing which header fields are > > hop-to-hop versus client-to-origin, so that HTTP proxies and caches > > know how to handle them. I think it would be a good idea to > > standardize a way for DNS proxies to know whether or not an > > unrecognized option can be handled opaquely. The problem with proxies is that they don't actually pass the responses they receive back. If they did there would be almost no problem. If you are going to pass queries through verbatim you need to pass the responses back verbatim. The still won't help with a request that generates multiple responses but we wouldn't need such options if they did the right thing in the first place. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Fri Aug 21 01: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 9F9F03A69D8; Fri, 21 Aug 2009 01:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.173 X-Spam-Level: X-Spam-Status: No, score=-4.173 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 3SjCOFmNXVNe; Fri, 21 Aug 2009 01:42:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 989F83A68BC; Fri, 21 Aug 2009 01:42:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MePdV-000LZN-Jp for namedroppers-data0@psg.com; Fri, 21 Aug 2009 08:38:13 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MePdP-000LWm-NR; Fri, 21 Aug 2009 08:38: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=IodpBmD1MpqsFPQjxCp0uQbdHukU4CJ/172GWyg3HSIziP+gW3q7yv8w xH+W43gSI8Ni8nY/EyyJNWOTOwZhTEljw9lM6jC5C+2ghGcPLpxCVATaN y/eHpSECx6JBmI0; 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=1250843887; x=1282379887; 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]=20EDNS=20Page=20Option=20draft=20updated|Date:=20Fri, =2021=20Aug=202009=2010:37:55=20+0200|Message-ID:=20|To:=20Matthew=20Dempsky=20|Cc:=20George=20Barwood=20,=0D=0A=09namedroppers@ops.ietf.org,=0D=0A=09owner-n amedroppers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To: =20|References:=20<406156C126454795B38BBC396D4DED73@l ocalhost>=09=20=20; bh=pfWYzHpbmLbAa8q41xMm+dpbObba8Wry0pRXpGdy5/g=; b=AEo7jdsmnblPbW1GvEoLXOKLjMqSCLAsMPHkcT+IkIStisGVj65UQTu+ fyzLE5LOmcKIMoZchQ1EA97aCjhhOkC3VbUIBo0wDp0AnP5biztPuEE+9 eNFxIVMRF9qPQ1j; X-IronPort-AV: E=Sophos;i="4.44,249,1249254000"; d="scan'208";a="12360271" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 21 Aug 2009 09:38:00 +0100 In-Reply-To: References: <406156C126454795B38BBC396D4DED73@localhost> To: Matthew Dempsky Cc: George Barwood , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft updated MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 21 Aug 2009 10:37:55 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 21/08/2009 09:38:04 AM, Serialize complete at 21/08/2009 09:38:04 AM Content-Type: multipart/alternative; boundary="=_alternative 002F6A7EC1257619_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 002F6A7EC1257619_= Content-Type: text/plain; charset="US-ASCII" > Adding EDNS options like this stands in opposition to > draft-ietf-dnsext-dnsproxy-06, which currently recommends that DNS > proxies should copy OPT records blindly. That's not strictly true - what it does say that if you blindly copy the request you should be prepared to blindly copy the *whole* response. Personally although I like the fact that sending all packets at once absolves the server of any need to keep state, it's fundamentally incompatible with the single-request -> single-response model used by DNS. Proxies _do_ need to maintain state about any transactions going through them, hence going to a single-request -> multiple response model will inevitably break many things. > If a DNS proxy unaware of > the Page option blindly copies a request with the Send All Pages flag > set, it won't know to forward the subsequent response packets. Indeed, although that's exactly what most current proxies would do. > People have expressed concerns about the Send All Pages flag, but I > don't see anyone arguing a priori that EDNS options cannot alter the > response format this way. If no one feels that way, then I think the > dnsproxy draft should be updated to require DNS proxies to strip > unknown option codes. > > The EDNS RFC says EDNS options are defined for hop-to-hop purposes, > and I think it's a mistake to try to handwave a DNS proxy as not > counting as a hop. The problem is that many of them behave as if they were transparent w.r.t. the request, but not to the response. > The HTTP RFCs go to some effort distinguishing which header fields are > hop-to-hop versus client-to-origin, so that HTTP proxies and caches > know how to handle them. I think it would be a good idea to > standardize a way for DNS proxies to know whether or not an > unrecognized option can be handled opaquely. It's not a bad idea, but there's no hope of it being implemented by middle-boxes whilst they're still ignoring everything I'm trying to get them to fix in draft-ietf-dnsext-dnsproxy. Ray --=_alternative 002F6A7EC1257619_= Content-Type: text/html; charset="US-ASCII" > Adding EDNS options like this stands in opposition to
> draft-ietf-dnsext-dnsproxy-06, which currently recommends that DNS
> proxies should copy OPT records blindly.  

That's not strictly true - what it does say that if you blindly copy the request you should be prepared to blindly copy the *whole* response.

Personally although I like the fact that sending all packets at once absolves the server of any need to keep state, it's fundamentally incompatible with the single-request -> single-response model used by DNS.  Proxies _do_ need to maintain state about any transactions going through them, hence going to a single-request -> multiple response model will inevitably break many things.

> If a DNS proxy unaware of
> the Page option blindly copies a request with the Send All Pages flag
> set, it won't know to forward the subsequent response packets.
Indeed, although that's exactly what most current proxies would do.

> People have expressed concerns about the Send All Pages flag, but I
> don't see anyone arguing a priori that EDNS options cannot alter the
> response format this way.  If no one feels that way, then I think the
> dnsproxy draft should be updated to require DNS proxies to strip
> unknown option codes.
>
> The EDNS RFC says EDNS options are defined for hop-to-hop purposes,
> and I think it's a mistake to try to handwave a DNS proxy as not
> counting as a hop.
The problem is that many of them behave as if they were transparent w.r.t. the request, but not to the response.
 
> The HTTP RFCs go to some effort distinguishing which header fields are
> hop-to-hop versus client-to-origin, so that HTTP proxies and caches
> know how to handle them.  I think it would be a good idea to
> standardize a way for DNS proxies to know whether or not an
> unrecognized option can be handled opaquely.
It's not a bad idea, but there's no hope of it being implemented by middle-boxes whilst they're still ignoring everything I'm trying to get them to fix in draft-ietf-dnsext-dnsproxy.

Ray
--=_alternative 002F6A7EC1257619_=-- From owner-namedroppers@ops.ietf.org Fri Aug 21 04:39: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 A5CE63A6DE4; Fri, 21 Aug 2009 04:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.93 X-Spam-Level: *** X-Spam-Status: No, score=3.93 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_40=-0.185, 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 8hwUUvLxC1sJ; Fri, 21 Aug 2009 04:39:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1794A3A6E09; Fri, 21 Aug 2009 04:39:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeSMI-000L1F-TL for namedroppers-data0@psg.com; Fri, 21 Aug 2009 11:32:38 +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 1MeSMD-000L0V-3W; Fri, 21 Aug 2009 11:32:35 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MeSMB-0003pn-84; Fri, 21 Aug 2009 12:32:31 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MeSMA-0004hy-Gi; Fri, 21 Aug 2009 12:32:30 +0100 Message-ID: <74329874920E437B883BB0B23B38BD93@localhost> From: "George Barwood" To: "Matthew Dempsky" , Cc: , References: <406156C126454795B38BBC396D4DED73@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Fri, 21 Aug 2009 12:32:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08D1_01CA225B.74620670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_08D1_01CA225B.74620670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Ray.Bellis@nominet.org.uk=20 To: Matthew Dempsky=20 Cc: George Barwood ; namedroppers@ops.ietf.org ; = owner-namedroppers@ops.ietf.org=20 Sent: Friday, August 21, 2009 9:37 AM Subject: Re: [dnsext] EDNS Page Option draft updated Ray > Personally although I like the fact that sending all packets at = once absolves the server of any need to keep state, it's fundamentally = incompatible with the single-request -> single-response model used by = DNS. Proxies _do_ need to maintain state about any transactions going = through them, hence going to a single-request -> multiple response model = will inevitably break many things.=20 It will break proxies ( that are unaware ), agreed. But does it break anything else? What are the many things? On server state : one simple model for authoritative servers is to = support cookies most of the time, but to turn them off during an update, e.g. (1) Updates arrive (2) Turn off cookies (3) Wait 5 seconds ( or shorter time if no cookies issued recently ) (4) Do update (5) Re-enable cookies ( cookie value increased, to catch any invalid = cookies ) It's more difficult for caches, since updates are of course very = frequent.=20 I think the most practical solution there is to keep a list of response = buffers.=20 I don't think the rate of sending large responses should be very high,=20 since DNSKEY RRsets should have long TTLs (hopefully), and=20 other large responses (NXDOMAINs) should be infrequent. So should I = think it is entirely practical. George ------=_NextPart_000_08D1_01CA225B.74620670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

----- Original Message ----- =
From:=20 Ray.Bellis@nominet.org.uk
To: Matthew Dempsky
Cc: George Barwood = ;=20 namedroppers@ops.ietf.org ; owner-namedroppers@ops.ietf.org
Sent: = Friday,=20 August 21, 2009 9:37 AM
Subject: Re: [dnsext] EDNS Page Option draft=20 updated

Ray > Personally although I like the fact that sending = all=20 packets at once absolves the server of any  need to keep state, = it's=20 fundamentally incompatible with the single-request -> single-response = model=20 used by DNS.  Proxies _do_ need to maintain state about any = transactions=20 going through them, hence going to a single-request -> multiple = response=20 model will inevitably break many things.

It will break proxies ( = that=20 are unaware ), agreed.

But does it break anything else? What are = the many=20 things?

On server state : one simple model for authoritative = servers=20 is to support cookies most
of the time, but to turn them off during = an=20 update, e.g.

(1) Updates arrive
(2) Turn off cookies
(3) = Wait 5=20 seconds ( or shorter time if no cookies issued recently )
(4) Do=20 update
(5) Re-enable cookies ( cookie value increased, to catch=20 any invalid cookies )

It's more difficult for = caches,=20 since updates are of course very frequent.
I think the most practical solution = there is to=20 keep a list of response buffers.
I don't think the rate of sending large = responses=20 should be very high,
since DNSKEY RRsets should have long = TTLs=20 (hopefully), and
other large responses (NXDOMAINs) should be = infrequent. So=20 should I think
it is entirely = practical.
 
George
------=_NextPart_000_08D1_01CA225B.74620670-- From owner-namedroppers@ops.ietf.org Fri Aug 21 11:28: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 034553A6E1E; Fri, 21 Aug 2009 11:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 hCedNksZhjH4; Fri, 21 Aug 2009 11:28:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8C993A6E09; Fri, 21 Aug 2009 11:28:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeYjC-0006dc-Ok for namedroppers-data0@psg.com; Fri, 21 Aug 2009 18:20:42 +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 1MeYj8-0006d9-Sd for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 18:20:40 +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 n7LIKcRm029222; Fri, 21 Aug 2009 11:20:38 -0700 (PDT) Message-Id: From: Nicholas Weaver To: "namedroppers@ops.ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] Suggested fallbacks... Date: Fri, 21 Aug 2009 11:20:38 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I think at this point we can presume "UDP Fragmentation is a problem for some". So stupid quesiton: Why not just have the resolver discover for itself when its the problem, and do something about it? The resolver already needs to keep track of EDNS0 fallback for every particular authority, no? (If you don't you get bad behavior where a non-EDNS-liking authority will see eg, 3 second latency. We experienced this in Netalyzr's F&F testing). So why not do the following: EDNS@4096. If failed, fallback to EDNS@1400. If success, and the response was > 1500B, record the server as "MTU > 1500" EDNS@1400. If success but truncated, mark that server as EDNS@1400, and on truncation, you fall back to TCP, of course. and then the rest of Bind's current policy or a similar policy. Its only one additional state in the fallback chain, but it allows one key addition... Keep a global count of the following: # of servers where you've gotten a reply where MTU > 1500B # of servers which have been marked as EDNS1400 When the # of EDNS1400 servers - MTU-1500B servers > B (B = 5 is a good number, this is a threshold-random-walk count, but 10 is good for paranoia), the resolver now presumes it is behind a broken middlebox and changes its default EDNS0 MTU from 4096 to 1400, as its learned the presence of a broken middlebox. When in EDNS@1400 mode, if a reply is truncated, don't just fallback to TCP, but also, with a random probability P, also conduct a UDP query with EDNS@4096 (which is not for returning but for path probing). If the probe succeeds at MTU>1500, add 1 to a second counter. If it fails, subtract one (but don't let the count get below -10). If it succeeds but the reply was <1500, do nothing. If this second count ever gets about another threshold (again, 5 is a good one, 10 for paranoia), the middlebox has gone away and gotten fixed, so return to EDNS@4096 and reset all counters and server status. Why? This is effectively learning: the resolver is able to quickly (with timeout events to only 5 servers!) discover that it is behind a broken middlebox which is causing fragmented DNS traffic to fail, and if so, change to a default behavior which prevents this problem. It is also able to quickly learn when the broken middlebox gets fixed, allowing it to automatically fallback to normal behavior. It won't reduce the number of TCP queries when behind a broken middlebox, but it eliminates the timeout latency for these queries (which is the far bigger concern: Which is worse, an additional 2 RTTs for a large-response query, or 2 RTTs plus a no-response timeout? You're still going to have the TCP hit anyway...). Its a single sided, resolver only change. The resolver needs to keep per authority state, but it already needs to keep per authority state on EDNS0 behavior, and this is only effectively a couple more bits to that state. If you don't want to keep exact per-authority state, use a couple of small bloom filter for the global status of authorities, so you can even do this with bounded state. It automatically "unlearns", so if the middlebox gets fixed, this gets fixed. EDNS@1400 is likely to be a "safe" number, but you could do learning at a couple of other points as well (EDNS@1000, EDNS@512). And now, you won't see the severe latency issues you might otherwise have with DNSSEC and large replies. You will still see TCP load on the authorities, but really, so what? Thoughts? From owner-namedroppers@ops.ietf.org Fri Aug 21 15:32: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 A2D663A69F1; Fri, 21 Aug 2009 15:32:04 -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 Yk31F1sAjrtq; Fri, 21 Aug 2009 15:32:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA90B3A69EA; Fri, 21 Aug 2009 15:32:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecYi-000C2I-Cg for namedroppers-data0@psg.com; Fri, 21 Aug 2009 22:26:08 +0000 Received: from [209.85.216.173] (helo=mail-px0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecYf-000C0D-6l for namedroppers@ops.ietf.org; Fri, 21 Aug 2009 22:26:06 +0000 Received: by pxi3 with SMTP id 3so5048093pxi.32 for ; Fri, 21 Aug 2009 15:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.119.6 with SMTP id r6mr2398238wac.45.1250893564397; Fri, 21 Aug 2009 15:26:04 -0700 (PDT) In-Reply-To: <74329874920E437B883BB0B23B38BD93@localhost> References: <406156C126454795B38BBC396D4DED73@localhost> <74329874920E437B883BB0B23B38BD93@localhost> Date: Fri, 21 Aug 2009 15:26:04 -0700 Message-ID: Subject: Re: [dnsext] EDNS Page Option draft updated From: Matthew Dempsky To: George Barwood 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 21, 2009 at 4:32 AM, George Barwood wrote: > But does it break anything else? What are the many things? I could imagine it breaking on firewalls that have to perform NAT. E.g., if a firewall rule is setup to only allow one response packet before discarding the NAT state. On the other hand, such a setup is already a bad idea today because it allows easier denial of service forgery attacks unless the NAT does deeper packet inspection than just the UDP header. From owner-namedroppers@ops.ietf.org Fri Aug 21 18:16: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 25FE73A6838; Fri, 21 Aug 2009 18:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 kCZYsmTKsNPa; Fri, 21 Aug 2009 18:16:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41A693A67A8; Fri, 21 Aug 2009 18:16:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mef8m-000O84-Cj for namedroppers-data0@psg.com; Sat, 22 Aug 2009 01:11: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 1Mef8h-000O7R-Cb; Sat, 22 Aug 2009 01:11: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 17A18E601C; Sat, 22 Aug 2009 01:11: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 n7M1BFE1029877; Sat, 22 Aug 2009 11:11:16 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908220111.n7M1BFE1029877@drugs.dv.isc.org> To: "George Barwood" Cc: "Matthew Dempsky" , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org From: Mark Andrews References: <406156C126454795B38BBC396D4DED73@localhost> <74329874920E437B883BB0B23B38BD93@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated In-reply-to: Your message of "Fri, 21 Aug 2009 12:32:32 +0100." <74329874920E437B883BB0B23B38BD93@localhost> Date: Sat, 22 Aug 2009 11:11:15 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <74329874920E437B883BB0B23B38BD93@localhost>, "George Barwood" writes: > Ray > Personally although I like the fact that sending all packets at > once absolves the server of any need to keep state, it's fundamentally > incompatible with the single-request -> single-response model used by > DNS. Proxies _do_ need to maintain state about any transactions going > through them, hence going to a single-request -> multiple response model > will inevitably break many things. > > It will break proxies ( that are unaware ), agreed. And you are designing this option to get DNS responses through such proxies. > But does it break anything else? What are the many things? Since you are failing to meet the design goal it doesn't matter if it breaks nothing else. > On server state : one simple model for authoritative servers is to > support cookies most > of the time, but to turn them off during an update, e.g. > > (1) Updates arrive > (2) Turn off cookies > (3) Wait 5 seconds ( or shorter time if no cookies issued recently ) > (4) Do update > (5) Re-enable cookies ( cookie value increased, to catch any invalid > cookies ) > > It's more difficult for caches, since updates are of course very > frequent. > I think the most practical solution there is to keep a list of response > buffers. > I don't think the rate of sending large responses should be very high, > since DNSKEY RRsets should have long TTLs (hopefully), and > other large responses (NXDOMAINs) should be infrequent. So should I > think > it is entirely practical. Again you are failing to think about why you are doing this in the first place. Large is > 512 bytes. This just won't fly. > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Sat Aug 22 16:19: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 39CD33A6C53; Sat, 22 Aug 2009 16:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 nHLQ2oyo9d3L; Sat, 22 Aug 2009 16:19:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 501B43A68F9; Sat, 22 Aug 2009 16:19:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MezlW-000CYx-15 for namedroppers-data0@psg.com; Sat, 22 Aug 2009 23:12:54 +0000 Received: from [209.85.211.189] (helo=mail-yw0-f189.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MezlR-000CY1-Fy for namedroppers@ops.ietf.org; Sat, 22 Aug 2009 23:12:51 +0000 Received: by ywh27 with SMTP id 27so1853372ywh.26 for ; Sat, 22 Aug 2009 16:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=nUgBkdYNjVJyveMP5vgLxmam2EoYQiaW2CLHYFaKHr4=; b=WGEFTGHWeasDUAfhHU5Ay0bWC5oE5+jA0p9eZuus8M1eX44fQaez0H64rdupFSwdDR SKfbWRLy1ZOykbfH0XsFaLmKgw+ZYe/pdw/zn3fydlsXXA9uQGBDKYwM6beOK92jVlec fsDM/RmXRRqJS9g6HOMshfdFQpQYL9V1Ngnyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=VB1E33BzFDXK1Q+//L3JheCzwSHde5nPhFsLQPVvgw4nMAPtGPYM3BSYurE41Gdvhm y8WsmZryCAFF8GSa57rjsQvz+7OQz5IeIzVz3sxgUa9yDU1uh439Crup7lbySKCwvIFX D9bEedgAoCtt0acyhOL/PLia8U2YG4EzJCoCU= Received: by 10.91.7.17 with SMTP id k17mr2401131agi.24.1250982768154; Sat, 22 Aug 2009 16:12:48 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 10sm2990436agd.73.2009.08.22.16.12.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 22 Aug 2009 16:12:47 -0700 (PDT) Message-ID: <4A907B6D.1050905@gmail.com> Date: Sat, 22 Aug 2009 19:12:45 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] root DNSKEY response is 1749 bytes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Vixie wrote: >> From: David Conrad >> However let's posit an alternative reality in which people actually turn >> on validation. A root DNSKEY response is 1749 bytes. What does this >> imply? > > yipe! > Earlier, we've learned that a NSEC3 NXDOMAIN won't fit within 512 bytes. Now, we've learned that a basic root query won't fit within 1500 bytes, let alone 1220 bytes. Of course, during key rollover, that'll be bigger. Unless somebody has a magic wand, a heck of a lot of queries are going to fall over to TCP. Could we please consider my earlier suggestion, breaking the problem into two parts? 1. Send a EDNS0 two part query for A and/or NS, with DO off, with the Algorithm Understood (AU) option. I've suggested that this be slightly extended to return the signature algorithms list with DO off. 2. If (and only if) a validating resolver, use TCP to query for the DNSsec records. 3. If some dastardly intermediate caching resolver doesn't return the DNSsec answers because it's faking answers, send the TCP query to the listed NS (cleverly saved above). Do we really want to perform 2 or 3 more RTT of UDP queries before TCP, just in case one of them works? As Weaver suggests above, step 2 SHOULD be cached. MY first DNS implementation cached information about server RTT and such, there's no reason that even the most mundane non-caching validating stub resolver would have much trouble keeping that tiny bit of state in memory. From owner-namedroppers@ops.ietf.org Sat Aug 22 22:02: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 BFBE23A6AD9; Sat, 22 Aug 2009 22:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b235zYJDDzyA; Sat, 22 Aug 2009 22:02:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68F813A6A66; Sat, 22 Aug 2009 22:02:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf56M-000FDV-UN for namedroppers-data0@psg.com; Sun, 23 Aug 2009 04:54:46 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf56J-000FCs-4X for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 04:54:44 +0000 Received: (qmail 20673 invoked by uid 399); 23 Aug 2009 04:54:37 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Aug 2009 04:54:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A90CB87.1080502@dougbarton.us> Date: Sat, 22 Aug 2009 21:54:31 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Mark Andrews CC: bert hubert , Paul Wouters , namedroppers@ops.ietf.org Subject: Re: [dnsext] all .gov do=1 nxdomain answers already appear to be fragmented.. and it works somehow References: <3efd34cc0908181454h4e93409dn7b0e8e0a0ca89034@mail.gmail.com> <3efd34cc0908181551p2702037eldb16e50f665296a5@mail.gmail.com> <4A8B8AEE.1040105@dougbarton.us> <200908190546.n7J5kZJr009870@drugs.dv.isc.org> In-Reply-To: <200908190546.n7J5kZJr009870@drugs.dv.isc.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark Andrews wrote: > In message <4A8B8AEE.1040105@dougbarton.us>, Doug Barton writes: >> bert hubert wrote: >> >>> This, however, is not the point; we are not dealing with a 'clean >>> network'. We are dealing with a network ('The Internet') that saw a >>> 600-fold increase in TCP traffic, which should not have happened. >> I asked in passing for references to this claim, now I'm asking directly. >> >> Doug > > The traffic went from .1 connects/second to 60 connections/second compared > to 6000 UDP requests/second. Whose traffic? I assume we're talking about ORG? Where is this documented? Meanwhile, we're losing sleep because 1% of connections/second are now happening over TCP? Has anyone from Afilias actually said that there is a problem here? Do any other sites anticipate a problem if 1% (or even *gasp* 2%) of their connections are TCP? I've already stated my support for wanting to see something "better" than we have now for making sure that EDNS is going to work, and I'm sorry if I'm being dense but I don't see that this problem justifies the amount of drama we've seen on the list so far. Doug (as always hoping to be enlightened if I'm wrong) From owner-namedroppers@ops.ietf.org Sat Aug 22 22:41: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 1A8833A6842; Sat, 22 Aug 2009 22:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.564 X-Spam-Level: **** X-Spam-Status: No, score=4.564 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_53=0.6, J_CHICKENPOX_56=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 tq1LYa7NZypm; Sat, 22 Aug 2009 22:41:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7B973A6359; Sat, 22 Aug 2009 22:41:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf5lH-000MTa-M1 for namedroppers-data0@psg.com; Sun, 23 Aug 2009 05:37:03 +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 1Mf5lD-000MSN-D9 for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 05:37:01 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Mf5l4-0008Km-Cd; Sun, 23 Aug 2009 06:36:50 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mf5l3-0003vJ-Of; Sun, 23 Aug 2009 06:36:49 +0100 Message-ID: <5281A663D492453DB6C35DC47AC2BB9E@localhost> From: "George Barwood" To: Cc: "Matthew Dempsky" , , "Mark Andrews" References: <406156C126454795B38BBC396D4DED73@localhost> <74329874920E437B883BB0B23B38BD93@localhost> <200908220111.n7M1BFE1029877@drugs.dv.isc.org> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Sun, 23 Aug 2009 06:36:47 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ( Reply follows some private correspondence between myself and Mark ) ----- Original Message ----- From: "Mark Andrews" To: "George Barwood" Cc: "Matthew Dempsky" ; ; ; Sent: Saturday, August 22, 2009 2:11 AM Subject: Re: [dnsext] EDNS Page Option draft updated > > In message <74329874920E437B883BB0B23B38BD93@localhost>, "George Barwood" > writes: >> Ray > Personally although I like the fact that sending all packets at >> once absolves the server of any need to keep state, it's fundamentally >> incompatible with the single-request -> single-response model used by >> DNS. Proxies _do_ need to maintain state about any transactions going >> through them, hence going to a single-request -> multiple response model >> will inevitably break many things. >> >> It will break proxies ( that are unaware ), agreed. > > And you are designing this option to get DNS responses through > such proxies. Therefore "this option" (that is the "Send All Pages" option) cannot be used when proxies are present, as described in the current draft. It can normally be used for authoritative queries. The exception is if there is a firewall which is stopping multiple responses, either at the client or the server ( authoritative queries are never proxied, AFAICS ). I suspect this is very rare, but in such cases either the firewall would need to be reconfigured, or the "Send All Pages" option cannot be used. Provided cookies are implemented, that's ok, it just implies latency of 2xRTT instead of 1xRTT. If "Send All Pages" cannot be used due to a server firewall, turning off cookies during updates as described below doesn't work. Instead, during updates, the server could return SERVERFAIL ( i.e. "ask another server" ), or it could ignore the Page Option ( leading to fragmented UDP packets), or it could truncate the response (leading to temporary TCP traffic ). Or of course cookies can be implemented to work during updates, which would be best. .. Doug Otis has raised concerns about amplification attacks on third parties using the "Send All Pages" option. These could be hard for a server to notice if the attacker is using a large number of authoritative servers to conduct the attack. I plan to add a section roughly as follows: (1) "Send All Pages" should not be honored for QTYPE=ANY. (2) The NS RRset should not be sent when QTYPE=DNSKEY ( except in referrals of course ). (3) Additional Section processing should be limited to so that it does not contribute to the maximum response size. (4) The minimum Page Size is 512 bytes. This should mean that the amplification an attacker can achieve (measured in packets) should not be more than ~4. There is an inevitable compromise between seeking to minimise latency, and mitigating amplification attacks. George > But does it break anything else? What are the many things? > > Since you are failing to meet the design goal it doesn't matter > if it breaks nothing else. > >> On server state : one simple model for authoritative servers is to >> support cookies most >> of the time, but to turn them off during an update, e.g. >> >> (1) Updates arrive >> (2) Turn off cookies >> (3) Wait 5 seconds ( or shorter time if no cookies issued recently ) >> (4) Do update >> (5) Re-enable cookies ( cookie value increased, to catch any invalid >> cookies ) >> >> It's more difficult for caches, since updates are of course very >> frequent. >> I think the most practical solution there is to keep a list of response >> buffers. >> I don't think the rate of sending large responses should be very high, >> since DNSKEY RRsets should have long TTLs (hopefully), and >> other large responses (NXDOMAINs) should be infrequent. So should I >> think >> it is entirely practical. > > Again you are failing to think about why you are doing this in the > first place. Large is > 512 bytes. This just won't fly. > >> George > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > From owner-namedroppers@ops.ietf.org Sat Aug 22 22:56: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 7D8613A687C; Sat, 22 Aug 2009 22:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XCiyIH2WvMzG; Sat, 22 Aug 2009 22:56:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E4F73A6778; Sat, 22 Aug 2009 22:56:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf61Q-000PdV-93 for namedroppers-data0@psg.com; Sun, 23 Aug 2009 05:53: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 1Mf61E-000PaM-Lu for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 05:53:34 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2DD27B3B8F for ; Sun, 23 Aug 2009 05:53:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Sat, 22 Aug 2009 19:12:45 -0400." <4A907B6D.1050905@gmail.com> References: <4A907B6D.1050905@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 23 Aug 2009 05:53:32 +0000 Message-ID: <61661.1251006812@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Sat, 22 Aug 2009 19:12:45 -0400 > From: William Allen Simpson > ... > Could we please consider my earlier suggestion, breaking the problem into > two parts? > > 1. Send a EDNS0 two part query for A and/or NS, with DO off, with the > Algorithm Understood (AU) option. I've suggested that this be slightly > extended to return the signature algorithms list with DO off. > > 2. If (and only if) a validating resolver, use TCP to query for the > DNSsec records. > > 3. If some dastardly intermediate caching resolver doesn't return the > DNSsec answers because it's faking answers, send the TCP query to the > listed NS (cleverly saved above). > ... if we're tearing the covers off again and declaring that dnssec still is not deployable and needs another round of changes before it's safe to use, then i have a small stack of late changes that i'd like to put in as well. From owner-namedroppers@ops.ietf.org Sun Aug 23 02: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 C875E3A6B16; Sun, 23 Aug 2009 02:53:13 -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.027, 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 78VKYX8yFumN; Sun, 23 Aug 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 C1D5D3A6B59; Sun, 23 Aug 2009 02:53:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf9gS-000HCw-ML for namedroppers-data0@psg.com; Sun, 23 Aug 2009 09:48:20 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf9gN-000HBW-PU for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 09:48:17 +0000 Received: by ewy11 with SMTP id 11so1615572ewy.11 for ; Sun, 23 Aug 2009 02:48:14 -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=0btNKU9ECrfTmGjCdMPXtPz35cEda1z7K9dwFETN2Zk=; b=vueh3ABWIgsb9UcPSUqFcKl8MpMxWp5/uJAxt2x6wBPOX9ns3cAcu92xwa9Y+/HXe0 eEOs7B1zoGvrz8nUY6Vpy48G2dXQHUgfIQfpVCc4yc1INab7k3wG2bP4UgV9LUWCe54G gb7X2A8vzUBtd764jPd0Omv48ihr/VXNOEAE0= 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=C3z5/4WlBY1ISV6md/gkpR/0VVktyheL0oyBDI8wb62oyxNDfCcJoW+KmudJnJlwAX QaV5gE40gyawbktqhwJEy9Sjjpv2R1pHB2E1N4BrwPte18Z4z1GbqUdmUDYdaZEhLQEr 4ycluY3PHcO6SwG6tKqhis8FOlpwgFbK410Gw= MIME-Version: 1.0 Received: by 10.210.38.5 with SMTP id l5mr3711468ebl.64.1251020894085; Sun, 23 Aug 2009 02:48:14 -0700 (PDT) In-Reply-To: <61661.1251006812@nsa.vix.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> From: bert hubert Date: Sun, 23 Aug 2009 11:47:54 +0200 Message-ID: <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes To: Paul Vixie Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Aug 23, 2009 at 7:53 AM, Paul Vixie wrote: >> =A03. If some dastardly intermediate caching resolver doesn't return the >> DNSsec answers because it's faking answers, send the TCP query to the >> listed NS (cleverly saved above). >> ... > > if we're tearing the covers off again and declaring that dnssec still is > not deployable and needs another round of changes before it's safe to use= , > then i have a small stack of late changes that i'd like to put in as well= . Since I'm a DNSSEC implementor these days, I'd support this motion. >From what I make of it right now, we have two futures. 1) we stick with what we have (large keys, 5-15% of resolvers unable to receive fragmented packets), and prepare for large scale TCP use to compensate. The losers in this scenario are those who have to support the TCP traffic, and those that can't do outgoing TCP. 2) we implement workarounds, like 'paging', ecc cryptography and algorithm selection. The losers in this case are the poor implementors who have to implement all that. In addition, any workarounds will have to look like very normal <512 byte queries/responses, so we aren't caught by another round of middle boxes interfering. DJB pioneered this concept in DNSCurve. What people are still pondering is: 3) do nothing, and hope for the best. I would personally not be happy to promote '3' as is - any 'PowerDNSSEC' efforts would still not end up being used in large scale, since people will quickly turn off DNSSEC if it 'smells like downtime'. In addition, even if 3 is marginally workable, I'm pretty sure it won't be over (emergency) key rollovers, since that makes packet sizes balloon. '3' is basically '1' without preparing for increased TCP usage. Option 1 requires some guts, and for many servers, a lot of work to bring TCP performance up to scratch. EDNS0@512 is taking us in this direction already, if we want it or not. Option 2 may not be so easy either - 'paging' will also cause packet counts to go up, and require further maintenance of state. Because of proxies, each response 'page' will require a new query, causing packet counts to go up anyhow. In addition, Richard Stevens had some wise words to say about when you find yourself adding sequencing and retransmit logic to a UDP based protocol 'you are rebuilding TCP, and you are not going to do a good job'. I can't find the exact words, but a lot of wisdom on UDP versus TCP can be found in section 20.4 of Unix Network Programming, second edition. Bert From owner-namedroppers@ops.ietf.org Sun Aug 23 04:32: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 7A3893A6C51; Sun, 23 Aug 2009 04:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.75 X-Spam-Level: *** X-Spam-Status: No, score=3.75 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRSe74NGXhry; Sun, 23 Aug 2009 04:32:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F6FA3A6C34; Sun, 23 Aug 2009 04:32:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfBEv-0008Rd-H8 for namedroppers-data0@psg.com; Sun, 23 Aug 2009 11:28:01 +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 1MfBEr-0008Ql-MB for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 11:27:59 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MfBEl-0007Cc-Mb; Sun, 23 Aug 2009 12:27:51 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MfBEk-0006pd-SY; Sun, 23 Aug 2009 12:27:50 +0100 Message-ID: <76A22FF470BC41C6B947A8763E28EB21@localhost> From: "George Barwood" To: "bert hubert" , "Paul Vixie" Cc: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Sun, 23 Aug 2009 12:27:48 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: My take: (1) I don't think waiting for middleboxes to be upgraded is good strategy, so I think we really do need some kind of standard solution for stub <-> cache via a proxy that truncates responses at 512 bytes. If that's SCTP/TCP via a DNS@512 tunnel, that may be good, but I haven't seen a detailed concrete proposal. I think my page option is simpler, and as this is a kludge, I think simpler is probably better. (2) I do have serious security concerns regarding UDP fragmentation. IP fragments are completely unprotected against spoofing - no port number, no DNS ID, and a server IP ID that is highly predictable. Even the timing window is wide. So fetching the root (or any) DNSKEY RRset is highly dangerous ( even for non-open caches) - careful cache policy may help, but has BIND implemented this? Using TCP for responses > ethernet MTU seems just about ok, but sub-optimal, with the usual worries about the scalability of TCP. Issue (1) need not delay the deployment of the root. Issue (2) does I think need very careful consideration. Has signing .gov actually left it wide open to attack? "First of all, do no harm" should be the guiding principle here. George ----- Original Message ----- From: "bert hubert" To: "Paul Vixie" Cc: Sent: Sunday, August 23, 2009 10:47 AM Subject: Re: [dnsext] root DNSKEY response is 1749 bytes On Sun, Aug 23, 2009 at 7:53 AM, Paul Vixie wrote: >> 3. If some dastardly intermediate caching resolver doesn't return the >> DNSsec answers because it's faking answers, send the TCP query to the >> listed NS (cleverly saved above). >> ... > > if we're tearing the covers off again and declaring that dnssec still is > not deployable and needs another round of changes before it's safe to use, > then i have a small stack of late changes that i'd like to put in as well. Since I'm a DNSSEC implementor these days, I'd support this motion. >From what I make of it right now, we have two futures. 1) we stick with what we have (large keys, 5-15% of resolvers unable to receive fragmented packets), and prepare for large scale TCP use to compensate. The losers in this scenario are those who have to support the TCP traffic, and those that can't do outgoing TCP. 2) we implement workarounds, like 'paging', ecc cryptography and algorithm selection. The losers in this case are the poor implementors who have to implement all that. In addition, any workarounds will have to look like very normal <512 byte queries/responses, so we aren't caught by another round of middle boxes interfering. DJB pioneered this concept in DNSCurve. What people are still pondering is: 3) do nothing, and hope for the best. I would personally not be happy to promote '3' as is - any 'PowerDNSSEC' efforts would still not end up being used in large scale, since people will quickly turn off DNSSEC if it 'smells like downtime'. In addition, even if 3 is marginally workable, I'm pretty sure it won't be over (emergency) key rollovers, since that makes packet sizes balloon. '3' is basically '1' without preparing for increased TCP usage. Option 1 requires some guts, and for many servers, a lot of work to bring TCP performance up to scratch. EDNS0@512 is taking us in this direction already, if we want it or not. Option 2 may not be so easy either - 'paging' will also cause packet counts to go up, and require further maintenance of state. Because of proxies, each response 'page' will require a new query, causing packet counts to go up anyhow. In addition, Richard Stevens had some wise words to say about when you find yourself adding sequencing and retransmit logic to a UDP based protocol 'you are rebuilding TCP, and you are not going to do a good job'. I can't find the exact words, but a lot of wisdom on UDP versus TCP can be found in section 20.4 of Unix Network Programming, second edition. Bert From owner-namedroppers@ops.ietf.org Sun Aug 23 04:54: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 C756228B56A; Sun, 23 Aug 2009 04:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv0s+M4YzQMZ; Sun, 23 Aug 2009 04:54:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A04F13A6A09; Sun, 23 Aug 2009 04:54:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfBbI-000CSN-MM for namedroppers-data0@psg.com; Sun, 23 Aug 2009 11:51:08 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfBbE-000CRL-Fr for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 11:51:06 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 6AC771542839; Sun, 23 Aug 2009 12:51:01 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: <0D1483CE-5E00-40C1-A482-1CF353109043@rfc1035.com> From: Jim Reid To: William Allen Simpson In-Reply-To: <4A907B6D.1050905@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] TCP traffic and DNSSEC Date: Sun, 23 Aug 2009 12:50:59 +0100 References: <4A907B6D.1050905@gmail.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 23 Aug 2009, at 00:12, William Allen Simpson wrote: > Now, we've learned that a basic root query won't fit within 1500 > bytes, > let alone 1220 bytes. Of course, during key rollover, that'll be > bigger. > > Unless somebody has a magic wand, a heck of a lot of queries are > going to fall over to TCP. I'm troubled at the lack of meaningful data in this discussion. And maybe it's better to move a debate about operational considerations to dnsop? What is meant by "a heck of a lot of queries"? And what is the expected operational impact of that increased amount of TCP queries to important DNS servers: ie the root and busy TLD name servers? The statistics published at [hkm].root-servers.org indicate a root server gets somewhere between 10-16K qps in steady state. David Conrad said 70% of the queries to L have the DO bit set. Worst case, that suggests around 7-10K qps will go over TCP once the root is signed. It may be a lot, lot less than that assuming EDNS0 payloads are big enough and UDP fragmentation doesn't hurt. Based on these crude numbers, I can think of the following questions: [1] Can the existing servers cope with that level of TCP traffic? [2] If the answer to [1] is "yes", then we're done. Though it would be good to know where the upper bounds on TCP traffic rates were and the constraints on them. [3] If the answer to [2] is "no", then what needs to be done to fix that? Is it a matter of throwing more hardware and/or anycasting at the problem? Are there protocol or implementation tweaks which can be deployed? [eg Don't do EDNS with a 512 byte buffer limit when the DO bit is on.] From owner-namedroppers@ops.ietf.org Sun Aug 23 05:52:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C2B3A6C6D; Sun, 23 Aug 2009 05:52:20 -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 t4w16zO+V8TJ; Sun, 23 Aug 2009 05:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B1113A6CAC; Sun, 23 Aug 2009 05:52:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfCU1-000Lyx-E5 for namedroppers-data0@psg.com; Sun, 23 Aug 2009 12:47:41 +0000 Received: from [74.125.78.24] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfCTy-000LyS-5V for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 12:47:39 +0000 Received: by ey-out-2122.google.com with SMTP id 9so466331eyd.65 for ; Sun, 23 Aug 2009 05:47: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; bh=EOlAoQRY/BBbEN7RVRouALibXiwyIv9k83t5gCVmUOI=; b=OaeJFtn3HfXMswQVM74OF22NJeGloPtsrpcI/jn65twObe8QfasUBaEDBMW/QOupgy 1GFQtNk1Okk3AfPZGBY7BSHcwNxgABu/CadESLDXo7pYTygf8twT1e/DiIBB8wKwLJI+ UM9VUCAI6t32X/wt8e4+jePaqoy9vIu9Pay2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=dJ7dgLG0YQ5vqhbwVAo8drLg553DyelmWo0ApdOhWDSK0hV+1mGZswxYFmSzxt/8ob wzBfwOclGhlyV0sFZf2GbM/UUr2HYXyVL6WXE0yrGtvKb/a/gJ3lm+Lt2PyVMd067jm4 YjUxyNBlvYF+iMHiwsZmTs2EM/N4wnzNY5+iA= MIME-Version: 1.0 Received: by 10.211.202.9 with SMTP id e9mr3840055ebq.93.1251031656083; Sun, 23 Aug 2009 05:47:36 -0700 (PDT) In-Reply-To: <0D1483CE-5E00-40C1-A482-1CF353109043@rfc1035.com> References: <4A907B6D.1050905@gmail.com> <0D1483CE-5E00-40C1-A482-1CF353109043@rfc1035.com> From: bert hubert Date: Sun, 23 Aug 2009 14:47:16 +0200 Message-ID: <3efd34cc0908230547k174c31c0t1cae994344796c21@mail.gmail.com> Subject: Re: [dnsext] TCP traffic and DNSSEC To: Jim Reid Cc: William Allen Simpson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Aug 23, 2009 at 1:50 PM, Jim Reid wrote: > [1] Can the existing servers cope with that level of TCP traffic? Unless we perform some standards action, and get rid of: - If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. >From RFC 1035, section 4.2.2, it will definitely not be doable. Bert From sanitization@styleq.com Sun Aug 23 06:40: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 6F25E3A6A6C for ; Sun, 23 Aug 2009 06:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.818 X-Spam-Level: *** X-Spam-Status: No, score=3.818 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjpBampJbmUG for ; Sun, 23 Aug 2009 06:40:50 -0700 (PDT) Received: from droq.cheapnet.it (ip-87-238-2-55.static.adsl.cheapnet.it [87.238.2.55]) by core3.amsl.com (Postfix) with SMTP id 418DA3A6359 for ; Sun, 23 Aug 2009 06:40:48 -0700 (PDT) Message-ID: <3946914A.4010708@styleq.com> Date: Sun, 23 Aug 2009 15:40:57 +0200 From: Chere User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: dnsext-archive@ietf.org Subject: "high tea" given last winter b Content-Type: multipart/mixed; boundary="------------020109090802090708030602" This is a multi-part message in MIME format. --------------020109090802090708030602 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Elf--have been to blame? It lifts a load from us, fixing the blame on Society. There were periods in the play when we hardly knew what to think. The scientific father, the dead mother, the early husband! it was difficult to grasp the fact that they alone were to blame. One felt there was something to be said for even them. Ugly thoughts would cross our mind that perhaps the Heroine herself was not altogether irreproachable--that possibly there would have been less Problem, if, thinking a little less about her clothes, yearning a little less to do nothing all day long and be perfectly happy, she had pulled herself together, told herself that the world was not built exclusively for her, and settled down to the existence of an ordinary decent woman. Looking at the thing all round, that is perhaps the best solution of the Problem: it is Society that is to blame. We had better keep to that. CHAPTER IX Civilization and the Unemployed. Where Civilization fails is in not providing men and women with sufficient work. In the Stone Age man was, one imagines, kept busy. When he was not looking for his dinner, or eating his dinner, or sleeping off the effects of his dinner, he was hard at work with a club, clearing the neighbourhood of what one doubts not he would have described as aliens. The healthy Palaeolithic man would have had a contempt for Cobden rivalling that of Mr. Chamberlain himself. He did not take the incursion of the foreigner "lying down." One pictures him in the mind's eye: unscientific, perhaps, but active to a degree difficult to --------------020109090802090708030602 Content-Type: image/jpeg; name="mercerisers.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mercerisers.jpg" /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDADIiJSwlHzIsKSw4NTI7S31RS0VFS5ltc1p9tZ++u7Kf r6zI4f/zyNT/16yv+v/9////////wfD/////////////2wBDATU4OEtCS5NRUZP/zq/O//////// ////////////////////////////////////////////////////////////wAARCAFFARgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDR59M0 mfm5yOKM+vFAwWPfigBefUUYPrRgUYoAOfakyfUflS89qTJ9BQALnHUdfSl+b1H5Uik7RwaXJ/um gA59R+VJznqPypcn0NJk+hoAXn1H5Uhzg9MUvPoPzpDnHagBcH1H5UnI7j8qXHqTRgelACA/j9KG Jx070tIzDHHPIoAXB9fyFG0d+frRk+lGD6/lQAtJkDvRtHfn60vSgBM+gNGT6frS0UAJ83tR83qP ypaKAGrnJ5HX0oGcnkdfSlHU/WgdT9aAD5vajJ9PypaKAE3D3/KgEHoaWkIB6igAIB6ijHuRRj0J FHPsaADn1H5UZPcflRk+ho3D1oAZLJ5cbPn7oJxRSXX/AB6zf7jfyooAlpuAWPHalyPWj+I/SgAx 6E0c+xpaKAEyfSkJHfP5U6igBqsMClLD1FC/dH0o6UAG5fUfnSbhnqKdSdfpQAhPPf8AKgnjoetL SE8fjQAvPsKMH1oooANo9KG6fjS01iB1oAdRSZ9Afyo5+hoAWikx6k0bR6UAG4eufpRn2NLRQAmT 6frR83oPzpaKAGrnJ4HX1oGcngdfWlHU/WkU5GaAFyfSjPqDS0UAJuHrS0Um0f8A6qAFopMHsfzo yfTNAC0Um4e/5UAg9DQBFcqPssvb5D/Kiluv+PWb/cb+VFAEmM0mBuOOOKdSfxH6UAHPr+dGT6fl S0UAJn2P5UZHTNLRQIRfuj6UGkUAqOB0pdq+g/KgYDkUtNwM9BS7R6CgA3D1FIxGPxFOpD0oAMn0 /Ojn2paKAExmgjjgY5paRun4igBaKKKAEpaKSgBaKQketG4UALRSZ9jRk/3TQADqfrSJ93/PpQCc ng9aRT8p4P8AkUAOyPWlpvHofyo+XHXFADqKbj0NLzQIWikzz0paBhSEA9qWigCG6H+iy8n7jfyo pbr/AI9Zv9xv5UUAS9aT+I/SjA9KTHzHBPSgB1FJz7GjPqDQAtFJuHrS0AIv3R9KWkX7o+lLQAh6 ilpO9LQAUjdPxFLTWIx19KAHUUmeOATRz6YoAWkbp+Iowe5/Kk2j0zzQAu4eufpRk9h+dBKjqabv 9B+dJySHYdg+v5UFc803efX9KN5/vfpS5kFmPxzmimeZ6gH6U4EMMrTUkwaFooopiEHU/WmqcKf8 9qcOp+tCjg5oAa8hVtopolPtSvGHbIbFIYT2c/jQA8FW7YNLj3IpiIwcdMU85BNACHP1o3eoNB7U 6gBNw9RS0mKTb6cUAMuv+PWb/cb+VFJc5+yy8/wN/KigCak/iP0oBzR0OTQAtHH/AOqkJz7D0pM0 xXHUm0egpM0bqLBcAvyjr+dLtHv+dJupdwNFguIBn1/Ol2j3/Ol7cdKKQxNo9BQ3T8RS0h6UAFFL SM21fc9KG7ADMB1/KmFifYegpueck5NGaycrlpC0lGaaWwR71Nxjs00mm54OOue9GeKm47Ck0sDf vCPaoXarFqhVd56npTjqweiJM+xpcn+6aWiugyGgnng9aTPyt/n0pw6n600/cb/PpQAgpcmqc24W 8rEkbRtBH160pIiaJo5C+9gpBOc570DasW92Bk9qdu3Rhh3FVWYuzRFumST6j0qxH/x7pz/DQgas L2FOpvOBS59QaBC0Um4eopaAIrr/AI9Zv9xv5UUXX/HrN/uN/KigCTA5J496YXyc0Snan1NQF6pI iTJi9NL1Dvo3cH2qrEcxLvpN1RbuKCTjqM07Bcl30b6hycHmgHHGaLBcsLLtNT5BAI6GqBarcPMK 596mSKi7klNYjHX0pdo9BQ3T8RUGgA5PANRO2WJ/AVNVbPFZ1GVEdmmlvwpCaM5rK5dhc9ADSZJA pOPrSFqVxinFNZqazU6GFpTk8L60JXDYWCLzG3N90frVskDuBRtUAADgUAAdq6IxsjJu4bhRke/5 UtFUIaCAT1/KkP3G/wA+lOHf61FKGMDhOG7fpQBHOpkgdBgEjjNHlqH3BRu9cVCLmVP9ZFn6cUou k/iDg/TNK5XK0ThVCgbTwc1MoxEoHQCqgu4cck/kasxuJIFdeAc9RTQnfqPGcClpoJx0pdw78fWg QtJtHbj6UtFAEN0D9ll5/gb+VFLdf8es3+438qKACdMxHH8PNVM1oVUng2ksnTuPSri+hnJdSPr/ AFo6596ZmlzVmY7HvR+OaTNGaAF4pC1ITTSaAHAFmCjqa0Au1QB0HFQ20Oxd7cMentUxHPWs5O5r FWFpG6fiKNv1/OkYD09KksUMM4zmqrfKxB7VbqOWLzORw386icbrQqLsV91JupGRlPIpu1j0BrCx oOLUwtnpUq20jHn5R71YjhSPkDJ9TVqDYnJIhhti3zScD0q0AAMAYApCfmFLWyikZt3CiiimSFFF FAxo6n6/0pkkhigd1XftGcZxkU8dT9aRQCpBAIPBB78UARu0amIAlvNOFAGePX6VCjwzBG27Q5wp YYBPpT7a2dJVMpysQ2x8/r+WBTba0fyIFlYr5bbtoA65OOaAuKsULKrKqkNwpz1qyqbIwvTHpVGM ZuFkdcW7ufLU8Yf1I98HFT2X/Lx/13b+lA22yx0paTuKWgQmB6CjHoTS0UAQ3OfssvT7h/lRS3X/ AB6zf7jfyooAlpB94/SlpP4j9KAIZbYNynB9O1VXjZDggitGkOCOQCPQ1SlYhxTM3JozV428bc4K /SmfZFz98/lVcyJ5GU+Sat29ttw8g57LUsUSIAVXn1NSUnK+xSjbcKDRRUFBSN0/EUtIen40DFpM 80UYoELkd6QnjI45pQPSovPiY7VkUtgkYPXHvQMkPUUtRtIAqEnluRtBbP0xVf7VulYqxaL7OXwO MnPrQBaP3hTqpGdgod1aKLYhDKN3X6+lXe9ABRRRQIKKMUUDEHU/Wq107pb/ACA8nlgenSrIHJ+t QyxNLAVU4Jx9D0pPYqDSkrjpJGRF+6S7hQR0FLG5LyI2MpjkDGcimm3GwAMch94OO/0oCOpkcMpd 8YyCBxRqV7th80qRKDIep4HrUbC3EjAkI2fmwxX+WKS6g3rIyZLsAMcc80SkRGRt5STbnPGG9Oua LsFFNE4OenSlpqHcinGMgHHpTqZmwooooAiuv+PWb/cb+VFF1/x6zf7jfyooAlpB94/QUY9KTncf pQBU89oLeZWJaSNtq7jktn7p/wA+lTQy7o3LM7FGKt8vcY6AdqV7dHmWVs7l7Z4JHTP0zTPs7BJB HIctL5h5K5HcZFAEyyoylgwABwc8YP4/WnAgjI5HqKz3t5BI8jgbRJG3L5yBkHr9e9Mdi6XxjUr9 zAHX9KANNfuj6UtVJSkLJEBtXBO5pigJ6dupp9i7SWcbOSzEHk/U0AWKKKKBBSN0/EUtI3T8RQMK WkpaAIL3f9kk8vO7Hbr15/SkklSW3aOAFw0ZxtHA44FTkgAknAHNIXUpuDccGgLFcRzhIVwNixgE Byp3cdSP6UkFiI1w75/dmM4HqSc/rViOQSxh1zg+tRSzEGUBgnlqCOnJxmlcpRbdiRYI124BO0AD JJxj2qSq5LOY3kTfH5eSOMZ79adaAi1j3enf60XBxsrk3eqdk7SxRu/nOxPJBwvX8Py/Sre4cVDF AsSqqGQqvQbsUyTNMjrpzCQlhNyp64IPIP5VoWX/AC8f9d2/pUghj8tY/KUovIU8igwRsSTBESeS So/woApSSFpHulDExthAFJBQcHnpzk/SnjZIlzI8aSlWPDHGExxj+nr61cVQFKBEC9Nvaq7yQkuG t/M8lRk7FwBjPc0AMLeZdxkCVlMAbCvg9e/Iqw4l+z/uQVcchXOc89Cef50x3gaVQQ28pkGMN93P tUqSRgqgY7iMhWzuI/HmgCD7YxG9Y8xsQkWeCzH19qlNx5RIlAUhSw2nO7HX05pgtVFqsSNkxtuV j2bOf60ktvJcSAyFECqwG3nORj2oAnEqFUfcAHxtzxnNOqmQ7Jaw7G3xupbjjC8ZzUI3hpvKUCRr ghZM4wcjrQBp0UUlAEd1/wAes3+438qKLr/j1m/3D/KigCTI9aP4j9KXrTcDce3FAEEryi7jXIVM HGTweO9SPIYmQbc7mAJz0Jps1uZXU7uACDn6dqWWJmEYTGEIPJ64pamnuuxNjPHrTImjJZY8cHkA Ypdx3KNowepz0/xqKIn7TKSrANtwSpxwKLkpaMdHKhwA689OetS1WVhF5aRFuX2lD6c5qzQmElYK TqaWjpTJCmnp+IoyO5FDEY/EUAOopMn0owfXFAEV0pa2fDbcDJ9/am2z/ueEA27eV/iqZkDqVbkH 1o24UKOAMAUral8y5bEdurpbhCuHAOMnjv6U5o94AcjoA2Bgn8fSpKKLEuTvcayK2AyggdARxS4G c4paTNMVxaKSigQtFJS0DEHU/Wqq27PNcFmZUkVR8uOeMH1q0Op+tInT/PpQBVeIx3aFTIsawhAy LuPXp0NRyRPJeK8bOWSLcpYYyQx4PStCigDK3+ZptzKBgmYsPUZI/wAaty+ZHJIWkdIgo2FV3BeO c8f59aneKN02Milc5xjvTHt1cMAzIGXa23HI/GgCQZwDkc/lTWjVkZGjUq33gO9ORQiKi9FAAp1A CA9Bz+NLRRQBFdf8es3+4f5UUXX/AB6zf7jfyooAlpP4j9KTcR1U/hzSB13HnHHfigB9FFFACYB7 UYFLRQAi/dH0o2r6D8qF+6PpS0AJtX0H5UFRnOBR1paADFIRxS0jdPxFAC0Umc0UCFpGPH40hZQe SM0hYkcKevfigY7NFJ85/uj9f8KNuerMf0oAUkL94gfU0m8dgT9BShQDwADSmgBuW7Jj6mj5/VR+ GaSWQRIWKswAJO0dMVBa3yXMrIqMMDOTQBY2tn75/AUbT/fb9P8ACqb6gUW4PljMbbV9+vX8qkjl neQKrQOu35nTnafpnn9KAJwpyfnbr7f4Uirxw7D8v8Kgtp5pp5kJjAibBwp+br78dKLu4e2tw6BS SwHzfSgCzhv7/wCYo+cf3T+lV5bl4YmkIjcL1Ctg04XafZmmYMNvDJ3U5xigCbc3dD+BFG9R1O36 8Ux7mKNwkhKEnAyp5p6SI/3HDfQ0AKDnpS00ovpg+3FG0jox/EZoAdRSDOOevtS0ARXX/HrN/uN/ Kii6/wCPWb/cb+VFAEtJ1YjtgUnPYg0ZO48dqADYvYY+nFG1h0f8xml3D1pGdUIDMAT0zQAfOOyn 8cUbj3Q/hinVE1zEspjL/OOSNp4oAcrYUZVunpmjePRv++TSxkOgKkMMdqRJY5DhJEY9cKwNAC7x 6N/3yaN49G/75NDusYy7Ko6ZY4pWZUxuIGTgZ7mgBNx7I36Uh3EdAOfWmyXEcZYEklRk7VJx+X0p k1yqQeaqs8fXcpGOuPr+lAEoDEn5sfQUuwd8t9TTYXaRA5UKGAIw2eD68VCkrXF1KmSsUXB28En/ ACDQBZACjgAD24psriOMs2cDk4Gaz542jms1eVpSJerdeq1bupAIJELKGKEBc8nigBpvk8gSiNyG OEHGWP50TPcpvOI9gjY5HUHB/Pp+tVkt5XtbfYpEsLE7XBAPOf6CrTwyyu25hHGUK7RySTnk0AU4 Lj7WIreZzjkuScbzngVoRyozGOMjKcEAcCmLaRC3WFxvRemeD1oghS1iYs+7cdzOep/z/WgAupB5 MqAl3KkbVGTyKq2lrNazhihcMmG2kAqeKvmRQit1ViAMe9I0jCTYiBjjPJxRcdmVUtpxHMyMqSTN kq3IA54/Wnx2pW6MxVI1C7QkXQ/Xp/n6VPmU9AgP54psDyyKrsU2kdADn+dK4W0uR29u0U1w7bWE j5AHbr/jSXdu1zbhE2qQwPzfSrQPJ9qFYkUxFK6gaWBkS2UMcYII4qPUIJAZGgUssuA6qM8g5zWl RQBRv/8Aj7s/+un9RTNm/Vph5aSfIOH6dB7GtCmNBGz79uGxjcpKk/lQBUuZXge3VSYVZiGyQRjj nmpYrk/ajAzK+VyrL+uadJaiR4mMjZjbcM8+nH6UiwGG5MkajZJw46YPqP60AWaKYDn+KjaRQA26 /wCPWb/cb+VFNuT/AKLLnj5D/KigCbA9KTHzHBPSnUg+8fpQAjMEQs+NoFVUjM4eSbq4wB6Clkb7 TNtH+qjPPuakaSNSA7hC33c0tzRe6gtnLx7Wb50+U+/oarIwTWJssBlAOe/ApzMYZxKOn3XHtV04 YdiDQiZqzMYiQWM7ICITIMD2/wA7as32PLtfJA37h5XPb8fw61fGAoJOAB64pqxwx8qiIW4yoAzT JINQUOsKsMq0yg89RzVUs8UsNpISxSZWRvVf8/4dq0mEf8e04+YbucY70j+WNrNtJB+Unnn2oAoW kvkLOs2PN3EnPV/p69/zpUt5V0p4yCXY52+nI/wq+0ipkEnIG7HtTZJlRUP98jFA7NiQriCNWU5C AEfhTVtts7yxyMm/7ygAj6/z/OpA/wC+KY6DJNI5LSCMEjjJI9KAsMSygREXZu2EkEnnJp+YomEa hUJ6ADFInlCUBXYtzxkmoZGLb3VGJDAg9uP8mlcpRuyy7lWCqNzHnGcU1GaRD/AwOM9ajkaN5ELE qu3IbOKE8xYDsBOW+XPYUXHy6DkyJHXcWUAdfWluf+Pc/UfzFLGrquCoC/XJzTvL3RBHJbpk0+gr 63K7/u3WP+EuCv59KdIU+0/O5UbB/FjuasFAxBZQSDkZ7VGJoWcASLuPA56/T1pWDnHRbdvyHI9a bbArboCCCB0NN+1RYmOT+54b9aab6EWyz4YqW24AGQffmmTcsDqfrSJ0/wA+lQtdRpJIqq8mwZcq Bhf1pkF7HKxSJJHIGegHp6mgRboqF7mOMqJNyljhQVPPT0+tPjlSQkK3zDqCCCPwNAD6KKKACmt2 +tOpCMigBaTaO3H0oByKWgCG6B+yy8/wH+VFLdf8es3+438qKAJarXcuweWpwzDk+gqaWQRRl25A 7etZrl5JDnl2POP5VMnY0pxu7suwRgAIvT1qjrIxNH/u/wBa0bdBFGF796p6vE8hiZFJ6g4pomTu yWePbEjdioBp1jLlDETynT3FWXQNFsPcYrK3tBODj5kP50tmaR96NjUwGjwehGKqnMkSj+KNSfxB wP5GrSMrorIcqRxTVjVGdhnL9abVyIysMXEskjdRgKP5/wBahOZIlX+KNSfxHAq1DEsSbVzj3oWF ULsM5fk0WHzJbDIiJHd+oICj+f8AWoVUyIY+8alfxzx/KrUcaxJtXOKTCBmC43ZBOOtFhc1tiGB8 q8u0ncQMCpHR/MEiEZxgg96I54mR2VwQn3uOlQ/bd4iEaHfKflB7D1I/P8qLC5tbkwjdnDuQCAQA vvTgojjC/wAIwOaoXl3NAzxMVyQCrKMdx7+xovyW0yAnJYlfqflNFhNsuGaCMEbl+TqF5x+VPilS ZA8bBlP6Vn24m8698jbu3/xfU1a0/C24Ty2jKnDbhjJ9c96Yiq1/JJavIHVGBwFAye3rTpZWe9t1 Ykq0eWRDwTzTre0mS0eFmRA5OSOTU6WcSSRSLuBjXaBng9f8aAMyU5iuGiBRC4DRHsPX25q3eKs0 dulty2RtIz8o9T6dqu+Unm+btG/GN3elVFX7qhe3AxQBnXVu76lsUkRzAFseg/rxSvaSDVFI3eUW 8zOMgHqf5fyrRoI4oAz50PmTssdxE/8AD5WSJD68D+v602COVbx2uUkGUA3RhsZ47j/9VaK96E6f 59KAM+7+aa08ty37zG5ucHipIlb+02MzYcL8m0YDj/P+eKvUjKrEFlB2nIyM4NAC0UUUAFFFFACE dxSbh34p1FAENyc2suP7h/lRS3X/AB6zf7h/lRQBXvS/mcg7FGVOOM1XicxvuADVq1G0UbsdyKfw qXG+prGpZWaK6XifxArUd5PJJ5ZtpcY6jOKneyjP3Sy/jn+dQvYNztdT9RijUXuMuK25ASQTjnHr VO+iyPNXqOtRG0mU8LnHcMKY6XAUhhJt9wcUNlRik7pljTpuTEe/K/1FXqxBujYN90g5BPrWzE/m RI5GCwyRTTJqKzuh/aqN9kXNsAzASPhhuODyO1Xu1QTWyzSLI7v8nKgEAD9PamZFOVJRdXEtuSGi C8Z6rjkf5/nUtnMs89xIuQG2dfpVtIlR2cZ3PjJJ64GKQRJHnYgXcQTgdaBlO8twbqLYrbZmxKF6 EAjmpp7ZjcRTQ7QYxt2ngY/yTVkd6WgCqbRZZXkuAGLDaFByFH1x1prrDamLdvkK52FjnbVys+5/ e3qp2GBSbsaU4qT1LqKoyyoFLcnAwT9afRRTMxD0oHSgkUxp404LgUwJKMVWa9jHQk/SozfDsmfr RZhcuUceo/OqJvX7KBSfbJfb9afKxXLw78j86F4HJH51R+2S+360v2yX2/WjlYXL9FUReN3UGnre DupH0pWYXRboqBbqM98fWpFlVuhBpDH0lGQaXrQAUUUUARXX/HrN/uN/Kii6/wCPWb/cb+VFAA86 RFQ7Yz0zTlkRuVYH6GqGqdYvof6VGIYoow0rEMegB5p2Vrivqa2aTqOKzJJpIQCrnBHGTnNC6jIO HQHH4UcrC6NTHtSYFUl1JMfMjD6VKt9Cf48fUUWYE68qDk0oPWoVuoT0kXj1pftEP/PRPz/+vSsB NSHoaj+0xf8APRPz/wDr0huYQP8AWL+dMZNSN0/EVA17CP48/QVG2oRjoGNFmIt9OtFZ7ag38CAf WonupX/ix9KfKwuahdVGSQKzYZlFyZXPqRUR3sNzbiPU03HGcipa95I1i7Qb+Rea/XHyoT9ahe8l bpgVJJDF9pEQGASOFyW6e9OSFFHAVv3bEOehOff0q9DHUrgPLE7s5ITHB96Ft5WKjbjccDNTm4jQ HHLYTOOhIOTTPtQR8ouRvL/N7jFPUBqW2RuZ1CggZBz2okiWOFWLZZsgY6cGmxvIE2Ku4Zzjbnmn GOZwAVOByB0xQBDS1MLWQ+g/Gl+yP6r+dF0FiClqb7I/qv50v2V/VaLoLEFFSm2k9AfxpDDIOqH8 Oad0KwyijBHUUUAPWV16MalW7cfeANV6WlZBc1KWj1+tFZlkV1/x6zf7jfyoouv+PWb/AHG/lRQB Vv8AHnQZ6Z/wqu26V2Yna3bPpWlIFbhgCMd6rPFbtwVx9KadncTV1YpTZVQpZTg54q6USdAd3z3A XnHQr1qI2CsMxyfnzTPslxGco3I6FWxVtpkpWJGt0uHYxbUBkKjA9Fz64xUH2V2AZCChUtu6cDrS p9qgwFVgFO77uRnGKRbl0VYyo2qrKR3INGox81sQU8sZHlhmJOBk+5pgtZicbOd23qOuM083YZSj R/IVVcA88HinG+fMhCgFiCp/u9v5UahoQ/Z5eu3A2hskgDB6UtvCJZxGzYznkc1KL0iYyBSBgAKC AAB26VFFN5c/m7RnkgDgCnqA5LVpApVlG/O0HqcVJ9mRpIEViC6BjxUa3LKY9igeXnb360oM7hMK fk4B28j8aWoEkcMBLYYvtjYkZ6Ee9PjeFPJJCqrbi4Izx2qLyLiT75OP9pqjlhaEgMQcjtUydkaU 4czsPmlV4o1TjaoBGO9REggYXBHU5605wiuAuduB1pzOZW2qAi+gqOazbNnTfIk9O4/NzI27BDeo G0/nTo7WQZ+cLkYOPSp4y4QKsUjY/vDFPEU7dSifqarmZz2REtpGOuWp22GPsox61KLVT993f2zg UrRwQRlyi4UZyRk0rsCITIfu7m/3Rml3SH7sLH68VaBDAEEEHkEUUAVts5/gUfVqClwB0i/M1ZpG 6fjQBVxP6Rf99Um6VXVXCYY9jmmTzyxSKqwbw3AIb/61PfPmw54POcfSgCUAkZGKNrDt+VBfZEWw TjPSmxzJ5O8nHr7mlcVxT6EfnTTFG3VR+FSMQUyDkHFCgbeQO/WmMrtbKehIqNrZx0wau7Aemfwp pUr3yKfMxWJM8n60tJjr9aMUgI7r/j1m/wBw/wAqKS6yLaX/AHG/lRQMVl3sAelPGB8qqKZJxtI+ n6U6JxtweD/OgBGjRug2t7VH868cHFSEryQ/PoabkO3HXFADQzk4CZNKVlxzGCPrT1YBRjqaVDuJ GeR2oAhCxucNGuR2IoMcI6pGPqBUrqHHPDLURAeeEMARk5BHtQAmyD+7H+QoxAvOIx+AqQpbjO5U HOMbR/hTljjDDEaYPQ7RRcCHzol4DD6ClEufuo7fRasgoMAFRnkAd6b9oi2qQ4Idto9zQBEBO3SM L7s3+FRXNvK0W5iCV6KoqZ7xVR2CsShxg8ZHqPyNK858p2GAA4QH8QM/zpNDi+V3KdtZtLhpMqv6 mrzGO3iJVRgYGBUDM6tOhdpAoT2xknPSmpA7CUKoCsFI+XaDgnIx2oSsVObluTxztKGCBMggbgdy /wBKdA7tGzMQcE7SB1FRmCR95LKhcjIGSMD8utSqu1QC5bHoMfhxTIKyyzlFYNuZ4C4GOh4/xpvl tJHLt+YNGRxkgntye/4VcG1AAoAAGB7CgyUAPByASCPY9qKi3mmmQDqQPrQBPketMkdVQnrjsOTU e/0J/AUb29H/AO+TQBF5w/uSf98mkLb5Y8I4wTnK47VNvb0f/vk0bm9H/wC+TQAqDjj1NNlTfHtC g9h04pNyjvj9KUNno365oCwbAkYUDgYpQdq5JwBkk0EkjBNKrbex/CgCESZ9UhY8E1M5+XH0oOxl Kt0Ixg0MAEAHQYFA27knr9aKT1+tLQSRXX/HtL/uN/Kii6/49pf9xv5UUDFPXB6ECjjGG49GxTmQ H1H0NN2HOA2fqKAAooXkiiJDy3QHpSbSpz5Y/Cl80jrx9RigBgVlc44INSCRgcNj8qQsHwQcEdxS 7j3TJ9RTEMkck7gMDFNb5Z4fbP8AKpDyctjjoKbgGRXJOVzikxlZcuX3BznoAB/hV5RtWNfTj9KZ hc/xc+hP+NA2gg/NkepP+NHSwraldreUltoxsO1Oexzn+Y/KpGtCXbawC4+Qejcc/oKm8z60hf8A zmgY37MgMZY/cXaffj/65/OlESpD5aE9MZPP/wBak8zPQ5P+yKPmP8J+p4oAIUWHcfly2PujA/Kn mSmhGPUgfTmgxqBzk/U0ABfHUgfWk3M3QMakCqvRQPoKWgCIIx9B+tO8v1Y/hxThS0AM8tP7ufrz TgAOgA+lLRQAUUUUAIOp+tInT/PpSjqfrSJ0/wA+lADqQqrdVB+opaKAGGNcjAI+hpPLPZvzGaee opaBEW1x2B+hpuQOo2/UYqeigYmDk896OR6GjaD2ox6E0ARXR/0aXg/cb+VFF1n7NL0+4f5UUATU n8R+lLSfxH6UALRRRQA0qpPKgn1xSeWvoR9CafSUAMEYIB3MPxpfL/22/T/CnL90fSloAZ5f+236 f4UeWP7zfpT6KAGeWuecn8TQUUchRnPpTqQ9PxFADqKKKACkbp+IpaRun4igBaSjrS0AFFFRPcQx /flQEdieaAJaKpvqdsvRmb6L/jULaug+7Ex+pxQBpUVktq0nO2JR6ZOab/a0/wDcj/I/40Aa46n6 0idP8+lZH9qz8/JHz7H/ABoGqTj+CP8AI/40AbNFZQ1ds/NCCPZsVImrRn78TD6HNAGhRVZNRtm/ 5abT7g1PHLHIMo6t9DQIdRmlooAKKTFFAEd1/wAe0v8AuN/Kii6/49Zv9xv5UUDJaT+I/SiigBaK KKACiiigBF+6PpS0UUAFFFFABTW6fiKKKAFFLRRQAhODikPT8aKKAIru5+zR7tm72zis2TVJ2+7t T6DP86KKAKsk8sv35Gb2JplFFABRRRQAUUUUAFFFFABRRRQAUUUUASx3c8f3ZW+hOatR6tKv30Vv pxRRQBqRP5kYbGM9qfRRQBFdf8es3+438qKKKAP/2Q== --------------020109090802090708030602-- From owner-namedroppers@ops.ietf.org Sun Aug 23 08:41: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 012903A68E9; Sun, 23 Aug 2009 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=0.801, 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 HryyCb36SReb; Sun, 23 Aug 2009 08:41:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB33D3A6A63; Sun, 23 Aug 2009 08:41:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfF5w-0000dS-5D for namedroppers-data0@psg.com; Sun, 23 Aug 2009 15:35:00 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfF5s-0000cU-Gv for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 15:34:57 +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 n7NFYqpD039693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Aug 2009 08:34:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0908230547k174c31c0t1cae994344796c21@mail.gmail.com> References: <4A907B6D.1050905@gmail.com> <0D1483CE-5E00-40C1-A482-1CF353109043@rfc1035.com> <3efd34cc0908230547k174c31c0t1cae994344796c21@mail.gmail.com> Date: Sun, 23 Aug 2009 08:34:31 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] TCP traffic and DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 2:47 PM +0200 8/23/09, bert hubert wrote: >On Sun, Aug 23, 2009 at 1:50 PM, Jim Reid wrote: >> [1] Can the existing servers cope with that level of TCP traffic? > >Unless we perform some standards action, and get rid of: > > - If the server needs to close a dormant connection to reclaim > resources, it should wait until the connection has been idle > for a period on the order of two minutes. > > >From RFC 1035, section 4.2.2, it will definitely not be doable. Your reading of the "needs" and "should" in that sentence doesn't feel right. From an operational standpoint, that sentence reads: If a server needs to do X, it should not panic and just blindly do X; it should first consider the very important operational consideration Y. If the server is doing Y but it still is not operationally stable, go ahead and do X. We do not need to "perform some standards action" to allow server vendors to make their systems operationally sound. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Sun Aug 23 09:23: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 EB5BB3A67FE; Sun, 23 Aug 2009 09:23:45 -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 oLdkNz4kPaln; Sun, 23 Aug 2009 09:23:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1221C3A67A6; Sun, 23 Aug 2009 09:23:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfFmH-0009tj-Ng for namedroppers-data0@psg.com; Sun, 23 Aug 2009 16:18: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 1MfFmE-0009tD-0f for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 16:18:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 87C8DB3C5C for ; Sun, 23 Aug 2009 16:18:41 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Sun, 23 Aug 2009 11:47:54 +0200." <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 23 Aug 2009 16:18:41 +0000 Message-ID: <85278.1251044321@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > > if we're tearing the covers off again and declaring that dnssec still > > is not deployable and needs another round of changes before it's safe > > to use, then i have a small stack of late changes that i'd like to put > > in as well. i guess i'd better be specific. we need subclass names for metadata so that (1) we have no special rules about DS sets, and (2) we can query for individual RRSIG sets. crypto that's based on djb's curve but uses dnssec semantics (so, NS names aren't keys, and the security is end to end, but the signatures aren't so damned big). these by themselves would solve most of the "messages are too large" problem for the current middlebox generation. however, i threw the request out there mostly to scare folks. we're close to deployment of dnssec as it is. if we back off for another run at it, we will never be this close again. so, irritating as i find the tradeoffs we made to get this far, i am NOT advocating that we back off and try again. i will be one of the people looking for miracles when the TCP storm hits. From owner-namedroppers@ops.ietf.org Sun Aug 23 10:09: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 99E783A6D3B; Sun, 23 Aug 2009 10:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-0.880, 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 t1AzK1lkKWJ6; Sun, 23 Aug 2009 10:09:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8DC53A6D47; Sun, 23 Aug 2009 10:09:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfGUg-000KKR-HC for namedroppers-data0@psg.com; Sun, 23 Aug 2009 17:04:38 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfGUd-000KJ8-09 for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 17:04:36 +0000 Received: by ewy11 with SMTP id 11so1761491ewy.11 for ; Sun, 23 Aug 2009 10:04:33 -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=z1c2aZcdhoNSJ6iQldUuwox2P2CYUvf/BdQ9VTUFeCg=; b=m7H+UGIXJuZFlZuNB9vnIoNWxD6hM0Y8lEt5FAvFEluV9RU7zVgsmUZ7683Xvaij1t lMhgf3s13nvglhCeaJ2srnIiK7O356MxBr8PfGFYn81hRKBavQopUXfVN+cyTapFAi7j LapaJqGH9+phVz2jvIh6dJuz09ovqpLwY/Hgw= 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=Cc1+S6LsAwKBQvvEkK/oit43S3nfDF45slczCLClg2+3jKaeVOEv0hEeX863kTQ86Z p7gSzbZaF8MAMA1Nx1wbiDmZGFTpgDnr3UC6FmvhlHFKqRFW4C4mcCp8Oc4+LluMJMTH 3250NZ/nd/w9qMYyQ1XL5OHJpyR8rBX1OnF9g= MIME-Version: 1.0 Received: by 10.216.90.133 with SMTP id e5mr737106wef.23.1251047073779; Sun, 23 Aug 2009 10:04:33 -0700 (PDT) In-Reply-To: <85278.1251044321@nsa.vix.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <85278.1251044321@nsa.vix.com> Date: Sun, 23 Aug 2009 13:04:33 -0400 Message-ID: <1028365c0908231004w6812653eu395c6a9b91c49e2c@mail.gmail.com> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes From: Donald Eastlake To: Paul Vixie Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have pretty much always thought that, due to the size considerations, some form of elliptic curve cryptography was the right thing for DNSSEC. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Aug 23, 2009 at 12:18 PM, Paul Vixie wrote: >> > if we're tearing the covers off again and declaring that dnssec still >> > is not deployable and needs another round of changes before it's safe >> > to use, then i have a small stack of late changes that i'd like to put >> > in as well. > > i guess i'd better be specific. =A0we need subclass names for metadata so > that (1) we have no special rules about DS sets, and (2) we can query for > individual RRSIG sets. =A0crypto that's based on djb's curve but uses dns= sec > semantics (so, NS names aren't keys, and the security is end to end, but > the signatures aren't so damned big). =A0these by themselves would solve = most > of the "messages are too large" problem for the current middlebox generat= ion. > > however, i threw the request out there mostly to scare folks. =A0we're cl= ose > to deployment of dnssec as it is. =A0if we back off for another run at it= , we > will never be this close again. =A0so, irritating as i find the tradeoffs= we > made to get this far, i am NOT advocating that we back off and try again.= =A0i > will be one of the people looking for miracles when the TCP storm hits. > > From owner-namedroppers@ops.ietf.org Sun Aug 23 10:25: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 B20BC3A694A; Sun, 23 Aug 2009 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+a9zDCjycku; Sun, 23 Aug 2009 10:25:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0B913A683C; Sun, 23 Aug 2009 10:25:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfGmG-000Nb5-Qe for namedroppers-data0@psg.com; Sun, 23 Aug 2009 17:22: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 1MfGmD-000NaU-5K for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 17:22:46 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B0982B3C10 for ; Sun, 23 Aug 2009 17:22:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Sun, 23 Aug 2009 13:04:33 -0400." <1028365c0908231004w6812653eu395c6a9b91c49e2c@mail.gmail.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <85278.1251044321@nsa.vix.com> <1028365c0908231004w6812653eu395c6a9b91c49e2c@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 23 Aug 2009 17:22:44 +0000 Message-ID: <87876.1251048164@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Sun, 23 Aug 2009 13:04:33 -0400 > From: Donald Eastlake > > I have pretty much always thought that, due to the size considerations, > some form of elliptic curve cryptography was the right thing for DNSSEC. have you evaluated djb's curve for suitability and correctness for DNSSEC? you (donald) would be an ideal author for a draft in this area, in my view. i think that since algo roll is already contemplated in the DNSSEC design, and we're already looking into adding one for use in russia, that we ought to be looking at new algo's if they're fast enough and secure enough but also much smaller. From owner-namedroppers@ops.ietf.org Sun Aug 23 11:00: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 95CE73A6D55; Sun, 23 Aug 2009 11:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=0.771, 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 R6RgIsP+sEyv; Sun, 23 Aug 2009 11:00:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B08D928C167; Sun, 23 Aug 2009 11:00:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfHIn-00063u-BR for namedroppers-data0@psg.com; Sun, 23 Aug 2009 17:56:25 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfHIi-00062K-T3 for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 17:56:22 +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 n7NHuFg2046835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Aug 2009 10:56:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1028365c0908231004w6812653eu395c6a9b91c49e2c@mail.gmail.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <85278.1251044321@nsa.vix.com> <1028365c0908231004w6812653eu395c6a9b91c49e2c@mail.gmail.com> Date: Sun, 23 Aug 2009 10:56:13 -0700 To: Donald Eastlake , Paul Vixie From: Paul Hoffman Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 1:04 PM -0400 8/23/09, Donald Eastlake wrote: >I have pretty much always thought that, due to the size >considerations, some form of elliptic curve cryptography was the right >thing for DNSSEC. Indeed, that was part of the motivation for draft-hoffman-dnssec-ecdsa-00. The size and speed issues are discussed in the introduction of that document. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Sun Aug 23 11: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 81EAC3A6AB3; Sun, 23 Aug 2009 11:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.132 X-Spam-Level: **** X-Spam-Status: No, score=4.132 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAuaKSw9X927; Sun, 23 Aug 2009 11:36:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B104C3A68A8; Sun, 23 Aug 2009 11:36:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfHtg-000CDO-Gy for namedroppers-data0@psg.com; Sun, 23 Aug 2009 18:34:32 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfHtb-000CCr-Oe for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 18:34:30 +0000 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MfHta-0000H7-3s for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 19:34:26 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MfHtZ-0003c8-JE for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 19:34:25 +0100 Message-ID: From: "George Barwood" To: References: <406156C126454795B38BBC396D4DED73@localhost> <74329874920E437B883BB0B23B38BD93@localhost> <200908220111.n7M1BFE1029877@drugs.dv.isc.org> <5281A663D492453DB6C35DC47AC2BB9E@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Sun, 23 Aug 2009 19:34:23 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have uploaded another revision http://www.ietf.org/id/draft-barwood-dnsext-edns-page-option-03.txt The protocol itself has not changed significantly. Changes: Spoofing of fragments added to introduction. New section on amplification attacks in Security considerations. Potential firewall problems addressed in compatibiulity section. Packet formats described using the usual "boxes". Various typos/nits fixed. Thank you very much again for all your comments, George From owner-namedroppers@ops.ietf.org Sun Aug 23 11:37: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 698313A6B22; Sun, 23 Aug 2009 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=0.742, 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 NnGXc934X7SF; Sun, 23 Aug 2009 11:37:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 826F03A68A8; Sun, 23 Aug 2009 11:37:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfHrp-000Bxn-RE for namedroppers-data0@psg.com; Sun, 23 Aug 2009 18:32:37 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfHrl-000BwH-Fj for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 18:32:35 +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 n7NIWVuC048595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Aug 2009 11:32:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 23 Aug 2009 11:32:30 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Greetings again. At the WG meeting in Stockholm, I agreed to write this document to allow crypto algorithms in non-standards-track RFCs to get allocations from the IANA registry. I incorporated a variety of ideas from different folks, including a review of the new policy long before the registry gets full. The document also gives the motivations for the proposed change. Please consider adopting this short document as a WG work item. --Paul Hoffman >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Cryptographic Algorithm Identifier Allocation for DNSSEC > Author(s) : P. Hoffman > Filename : draft-hoffman-dnssec-alg-allocation-00.txt > Pages : 4 > Date : 2009-08-23 > >This document specifies how DNSSEC cryptographic algorithm >identifiers in the IANA registries are allocated. It changes the >rule from "standard required" to "RFC required". > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-00.txt From owner-namedroppers@ops.ietf.org Sun Aug 23 13:14: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 1CF753A6D70; Sun, 23 Aug 2009 13:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pfLhWoIGXu1; Sun, 23 Aug 2009 13:14:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2CECB3A6B6A; Sun, 23 Aug 2009 13:14:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfJLu-0005ro-BZ for namedroppers-data0@psg.com; Sun, 23 Aug 2009 20:07: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 1MfJLq-0005rC-QT for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 20:07:44 +0000 Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B09A52FE8CBB for ; Sun, 23 Aug 2009 20:07:40 +0000 (UTC) Date: Sun, 23 Aug 2009 16:07:38 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] TCP traffic and DNSSEC Message-ID: <20090823200735.GC1594@shinkuro.com> References: <4A907B6D.1050905@gmail.com> <0D1483CE-5E00-40C1-A482-1CF353109043@rfc1035.com> <3efd34cc0908230547k174c31c0t1cae994344796c21@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Aug 23, 2009 at 08:34:31AM -0700, Paul Hoffman wrote: > > We do not need to "perform some standards action" to allow server > vendors to make their systems operationally sound. Without wearing any hat, I think that is a really sensible principle to hang on to, in the DNS or anywhere else. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Sun Aug 23 13:19:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D260B3A6BD0; Sun, 23 Aug 2009 13:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 7y4FysxsrFHl; Sun, 23 Aug 2009 13:19:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E35A528C12C; Sun, 23 Aug 2009 13:19:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfJUl-0007Wb-MW for namedroppers-data0@psg.com; Sun, 23 Aug 2009 20:16:55 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfJUh-0007VI-Ob for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 20:16:53 +0000 Received: by ewy11 with SMTP id 11so1835727ewy.11 for ; Sun, 23 Aug 2009 13:16:49 -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=V8UVL/W0SVxT2jZEfcxjSPj424A2r5hO3/v2obnORjg=; b=j1UIeh1RBOo8DUI6hHemTrUCDDE5Nju/rMM5rnM7VCMpnI5FDRuJ29s7EeQZ6ZYD3Y fMsZ3TPGjm4NbwKQdTe66MroWQ/OVL+Fo8T20dTywIayC74zh5skj/cE1kqRNk4NIF2n CgWkvTiTmO8cdV7JCA4cTY7SVgbkoPtXccB28= 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=CHai5TT+javG77FPS5rIs+CqO0l24W16L/6OiV6/VtpURnKDoQGM5a+NV4u0ueBQhz 61EbOFouB7zTwhmwD/MYRPsBidDs0mrVVqtpJ95mu9kpq4pX3oTeIa+lt9/NlIjY6tRR R4VUO2YBXxd+dqvx0B2uBLyRzFwxD4S/fazug= MIME-Version: 1.0 Received: by 10.210.70.3 with SMTP id s3mr3937774eba.79.1251058609190; Sun, 23 Aug 2009 13:16:49 -0700 (PDT) In-Reply-To: <85278.1251044321@nsa.vix.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <85278.1251044321@nsa.vix.com> From: bert hubert Date: Sun, 23 Aug 2009 22:16:29 +0200 Message-ID: <3efd34cc0908231316x78e5e33ch3413023e98c9172a@mail.gmail.com> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes To: Paul Vixie Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Aug 23, 2009 at 6:18 PM, Paul Vixie wrote: > however, i threw the request out there mostly to scare folks. =A0we're cl= ose > to deployment of dnssec as it is. =A0if we back off for another run at it= , we > will never be this close again. =A0so, irritating as i find the tradeoffs= we > made to get this far, i am NOT advocating that we back off and try again.= =A0i > will be one of the people looking for miracles when the TCP storm hits. We might as well move to TCP then anyhow and be rid of the spoofing risks today :-) However, if you feel this way, perhaps we should add something to dnssec-updates that deprecates RFC 1035, section 4.2.2 (the two minute timeout). Bert From owner-namedroppers@ops.ietf.org Sun Aug 23 13:28: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 D609C28C161; Sun, 23 Aug 2009 13:28:49 -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 zRLr+SemfM3m; Sun, 23 Aug 2009 13:28:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17A4128C134; Sun, 23 Aug 2009 13:28:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfJd7-0009Gj-95 for namedroppers-data0@psg.com; Sun, 23 Aug 2009 20:25:33 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfJd1-0009Ex-HR for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 20:25:30 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3075FB3C89 for ; Sun, 23 Aug 2009 20:25:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Sun, 23 Aug 2009 22:16:29 +0200." <3efd34cc0908231316x78e5e33ch3413023e98c9172a@mail.gmail.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <85278.1251044321@nsa.vix.com> <3efd34cc0908231316x78e5e33ch3413023e98c9172a@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 23 Aug 2009 20:25:27 +0000 Message-ID: <94996.1251059127@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: bert hubert > Date: Sun, 23 Aug 2009 22:16:29 +0200 > ... > ..., perhaps we should add something to dnssec-updates that deprecates > RFC 1035, section 4.2.2 (the two minute timeout). it's not dnssec-specific, so we need a broader document scope for it. we also have to cope with the implementations who correctly syslog today when the responder closes a tcp connection. this calls for a phased implementation where in year 1-2 we adjust the initiators and in year 3-on we adjust the responders. From owner-namedroppers@ops.ietf.org Sun Aug 23 13:43: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 9B7FF28C14F; Sun, 23 Aug 2009 13:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.076 X-Spam-Level: X-Spam-Status: No, score=-5.076 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 En-IOLcLfwBv; Sun, 23 Aug 2009 13:43:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A30EE28C108; Sun, 23 Aug 2009 13:43:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfJr6-000CEu-Vm for namedroppers-data0@psg.com; Sun, 23 Aug 2009 20:40:00 +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 1MfJr0-000CCF-MC for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 20:39: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 n7NKdrKZ010962; Sun, 23 Aug 2009 13:39:54 -0700 (PDT) Message-Id: <7DA949B3-460C-4788-87D7-5C13A7638A51@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 v936) Subject: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? Date: Sun, 23 Aug 2009 13:39:53 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: My worry on the UDP fragmentation issue has always been the latency hit from the unpredictable timeouts, not the latency hit from TCP (simply because 3 RTTs vs 1 is nowhere near the same as a failure- timeout). But I think we can handle that by having the resolver learn when it has a fragmentation problem and use a smaller EDNS MTU to accommodate this. Thus the remaining concern is load on authorities if some fraction (say, 10% of queries if it only returns records using DNSSEC >1500B) fallback to TCP. Has anyone seen how many queries/second a standard Bind configuration on vanilla hardware can handle under TCP, both with the default (2 minute) timeout and a more aggressive 10 second timeout on idle connections? From owner-namedroppers@ops.ietf.org Sun Aug 23 15:32: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 81E3F3A6C7C; Sun, 23 Aug 2009 15:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 09ec5rFjMWyv; Sun, 23 Aug 2009 15:32:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A54DF3A69E8; Sun, 23 Aug 2009 15:32:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfLXJ-00044M-RE for namedroppers-data0@psg.com; Sun, 23 Aug 2009 22:27:41 +0000 Received: from [209.85.211.189] (helo=mail-yw0-f189.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfLXE-00043X-TS for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 22:27:38 +0000 Received: by ywh27 with SMTP id 27so2278936ywh.26 for ; Sun, 23 Aug 2009 15:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2MNrSZzgm8vSIXP701JOXcPxQImUVxACcfM4QKRVJFc=; b=NdulS6PpObVNI4aIai+50fEiIzgmsPJi291RWQq2NScIYLuD2bQ1vsMTMKuYp1Stfn a/dYBatbXIhoQuyWgid0jKHtLjkac+2ZzkgF8sNj1kf4iZSDKsCkFCT4GTgrwXQkAMYO 0akCbunByTrfukhBWdsh+uEdDEKTcZriq2l78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=nNM/pdrSYtt8au1tA9RmGwe+V5Xl8iqcFg/xlfhCoc3Fkw0qkljIUOMBlNOzDsQcvB QZEYNeqgKPWefpDuuNuE1bJrsDpjYhw/9Bnlp1kKmonid+fxe7H0O9K1azjVvf9MM5hS F/sOVazsH7sb+Q+xSHyXxCn1FiRXfaRmF7CLY= Received: by 10.90.173.8 with SMTP id v8mr3358026age.98.1251066456255; Sun, 23 Aug 2009 15:27:36 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 7sm4735868agb.41.2009.08.23.15.27.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Aug 2009 15:27:35 -0700 (PDT) Message-ID: <4A91C255.4010000@gmail.com> Date: Sun, 23 Aug 2009 18:27:33 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> In-Reply-To: <61661.1251006812@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Vixie wrote: >> Date: Sat, 22 Aug 2009 19:12:45 -0400 >> From: William Allen Simpson >> ... >> Could we please consider my earlier suggestion, breaking the problem into >> two parts? >> >> 1. Send a EDNS0 two part query for A and/or NS, with DO off, with the >> Algorithm Understood (AU) option. I've suggested that this be slightly >> extended to return the signature algorithms list with DO off. >> >> 2. If (and only if) a validating resolver, use TCP to query for the >> DNSsec records. >> >> 3. If some dastardly intermediate caching resolver doesn't return the >> DNSsec answers because it's faking answers, send the TCP query to the >> listed NS (cleverly saved above). >> ... > > if we're tearing the covers off again and declaring that dnssec still is > not deployable and needs another round of changes before it's safe to use, > then i have a small stack of late changes that i'd like to put in as well. > (Aware of your later posts) I wasn't suggesting a change to the DNSsec standard itself, merely a strategy that could be implemented on a case by case basis (in this case, a validating resolver), distributed as an application without major structural changes. If there are late changes, bring them up! It seems there's always going to be yet another round.... From owner-namedroppers@ops.ietf.org Sun Aug 23 15:34: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 DCEE63A6C7C; Sun, 23 Aug 2009 15:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.131, 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 Crt8ANXbpG2a; Sun, 23 Aug 2009 15:34:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 213F03A69E8; Sun, 23 Aug 2009 15:34:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfLbH-0004ng-5d for namedroppers-data0@psg.com; Sun, 23 Aug 2009 22:31:47 +0000 Received: from [209.85.211.189] (helo=mail-yw0-f189.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfLbD-0004n0-6H for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 22:31:44 +0000 Received: by ywh27 with SMTP id 27so2280653ywh.26 for ; Sun, 23 Aug 2009 15:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=E8LMyzbdozU90cIrowHV7RAYugG5Y7o/rn1hF+cZ86Y=; b=LULH1VPOVvdrPCGiCiroAHJZJBupCLxgvd0dLSDmcYTqZhLMMSrT8wX/uj0QD+90Pl hORtCDyg8sW9Xuvz8UyTotSffhv2F+pIFt7ilVRNnilFYlGdjORTU0rCnGPTO3BGs32T 59cumfrEd6t7NqaLwUQI2C/5OWY6oZdZrbY04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=VXlEiRsX7fSm8VZzimS0X2LxociQfh18sbbfNH2z8lv1A/iq253hN08TeaSmvDNKMY KYrKrJyoVevNPyXf6zOMLtn4ES8NsiWuFf94FMRhxUpmnL/TOGBYOcydRPLIErfV74DA DV6V5WkMwSs1qA9iiNtRpDm6GBcDEo/oemXdA= Received: by 10.90.58.29 with SMTP id g29mr3387766aga.44.1251066701166; Sun, 23 Aug 2009 15:31:41 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id 6sm4622595agd.32.2009.08.23.15.31.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Aug 2009 15:31:40 -0700 (PDT) Message-ID: <4A91C34A.1050307@gmail.com> Date: Sun, 23 Aug 2009 18:31:38 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <85278.1251044321@nsa.vix.com> <3efd34cc0908231316x78e5e33ch3413023e98c9172a@mail.gmail.com> <94996.1251059127@nsa.vix.com> In-Reply-To: <94996.1251059127@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Vixie wrote: >> From: bert hubert >> Date: Sun, 23 Aug 2009 22:16:29 +0200 >> ... >> ..., perhaps we should add something to dnssec-updates that deprecates >> RFC 1035, section 4.2.2 (the two minute timeout). > > it's not dnssec-specific, so we need a broader document scope for it. we > also have to cope with the implementations who correctly syslog today when > the responder closes a tcp connection. this calls for a phased > implementation where in year 1-2 we adjust the initiators and in year 3-on > we adjust the responders. > As Paul notes, the 2 minute TCP TIME-WAIT isn't DNSsec specific. But there are numerous old drafts and papers on how to change that, and nothing has been done in 18 years.... I'll send Bert my latest draft on it. From owner-namedroppers@ops.ietf.org Sun Aug 23 15:59: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 4EEBF3A6CEC; Sun, 23 Aug 2009 15:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.884 X-Spam-Level: * X-Spam-Status: No, score=1.884 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 KJqvBhMGl1hZ; Sun, 23 Aug 2009 15:59:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D17173A695E; Sun, 23 Aug 2009 15:59:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfLyd-000A7p-Vd for namedroppers-data0@psg.com; Sun, 23 Aug 2009 22:55:55 +0000 Received: from [209.85.220.228] (helo=mail-fx0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfLyZ-000A6q-8v for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 22:55:53 +0000 Received: by fxm28 with SMTP id 28so1305634fxm.41 for ; Sun, 23 Aug 2009 15:55:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.2.76 with SMTP id 12mr3853246fai.98.1251068149068; Sun, 23 Aug 2009 15:55:49 -0700 (PDT) In-Reply-To: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Mon, 24 Aug 2009 00:55:29 +0200 Message-ID: Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 To: Paul Hoffman Cc: Nicholas Weaver , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=00151747bf2c9d74750471d70058 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --00151747bf2c9d74750471d70058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Wed, Jul 29, 2009 at 10:42 PM, Paul Hoffman wrote: > At 9:59 AM -0700 7/29/09, Nicholas Weaver wrote: > >>>SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd > >>>like to see a formal commitment to shift to the Advanced Hash function > >>>winner after it gets NSA approval for Top Secret communication), but > >>>better. > >> > >>References please. > > > >Even as old as 2005 it was known SHA-1 had problems: > >http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html > >http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1 > > Please stop the FUD about SHA-1. Those articles are about probable problems > with SHA1's collision resistance. That is not applicable for the root > signing TLDs. Even if such a collision can be done (it still has not been > shown in practice, as compared to MD5), the scenario where it could be of > damage to DNSSEC is both obscure and trivial to detect. Paul, trying not to spread any FUD, could you please comment: http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html 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 ----------------------------------------- --00151747bf2c9d74750471d70058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2009 at 10:42 PM, Paul Hoffman <paul.hoffman@vpnc.org> wro= te:
At 9:59 AM -0700 7/29/09, Nicholas Weaver wrote:
>>>SHA-1 is a known problem. =C2=A0SHA-256 is better. =C2=A0Not be= tter ENOUGH (I'd
>>>like to see a formal commitment to shift to the Advanced Hash f= unction
>>>winner after it gets NSA approval for Top Secret communication)= , but
>>>better.
>>
>>References please.
>
>Even as old as 2005 it was known SHA-1 had problems:
>http://www.schneier.com/blog/archives/2005/02/cry= ptanalysis_o.html
>http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1

Please stop the FUD about SHA-1. Those articles are about probable pr= oblems with SHA1's collision resistance. That is not applicable for the= root signing TLDs. Even if such a collision can be done (it still has not = been shown in practice, as compared to MD5), the scenario where it could be= of damage to DNSSEC is both obscure and trivial to detect.

Paul,

trying not to spread any FUD, could you please commen= t:

http://www.schneier.com/blog/archives/2009/06/ever_better_cry= .html

Ondrej
--
Ondrej Sury
technicky reditel/Chief T= echnical Officer
-----------------------------------------
CZ.NIC, = z.s.p.o. =C2=A0-- =C2=A0.cz domain registry
Americka 23,120 00 Praha 2,= Czech Republic
mailto:ondrej.sury@nic.cz =C2=A0= http://nic.cz/
sip:ondrej.sury@nic.cz tel:+420.222745110
mob:+4= 20.739013699 =C2=A0 =C2=A0 fax:+420.222745112
-----------------------------------------


--00151747bf2c9d74750471d70058-- From owner-namedroppers@ops.ietf.org Sun Aug 23 16:21: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 D7BDD3A6CD2; Sun, 23 Aug 2009 16:21:15 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char DE hex): To: Ond\336ej Sur\230 ) id 1MfMHx-000EOD-MJ for namedroppers-data0@psg.com; Sun, 23 Aug 2009 23:15:53 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfMHq-000EMc-K8 for namedroppers@ops.ietf.org; Sun, 23 Aug 2009 23:15:50 +0000 Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7NNFM6v061815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Aug 2009 16:15:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> Date: Sun, 23 Aug 2009 16:15:19 -0700 To: OndÞej Sur˜ From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 12:55 AM +0200 8/24/09, OndÞej Sur˜ wrote: >trying not to spread any FUD, could you please comment: > >http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html Same comment as earlier on this thread: this is a better-yet attack on the collision resistance, as Bruce says quite clearly. We still haven't seen that there is a relationship between the ever-better attacks on collision resistance and any possible attack on the preimage resistance of any commonly-used hash algorithm. There could be such a relationship, of course; however, no cryptographer has said that they think such a relationship exists. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Sun Aug 23 18:19: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 D84BB3A6949; Sun, 23 Aug 2009 18:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgPA171mOTEc; Sun, 23 Aug 2009 18:19:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 621583A6961; Sun, 23 Aug 2009 18:19:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfO6c-000B6N-1R for namedroppers-data0@psg.com; Mon, 24 Aug 2009 01:12:18 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfO6T-000Ar1-4f for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 01:12: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 n7O1Aa8X009167; Mon, 24 Aug 2009 01:10:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7O1AVov009166; Mon, 24 Aug 2009 01:10:31 GMT Date: Mon, 24 Aug 2009 01:10:31 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: IETF DNSEXT WG Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? Message-ID: <20090824011031.GA7586@vacation.karoshi.com.> References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Aug 23, 2009 at 01:39:53PM -0700, Nicholas Weaver wrote: > > Has anyone seen how many queries/second a standard Bind > configuration on vanilla hardware can handle under TCP, both with the > default (2 minute) timeout and a more aggressive 10 second timeout on idle > connections? > ref the thread on e2e - initiated by Wm Simpson. standard bind on vanilla hw is not enough. TCP stack performance is really OS dependent. also - a 10sec timeout violates the DNS spec ... it has to be the 2min timeout. --bill From owner-namedroppers@ops.ietf.org Sun Aug 23 20:43: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 C9AE43A6D03; Sun, 23 Aug 2009 20:43: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 5w4LRVEczaax; Sun, 23 Aug 2009 20:43:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62E173A6C0A; Sun, 23 Aug 2009 20:43:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfQMm-00086b-OW for namedroppers-data0@psg.com; Mon, 24 Aug 2009 03:37: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 1MfQMj-00085T-0f for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 03:37:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AE0C9B3D41 for ; Mon, 24 Aug 2009 03:37:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Sun, 23 Aug 2009 18:27:33 -0400." <4A91C255.4010000@gmail.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <4A91C255.4010000@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 24 Aug 2009 03:37:03 +0000 Message-ID: <12038.1251085023@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Sun, 23 Aug 2009 18:27:33 -0400 > From: William Allen Simpson > > >> ... > >> Could we please consider my earlier suggestion, breaking the problem into > >> two parts? > >> > >> 1. Send a EDNS0 two part query for A and/or NS, with DO off, with the > >> Algorithm Understood (AU) option. I've suggested that this be slightly > >> extended to return the signature algorithms list with DO off. > >> > >> 2. If (and only if) a validating resolver, use TCP to query for the > >> DNSsec records. > >> > >> 3. If some dastardly intermediate caching resolver doesn't return the > >> DNSsec answers because it's faking answers, send the TCP query to the > >> listed NS (cleverly saved above). > >> ... > > > > if we're tearing the covers off again and declaring that dnssec still > > is not deployable and needs another round of changes before it's safe > > to use, then i have a small stack of late changes that i'd like to put > > in as well. > > (Aware of [vixie's] later posts) I wasn't suggesting a change to the > DNSsec standard itself, merely a strategy that could be implemented on a > case by case basis (in this case, a validating resolver), distributed as > an application without major structural changes. if it's not a requirement it will not happen at all since the pain will be felt by responders and the change you're recommending would have to happen at initiators. if it's made a requirement it could happen a little bit slowly over years. > If there are late changes, bring them up! It seems there's always going > to be yet another round.... i'd prefer to let sleeping ideas lay, until we have deployment experience to feed back into the next round. so, several years off, at a minimum. From owner-namedroppers@ops.ietf.org Sun Aug 23 20:43:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38BA3A6A59; Sun, 23 Aug 2009 20:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.075 X-Spam-Level: X-Spam-Status: No, score=-5.075 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 kulzz2TWxQ52; Sun, 23 Aug 2009 20:43:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5B6D3A68D4; Sun, 23 Aug 2009 20:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfQQp-0008n6-7W for namedroppers-data0@psg.com; Mon, 24 Aug 2009 03:41:19 +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 1MfQQl-0008m3-5i for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 03:41:17 +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 n7O3fDi1009380; Sun, 23 Aug 2009 20:41:13 -0700 (PDT) Cc: Nicholas Weaver , IETF DNSEXT WG Message-Id: <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> From: Nicholas Weaver To: bmanning@vacation.karoshi.com In-Reply-To: <20090824011031.GA7586@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 v936) Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? Date: Sun, 23 Aug 2009 20:41:12 -0700 References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> <20090824011031.GA7586@vacation.karoshi.com.> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 23, 2009, at 6:10 PM, bmanning@vacation.karoshi.com wrote: > On Sun, Aug 23, 2009 at 01:39:53PM -0700, Nicholas Weaver wrote: >> >> Has anyone seen how many queries/second a standard Bind >> configuration on vanilla hardware can handle under TCP, both with >> the >> default (2 minute) timeout and a more aggressive 10 second timeout >> on idle >> connections? >> > > ref the thread on e2e - initiated by Wm Simpson. > standard bind on vanilla hw is not enough. TCP stack > performance is really OS dependent. Do you have a URL for this thread? And for typical (eg, Linux, BSD)? > also - a 10sec timeout violates the DNS spec ... it has > to be the 2min timeout. This is one of those cases where if you violated the spec, so what? It should only be happening for resolvers with busted middleboxes, so who cares about their reinitiation latency on a 10s timeout vs 2 minutes? > > --bill > From owner-namedroppers@ops.ietf.org Sun Aug 23 21:45: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 0E7D83A6976; Sun, 23 Aug 2009 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4dSUOQeQWG2; Sun, 23 Aug 2009 21:45:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D9583A6946; Sun, 23 Aug 2009 21:45:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfRMY-000HQW-Tt for namedroppers-data0@psg.com; Mon, 24 Aug 2009 04:40:58 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfRMT-000HCo-CC for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 04:40: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 n7O4dU8X010832; Mon, 24 Aug 2009 04:39:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7O4dUE7010830; Mon, 24 Aug 2009 04:39:30 GMT Date: Mon, 24 Aug 2009 04:39:30 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? Message-ID: <20090824043930.GA10777@vacation.karoshi.com.> References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> <20090824011031.GA7586@vacation.karoshi.com.> <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Aug 23, 2009 at 08:41:12PM -0700, Nicholas Weaver wrote: > > On Aug 23, 2009, at 6:10 PM, bmanning@vacation.karoshi.com wrote: > > >On Sun, Aug 23, 2009 at 01:39:53PM -0700, Nicholas Weaver wrote: > >> > >> Has anyone seen how many queries/second a standard Bind > >> configuration on vanilla hardware can handle under TCP, both with > >>the > >>default (2 minute) timeout and a more aggressive 10 second timeout > >>on idle > >>connections? > >> > > > > ref the thread on e2e - initiated by Wm Simpson. > > standard bind on vanilla hw is not enough. TCP stack > > performance is really OS dependent. > > Do you have a URL for this thread? List-Archive: > And for typical (eg, Linux, BSD)? no idea what the limits are - there are 1000s of research papers that touch the subject. > > > also - a 10sec timeout violates the DNS spec ... it has > > to be the 2min timeout. > > This is one of those cases where if you violated the spec, so what? > It should only be happening for resolvers with busted middleboxes, so > who cares about their reinitiation latency on a 10s timeout vs 2 > minutes? er... not so much. back when the spec was written, the idea of and deployment of middleboxes was rare indeed. there must have been another reason for the 2min timeout. moving to TCP is a massive multiplier on consumption of system resource. thats a huge cost for operations. the cost has to be pushed back to the edge. --bill From owner-namedroppers@ops.ietf.org Sun Aug 23 21:50: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 8A8FF3A6B34; Sun, 23 Aug 2009 21:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 EM0p8olCup6h; Sun, 23 Aug 2009 21:50:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A65263A6976; Sun, 23 Aug 2009 21:50:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfRSV-000IDW-EB for namedroppers-data0@psg.com; Mon, 24 Aug 2009 04:47: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 1MfRSP-000IBV-5I for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 04:47:03 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4B927E6056; Mon, 24 Aug 2009 04:47:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7O4kvFj068158; Mon, 24 Aug 2009 14:46:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908240446.n7O4kvFj068158@drugs.dv.isc.org> To: Nicholas Weaver Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG From: Mark Andrews References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> <20090824011031.GA7586@vacation.karoshi.com.> <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? In-reply-to: Your message of "Sun, 23 Aug 2009 20:41:12 MST." <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> Date: Mon, 24 Aug 2009 14:46:57 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU>, Nicholas Weaver writes: > > On Aug 23, 2009, at 6:10 PM, bmanning@vacation.karoshi.com wrote: > > > On Sun, Aug 23, 2009 at 01:39:53PM -0700, Nicholas Weaver wrote: > >> > >> Has anyone seen how many queries/second a standard Bind > >> configuration on vanilla hardware can handle under TCP, both with > >> the > >> default (2 minute) timeout and a more aggressive 10 second timeout > >> on idle > >> connections? > >> > > > > ref the thread on e2e - initiated by Wm Simpson. > > standard bind on vanilla hw is not enough. TCP stack > > performance is really OS dependent. > > Do you have a URL for this thread? > > And for typical (eg, Linux, BSD)? > > > also - a 10sec timeout violates the DNS spec ... it has > > to be the 2min timeout. > > This is one of those cases where if you violated the spec, so what? > It should only be happening for resolvers with busted middleboxes, so > who cares about their reinitiation latency on a 10s timeout vs 2 > minutes? Except it isn't just these clients. It's also plain DNS clients that need to get a answer > 512. > > --bill > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Sun Aug 23 22: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 41F993A6A77; Sun, 23 Aug 2009 22:48:10 -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 OtTy4cEYugRJ; Sun, 23 Aug 2009 22:48:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54E7C3A690A; Sun, 23 Aug 2009 22:48:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfSKd-0001ER-3H for namedroppers-data0@psg.com; Mon, 24 Aug 2009 05:43:03 +0000 Received: from [80.64.7.197] (helo=mx10.tdc.fi) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfSKY-0001D4-OS for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 05:43:00 +0000 X-IronPort-AV: E=Sophos;i="4.44,263,1249246800"; d="scan'208";a="113780" Received: from fi-hel2ex01.nordiclan.net ([194.100.219.27]) by mail-gw1.tdc.fi with ESMTP; 24 Aug 2009 08:42:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Mon, 24 Aug 2009 08:42:55 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F1522C15B@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Signing the root with SHA-1 or SHA-2 Thread-Index: AcokSlN5cQ5UwuveQ4SxcvPJkvD4cgAM0HSA References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >-----Original Message----- >From: owner-namedroppers@ops.ietf.org = [mailto:owner->namedroppers@ops.ietf.org] On Behalf Of Paul Hoffman >Sent: 24. elokuuta 2009 2:15 >To: Ond=DEej Sur~ >Cc: namedroppers@ops.ietf.org >Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 > >At 12:55 AM +0200 8/24/09, Ond=DEej Sur~ wrote: >>trying not to spread any FUD, could you please comment: >> >>http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html > >Same comment as earlier on this thread: this is a better-yet attack on = the >collision resistance, as Bruce says quite clearly. We still haven't = seen >that there is a relationship between the ever-better attacks on = collision >resistance and any possible attack on the preimage resistance = of any >commonly-used hash algorithm. There could be such a = relationship, of relationship exists. > >--Paul Hoffman, Director >--VPN Consortium Related to SHA-2, I hope you all have seen this... http://eprint.iacr.org/2008/270.pdf --- Aki Tuomi From owner-namedroppers@ops.ietf.org Sun Aug 23 23:55: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 268D23A6DA7; Sun, 23 Aug 2009 23:55:33 -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 BXvpZbxfc6ny; Sun, 23 Aug 2009 23:55:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 432B03A6A44; Sun, 23 Aug 2009 23:55:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfTNZ-000F1e-N6 for namedroppers-data0@psg.com; Mon, 24 Aug 2009 06:50: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 1MfTNV-000EzT-BN for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 06:50:07 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F316AB3D63 for ; Mon, 24 Aug 2009 06:50:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? In-Reply-To: Your message of "Sun, 23 Aug 2009 20:41:12 MST." <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> <20090824011031.GA7586@vacation.karoshi.com.> <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 24 Aug 2009 06:50:04 +0000 Message-ID: <20587.1251096604@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Nicholas Weaver > Date: Sun, 23 Aug 2009 20:41:12 -0700 > > > also - a 10sec timeout violates the DNS spec ... it has to be the > > 2min timeout. > > This is one of those cases where if you violated the spec, so what? It > should only be happening for resolvers with busted middleboxes, so who > cares about their reinitiation latency on a 10s timeout vs 2 minutes? notwithstanding the fact that we can change the spec, and we must if we want tcp to be available, the problems will be felt beyond those who are behind busted middleboxes. right now it's correct to syslog() in the requestor when the responder closes a tcp/53 session. that's got to change. and it's not just a timeout value. if a responder knows it can only talk to N tcp initiators simultaneously, then at some point near N-1 it has to shorten the timeouts, all the way to zero if necessary. attackers in the current spec need only open some long running initiators who do nothing or who do things very slowly. we have to raise that bar or we just make the whole thing into a shiny new ddos target. make them open lots of sessions continuously, make them send queries soon after they open, insist that those queries be valid, insist that the receive windows be large enough for a response, and then be ready to close immediately after sending a response depending on how many connection slots are full, and do NOT keep the tcb around for 2*MSL (so, forget about FIN_WAIT_2). even so we will need something like djb's tcp cookies if we find no other solution to the fragmentation problem and are forced to rely on tcp here. From owner-namedroppers@ops.ietf.org Mon Aug 24 01:26: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 2C96A3A67E7; Mon, 24 Aug 2009 01:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[AWL=-0.517, 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 vpOcOB0ZC4Mc; Mon, 24 Aug 2009 01:26:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7B7A3A6832; Mon, 24 Aug 2009 01:26:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfUo5-0003kr-K3 for namedroppers-data0@psg.com; Mon, 24 Aug 2009 08:21: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 1MfUo1-0003kH-Dj for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 08:21:35 +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 1MfUnm-0005pN-Vq; Mon, 24 Aug 2009 10:21:18 +0200 Received: by bfk.de with local id 1MfUnm-0005qV-Oo; Mon, 24 Aug 2009 08:21:18 +0000 To: Paul Hoffman Cc: =?utf-8?B?T25k3mVqIFN1csKY?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> From: Florian Weimer Date: Mon, 24 Aug 2009 08:21:18 +0000 In-Reply-To: (Paul Hoffman's message of "Sun\, 23 Aug 2009 16\:15\:19 -0700") Message-ID: <82eir1lj0h.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Paul Hoffman: > Same comment as earlier on this thread: this is a better-yet attack > on the collision resistance, as Bruce says quite clearly. We still > haven't seen that there is a relationship between the ever-better > attacks on collision resistance and any possible attack on the > preimage resistance of any commonly-used hash algorithm. Signatures on DS records require some form of collision resistance, not preimage resinstance, because you sign attacker-provided data. Randomized hashing can provide a workaround, as discussed before. (This is really quite different from that HMAC stuff.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 24 07:50: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 221F03A6BAA; Mon, 24 Aug 2009 07:50:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F2 hex): Cc: Ond?ej Sur\362 ) id 1Mfak8-0009K8-9P for namedroppers-data0@psg.com; Mon, 24 Aug 2009 14:41:56 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfak4-0009Ix-Sj for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 14:41:54 +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 n7OEfOPD012422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 07:41:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82eir1lj0h.fsf@mid.bfk.de> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <82eir1lj0h.fsf@mid.bfk.de> Date: Mon, 24 Aug 2009 07:41:23 -0700 To: Florian Weimer From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Cc: Ond?ej Surò , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 8:21 AM +0000 8/24/09, Florian Weimer wrote: >* Paul Hoffman: > >> Same comment as earlier on this thread: this is a better-yet attack >> on the collision resistance, as Bruce says quite clearly. We still >> haven't seen that there is a relationship between the ever-better >> attacks on collision resistance and any possible attack on the >> preimage resistance of any commonly-used hash algorithm. > >Signatures on DS records require some form of collision resistance, >not preimage resinstance, because you sign attacker-provided data. >Randomized hashing can provide a workaround, as discussed before. With all due respect, this is FUD. Please re-read the thread. Earlier, I said: At 10:42 PM +0200 7/29/09, Paul Hoffman wrote: >Even if such a collision can be done (it still has not been shown in practice, as compared to MD5), the scenario where it could be of damage to DNSSEC is both obscure and trivial to detect. That statement is still true. Even when SHA-1 collisions become practical, a signer detecting them is trivial. The scenario you are talking about is a fully-automated certificate authority who is doing no checking of what they are signing. I do not believe that anyone in the DNSSEC community believes that this will be true of signing the root. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Aug 24 07:56: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 BC5493A6DB6; Mon, 24 Aug 2009 07:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=-0.470, 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 OS7Q4pYqq70l; Mon, 24 Aug 2009 07:56:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEF983A6E2C; Mon, 24 Aug 2009 07:56:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfauE-000BjF-Ir for namedroppers-data0@psg.com; Mon, 24 Aug 2009 14:52:22 +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 1Mfau8-000BiI-Ue for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 14:52:19 +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 1Mfatv-0005O9-H3; Mon, 24 Aug 2009 16:52:03 +0200 Received: by bfk.de with local id 1Mfatv-0004Uf-CW; Mon, 24 Aug 2009 14:52:03 +0000 To: Paul Hoffman Cc: , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <82eir1lj0h.fsf@mid.bfk.de> From: Florian Weimer Date: Mon, 24 Aug 2009 14:52:03 +0000 In-Reply-To: (Paul Hoffman's message of "Mon\, 24 Aug 2009 07\:41\:23 -0700") Message-ID: <82ocq5gt7w.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Paul Hoffman: > At 8:21 AM +0000 8/24/09, Florian Weimer wrote: >>* Paul Hoffman: >> >>> Same comment as earlier on this thread: this is a better-yet attack >>> on the collision resistance, as Bruce says quite clearly. We still >>> haven't seen that there is a relationship between the ever-better >>> attacks on collision resistance and any possible attack on the >>> preimage resistance of any commonly-used hash algorithm. >> >>Signatures on DS records require some form of collision resistance, >>not preimage resinstance, because you sign attacker-provided data. >>Randomized hashing can provide a workaround, as discussed before. > > With all due respect, this is FUD. Huh? > Please re-read the thread. Earlier, I said: > > At 10:42 PM +0200 7/29/09, Paul Hoffman wrote: >>Even if such a collision can be done (it still has not been shown in >>practice, as compared to MD5), the scenario where it could be of >>damage to DNSSEC is both obscure and trivial to detect. This statement is true, *except* for signatures on DS records. If an attack is performed against them, it is as trivial to detect as a forged X.509 certificate created using Lenstra et al.'s method. That is, not trivial at all. DNSSEC can't magically defuse the effect of bad crypto algorithms. Through its delegation concept, it has less exposure than other frameworks because you generally sign only your own data, but at the delegation points, you need a good signature algorithm because that assumption doesn't hold. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 24 09:16: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 4871B28C125; Mon, 24 Aug 2009 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.822 X-Spam-Level: X-Spam-Status: No, score=-3.822 tagged_above=-999 required=5 tests=[AWL=0.673, 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 yJmG0Bpl3Y6s; Mon, 24 Aug 2009 09:16:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B5C728C217; Mon, 24 Aug 2009 09:16:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfc84-000PYV-Q5 for namedroppers-data0@psg.com; Mon, 24 Aug 2009 16:10:44 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfc7q-000PVg-Oe for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 16:10:37 +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 n7OGA6eJ018883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 09:10:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82ocq5gt7w.fsf@mid.bfk.de> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <82eir1lj0h.fsf@mid.bfk.de> <82ocq5gt7w.fsf@mid.bfk.de> Date: Mon, 24 Aug 2009 09:10:05 -0700 To: Florian Weimer From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Cc: , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 2:52 PM +0000 8/24/09, Florian Weimer wrote: > > At 10:42 PM +0200 7/29/09, Paul Hoffman wrote: > >>>Even if such a collision can be done (it still has not been shown in >>>practice, as compared to MD5), the scenario where it could be of >>>damage to DNSSEC is both obscure and trivial to detect. > >This statement is true, *except* for signatures on DS records. OK, I'm missing something. Please show how the zone admin for badactor.com can mount an attack on example.com using DS records signed using a hash algorithm for which collisions are trivial but primages are impossible. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Aug 24 14:10: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 339523A6914; Mon, 24 Aug 2009 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQevaaZaxMT0; Mon, 24 Aug 2009 14:10:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35A233A6EA5; Mon, 24 Aug 2009 14:10:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfgiv-000KXy-Om for namedroppers-data0@psg.com; Mon, 24 Aug 2009 21:05:05 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfgiq-000KUt-12 for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 21:05:01 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 09B81327A75; Mon, 24 Aug 2009 21:04: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 2B259327A70; Mon, 24 Aug 2009 21:04:53 +0000 (UTC) Message-ID: <4A930075.7080503@isc.org> Date: Mon, 24 Aug 2009 16:04:53 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nicholas Weaver CC: "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Suggested fallbacks... 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Weaver wrote: > I think at this point we can presume "UDP Fragmentation is a problem for > some". > > > So stupid quesiton: Why not just have the resolver discover for itself > when its the problem, and do something about it? > > > The resolver already needs to keep track of EDNS0 fallback for every > particular authority, no? (If you don't you get bad behavior where a > non-EDNS-liking authority will see eg, 3 second latency. We experienced > this in Netalyzr's F&F testing). This is a cache, and a short-lived cache at times. IMHO, any design that relies on discovering and performance is based on remembering such data is flawed. > EDNS@4096. If failed, fallback to EDNS@1400. If success, and the > response was > 1500B, record the server as "MTU > 1500" Please define "the server" here. do you mean the remote server? That is, the thing that answered? If so, I don't think this makes a lot of sense. I would suspect that the limiting factor on what can be received is not on the sending end (as this tracking would imply) but on the receiving end. Therefore, learning the safe fallback might help, but it should be "what I can safely receive" not "what that server over there, that I now need to maintain state about, can send me." I don't think it's practical to expect to maintain state on every auth server I might speak to. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTAHUACgkQ+NNi0s9NRJ0YwgCfRiQWjQueWnaBN7nQJ+KBtzUi 6koAn0uoUHjg7mLwgw9uxpI21FJK4Clc =b2je -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 14:11: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 CA8253A6EA5; Mon, 24 Aug 2009 14:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs5vpRGYhB+I; Mon, 24 Aug 2009 14:11:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0EA243A6B04; Mon, 24 Aug 2009 14:11:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfgm5-000L1i-1n for namedroppers-data0@psg.com; Mon, 24 Aug 2009 21:08:21 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfgm0-000L0q-O3 for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 21:08:18 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 03472327A7E; Mon, 24 Aug 2009 21:08:16 +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 6396A327A75; Mon, 24 Aug 2009 21:08:15 +0000 (UTC) Message-ID: <4A93013E.6030806@isc.org> Date: Mon, 24 Aug 2009 16:08:14 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: bert hubert CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> In-Reply-To: <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bert hubert wrote: > In addition, Richard Stevens had some wise words to say about when you > find yourself adding sequencing and retransmit logic to a UDP based > protocol 'you are rebuilding TCP, and you are not going to do a good > job'. I can't find the exact words, but a lot of wisdom on UDP versus > TCP can be found in section 20.4 of Unix Network Programming, second > edition. This is exactly my argument against the page option. I've fought against adding TCP-like features to UDP protocols for years now, back when IRC servers had connection problems. Now they can accept thousands of TCP sessions per second and not flinch. So, I say again, why are people actually scared of TCP? It's come a very long way since 1980. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTAT4ACgkQ+NNi0s9NRJ0G9QCgiMnZn6nuIILEC7LqX+zsR0Ol v2kAn0PdhHOsrLSurx612BRnfPQ4XKTm =btPw -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 14:17: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 18C123A696B; Mon, 24 Aug 2009 14:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFDa6XA0rL3G; Mon, 24 Aug 2009 14:17:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31BB628C1D7; Mon, 24 Aug 2009 14:17:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfgrz-000LwY-0q for namedroppers-data0@psg.com; Mon, 24 Aug 2009 21:14:27 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfgru-000LvV-Fe for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 21:14:24 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id D43FA327A7E; Mon, 24 Aug 2009 21:14:21 +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 403EE327A75; Mon, 24 Aug 2009 21:14:21 +0000 (UTC) Message-ID: <4A9302AC.1060502@isc.org> Date: Mon, 24 Aug 2009 16:14:20 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Vixie CC: IETF DNSEXT WG Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> <20090824011031.GA7586@vacation.karoshi.com.> <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> <20587.1251096604@nsa.vix.com> In-Reply-To: <20587.1251096604@nsa.vix.com> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: > attackers in the current spec need only open some long running initiators > who do nothing or who do things very slowly. we have to raise that bar > or we just make the whole thing into a shiny new ddos target. make them > open lots of sessions continuously, make them send queries soon after they > open, insist that those queries be valid, insist that the receive windows > be large enough for a response, and then be ready to close immediately > after sending a response depending on how many connection slots are full, > and do NOT keep the tcb around for 2*MSL (so, forget about FIN_WAIT_2). I will ask this in another thread. How is this at all any difference than what we have today, as an attack vector? This is not the future threat, it is a current one. It's not a shiny new target, that is. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTAqwACgkQ+NNi0s9NRJ0mxACfVdLiFYNJuYzhnw+R8PKX4ave 0usAni03KzfaW2zPA0EXYbA6kbjsIyLP =tr8H -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 14:40: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 CA6C43A6EDB; Mon, 24 Aug 2009 14:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 wST1EdNl24tP; Mon, 24 Aug 2009 14:40:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4EC93A6ECD; Mon, 24 Aug 2009 14:40:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfhDZ-000PEp-A7 for namedroppers-data0@psg.com; Mon, 24 Aug 2009 21:36:45 +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 1MfhDV-000PE1-LR for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 21:36:43 +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 n7OLaOao010457; Mon, 24 Aug 2009 14:36:25 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org WG" Message-Id: <4BD3675E-BF4F-4AFA-B2FB-638AFBE7CE31@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A930075.7080503@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Suggested fallbacks... Date: Mon, 24 Aug 2009 14:36:24 -0700 References: <4A930075.7080503@isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 24, 2009, at 2:04 PM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: >> I think at this point we can presume "UDP Fragmentation is a >> problem for >> some". >> >> >> So stupid quesiton: Why not just have the resolver discover for >> itself >> when its the problem, and do something about it? >> >> >> The resolver already needs to keep track of EDNS0 fallback for every >> particular authority, no? (If you don't you get bad behavior where a >> non-EDNS-liking authority will see eg, 3 second latency. We >> experienced >> this in Netalyzr's F&F testing). > > This is a cache, and a short-lived cache at times. IMHO, any design > that relies on discovering and performance is based on remembering > such > data is flawed. Then you get REALLY cruddy performance: This is data that should already be cached per authority. Bind does do this already, but I've seen the results when a resolver does not and the authority ignores/ fails on EDNS: its ugly. >> EDNS@4096. If failed, fallback to EDNS@1400. If success, and the >> response was > 1500B, record the server as "MTU > 1500" > > Please define "the server" here. do you mean the remote server? That > is, the thing that answered? Authority. > If so, I don't think this makes a lot of sense. I would suspect that > the limiting factor on what can be received is not on the sending end > (as this tracking would imply) but on the receiving end. Therefore, > learning the safe fallback might help, but it should be "what I can > safely receive" not "what that server over there, that I now need to > maintain state about, can send me." Its the observation that you are doing a TRW count: the # of remote authorities you can contact where you CAN get a >1500B response vs the # of authorities you can't. When the difference between the two exceeds a threshold, you have learned you are behind a broken middlebox. This is a long-lived property, > I don't think it's practical to expect to maintain state on every auth > server I might speak to. A: Don't you do this already? All those cached NS records are state about each authority you may talk to. B: If you are so afraid of per-authority state, just use two bloom filters, one thats "This authority can give me a >1500B response" and "this authority can NOT give me a >1500B response". For this purpose, the single-sided error of a bloom filter is no problem, you aren't using this to actually decide a local property of a given authority, but just to track whether it has already been included in the trouble/OK count or not. So although I'll argue the per-authority state should already be there, if not, you don't need per-authority state but can used bounded state just as well. From owner-namedroppers@ops.ietf.org Mon Aug 24 15:02:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E0C3A6978; Mon, 24 Aug 2009 15:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 4vXpPrHVbxJ9; Mon, 24 Aug 2009 15:02:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70B723A6B5A; Mon, 24 Aug 2009 15:02:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfhZH-0002GT-9Z for namedroppers-data0@psg.com; Mon, 24 Aug 2009 21:59:11 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfhZD-0002Ft-8N for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 21:59:09 +0000 Received: (qmail 28597 invoked by uid 399); 24 Aug 2009 21:59:03 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Aug 2009 21:59:03 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A930D22.2090009@dougbarton.us> Date: Mon, 24 Aug 2009 14:58:58 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Michael Graff CC: Nicholas Weaver , "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Suggested fallbacks... References: <4A930075.7080503@isc.org> In-Reply-To: <4A930075.7080503@isc.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Michael Graff wrote: > I don't think it's practical to expect to maintain state on every auth > server I might speak to. Why not? BIND at least already keeps a running record of RTT for each authority you query. This would just be one more data point, and unlike RTT it would be static (for all practical purposes). Doug From owner-namedroppers@ops.ietf.org Mon Aug 24 15:11: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 D06AB3A6831; Mon, 24 Aug 2009 15:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dolm9uS7zB8i; Mon, 24 Aug 2009 15:11:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F238028C32B; Mon, 24 Aug 2009 15:11:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfhhi-0003OL-9H for namedroppers-data0@psg.com; Mon, 24 Aug 2009 22:07:54 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfhhb-0003Bn-AJ for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 22:07: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 n7OM4p8X018098; Mon, 24 Aug 2009 22:04:51 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7OM4pQa018097; Mon, 24 Aug 2009 22:04:51 GMT Date: Mon, 24 Aug 2009 22:04:51 +0000 From: bmanning@vacation.karoshi.com To: Michael Graff Cc: bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <20090824220451.GF17279@vacation.karoshi.com.> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A93013E.6030806@isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 04:08:14PM -0500, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > bert hubert wrote: > > > In addition, Richard Stevens had some wise words to say about when you > > find yourself adding sequencing and retransmit logic to a UDP based > > protocol 'you are rebuilding TCP, and you are not going to do a good > > job'. I can't find the exact words, but a lot of wisdom on UDP versus > > TCP can be found in section 20.4 of Unix Network Programming, second > > edition. > > This is exactly my argument against the page option. I've fought > against adding TCP-like features to UDP protocols for years now, back > when IRC servers had connection problems. > > Now they can accept thousands of TCP sessions per second and not flinch. > So, I say again, why are people actually scared of TCP? It's come a > very long way since 1980. sure you can -accept- thousands of TCP sessions per second. how many can you keep open? what is your criteria for dropping one? how many TCP sessions lose state partway through the handshake? remember that DNS sez you -MUST- keep a TCP session open for 120 seconds. my numbers indicate about 5% state loss for TCP (any TCP) -IF- one migrates the 25,000 qps over UDP on some servers, my rough calculations seem to indicate we wouldneed to keep 175,000 qps over TCP for the exact same query loading... 150,000 of those are half-open TCP sessions that got lost. again, how many can you keep open and what is the criteria for closing a TCP session. > > - --Michael From owner-namedroppers@ops.ietf.org Mon Aug 24 15:34: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 28FCD3A6ED2; Mon, 24 Aug 2009 15:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.073 X-Spam-Level: X-Spam-Status: No, score=-5.073 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 re66CFOOLHCW; Mon, 24 Aug 2009 15:34:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 964F33A6D3D; Mon, 24 Aug 2009 15:34:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfi3q-00076T-Uh for namedroppers-data0@psg.com; Mon, 24 Aug 2009 22:30:46 +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 1Mfi3m-00075u-U6 for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 22:30:44 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n7OMUbPA016214; Mon, 24 Aug 2009 15:30:37 -0700 (PDT) Cc: Nicholas Weaver , Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> From: Nicholas Weaver To: bmanning@vacation.karoshi.com In-Reply-To: <20090824220451.GF17279@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 v936) Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Mon, 24 Aug 2009 15:30:37 -0700 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 24, 2009, at 3:04 PM, bmanning@vacation.karoshi.com wrote: > > sure you can -accept- thousands of TCP sessions per second. > how many can you keep open? > what is your criteria for dropping one? > how many TCP sessions lose state partway through the handshake? > > remember that DNS sez you -MUST- keep a TCP session open for > 120 seconds. Why? That number is a holdover from when DNS over TCP was used primarily for zone transfers. IF it ends up being a common fallback mechanism for ~10% of the queries, thats a completely different story and a much more agressive timeout is far more appropriate. In fact, if its being used primarily as a fallback for normal queries, a keepalive at all is probably inappropriate, and simply closing the connection after each query would probably serve things almost as well. > my numbers indicate about 5% state loss for TCP (any TCP) > > -IF- one migrates the 25,000 qps over UDP on some servers, my rough > calculations seem to indicate we wouldneed to keep 175,000 qps over > TCP > for the exact same query loading... 150,000 of those are half-open > TCP > sessions that got lost. > > again, how many can you keep open and what is the criteria for > closing a TCP > session. Whats wrong with "When state exceeds LRU, close", or heck, "If a 'normal' query, close connection when complete". (You can even close with a RST so you don't need to keep the half-open state) Dealing with a 2,500 simple queries over TCP SHOULD NOT be a major issue. Its stuff that the web server community and related solved a decade ago. From owner-namedroppers@ops.ietf.org Mon Aug 24 15:44: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 7E7EF3A6EFD; Mon, 24 Aug 2009 15:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.116, 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 cuVKh2-IGfRI; Mon, 24 Aug 2009 15:44:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 728D03A6E5B; Mon, 24 Aug 2009 15:44:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfiE0-0008VQ-FI for namedroppers-data0@psg.com; Mon, 24 Aug 2009 22:41:16 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfiDu-0008UR-MJ for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 22:41:13 +0000 Received: (qmail 1820 invoked by uid 399); 24 Aug 2009 22:41:06 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Aug 2009 22:41:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A9316FC.5050407@dougbarton.us> Date: Mon, 24 Aug 2009 15:41:00 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> In-Reply-To: <20090824220451.GF17279@vacation.karoshi.com.> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: bmanning@vacation.karoshi.com wrote: > sure you can -accept- thousands of TCP sessions per second. > how many can you keep open? > what is your criteria for dropping one? > how many TCP sessions lose state partway through the handshake? Back in 1996 we had over 5,000 simultaneous clients on an IRC server (which carries a LOT more traffic per client than DNS) attached to DALnet. We had what was at the time "top of the line" hardware, but apply Moore's law 4 times to the hardware and the multiplier of your choice for the software and extrapolate from there. Someone else already said it, TCP has come a long way in 30 years. Doug From owner-namedroppers@ops.ietf.org Mon Aug 24 15:57: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 EE3C428C3AD; Mon, 24 Aug 2009 15:57:02 -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 tQK+XJ1Sq5l1; Mon, 24 Aug 2009 15:57:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FED728C3A9; Mon, 24 Aug 2009 15:57:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfiQ2-000AO7-HA for namedroppers-data0@psg.com; Mon, 24 Aug 2009 22:53:42 +0000 Received: from [209.85.216.173] (helo=mail-px0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfiPz-000ANO-CU for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 22:53:40 +0000 Received: by pxi3 with SMTP id 3so6459341pxi.32 for ; Mon, 24 Aug 2009 15:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.7.25 with SMTP id 25mr7885424wag.21.1251154418005; Mon, 24 Aug 2009 15:53:38 -0700 (PDT) In-Reply-To: <4A9316FC.5050407@dougbarton.us> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <4A9316FC.5050407@dougbarton.us> Date: Mon, 24 Aug 2009 15:53:37 -0700 Message-ID: Subject: Re: [dnsext] root DNSKEY response is 1749 bytes From: Matthew Dempsky To: Doug Barton Cc: bmanning@vacation.karoshi.com, Michael Graff , bert hubert , 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 3:41 PM, Doug Barton wrote: > Back in 1996 we had over 5,000 simultaneous clients on an IRC server > (which carries a LOT more traffic per client than DNS) attached to > DALnet. We had what was at the time "top of the line" hardware, but > apply Moore's law 4 times to the hardware and the multiplier of your > choice for the software and extrapolate from there. > > Someone else already said it, TCP has come a long way in 30 years. Do we have any sense for how many concurrent TCP connections name servers actually need to support in the worst case? E.g., has anyone performed analysis of the DITL 2009 data to see how many unique source IP addresses are seen in rolling two minute windows? From owner-namedroppers@ops.ietf.org Mon Aug 24 15:58: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 D512328C3A9; Mon, 24 Aug 2009 15:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQyEmgIYTQNd; Mon, 24 Aug 2009 15:58:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D84FA28C3A4; Mon, 24 Aug 2009 15:58:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfiRq-000Ah0-Jy for namedroppers-data0@psg.com; Mon, 24 Aug 2009 22:55:34 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfiRm-000AQy-EK for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 22:55:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n7OMqd8X018445; Mon, 24 Aug 2009 22:52:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7OMqdYn018444; Mon, 24 Aug 2009 22:52:39 GMT Date: Mon, 24 Aug 2009 22:52:39 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <20090824225239.GC18180@vacation.karoshi.com.> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 03:30:37PM -0700, Nicholas Weaver wrote: > > On Aug 24, 2009, at 3:04 PM, bmanning@vacation.karoshi.com wrote: > > > > sure you can -accept- thousands of TCP sessions per second. > > how many can you keep open? > > what is your criteria for dropping one? > > how many TCP sessions lose state partway through the handshake? > > > > remember that DNS sez you -MUST- keep a TCP session open for > > 120 seconds. > > Why? That number is a holdover from when DNS over TCP was used > primarily for zone transfers. IF it ends up being a common fallback > mechanism for ~10% of the queries, thats a completely different story > and a much more agressive timeout is far more appropriate. its in the spec Nicholas. thats why. > > again, how many can you keep open and what is the criteria for > >closing a TCP > > session. > > Whats wrong with "When state exceeds LRU, close", or heck, "If a > 'normal' query, close connection when complete". NP with close when complete... the huge number is based on a 5% state loss of TCP transactions - in which case they will never close bythemselves. > (You can even close with a RST so you don't need to keep the half-open > state) sure. you can. whats your criteria for dropping a half-open TCP connection for DNS service? > Dealing with a 2,500 simple queries over TCP SHOULD NOT be a major > issue. Its stuff that the web server community and related solved a > decade ago. its 25,000 qps over UDP. move that to TCP, assume a 5% drop and then your pushing 175,000 qps over TCP for the same goodput. 175,000 open TCP sessions per second is slightly tougher nut to crack - and no, i don't think that extrapolating HTTP over TCP is quite the same as DNS over TCP. --bill From owner-namedroppers@ops.ietf.org Mon Aug 24 16:09: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 B15D23A6ADC; Mon, 24 Aug 2009 16:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcw6gL98ALPT; Mon, 24 Aug 2009 16:09:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B4DB3A6942; Mon, 24 Aug 2009 16:09:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MficH-000CUd-5V for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:06:22 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MficC-000CJi-Nn for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:06: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 n7ON338X018554; Mon, 24 Aug 2009 23:03:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7ON33YS018553; Mon, 24 Aug 2009 23:03:03 GMT Date: Mon, 24 Aug 2009 23:03:03 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: Doug Barton , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <20090824230303.GA18538@vacation.karoshi.com.> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <4A9316FC.5050407@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 03:53:37PM -0700, Matthew Dempsky wrote: > On Mon, Aug 24, 2009 at 3:41 PM, Doug Barton wrote: > > Back in 1996 we had over 5,000 simultaneous clients on an IRC server > > (which carries a LOT more traffic per client than DNS) attached to > > DALnet. We had what was at the time "top of the line" hardware, but > > apply Moore's law 4 times to the hardware and the multiplier of your > > choice for the software and extrapolate from there. > > > > Someone else already said it, TCP has come a long way in 30 years. > > Do we have any sense for how many concurrent TCP connections name > servers actually need to support in the worst case? E.g., has anyone > performed analysis of the DITL 2009 data to see how many unique source > IP addresses are seen in rolling two minute windows? why yes.. On Aug 12, 2009, at 2:51 PM, William Allen Simpson wrote: >With the advent of more widespread DNSsec deployment, more UDP >sessions >are likely to fallover into TCP sessions. > >I've been informed that even today, with a more limited TCP activity, >busy servers cannot wait 2MSL to finish closing. One wonders how a web server survives... >Also, busy caching servers run out of port numbers, and cycle quickly. >So there's ample opportunity for seemingly duplicate transmissions. Presuming a single source and destination IP address and a single well- known server port number, the caching server could run through ~60000/ MSL connections per second before attempting to reuse a four-tuple still in TIME_WAIT. If one were holding strictly to a four minute MSL that is ~250 connections per second. 60 seconds seems to be a rather more common MSL (well, length of TIME_WAIT) so that would be ~1000 connections per second. --bill From owner-namedroppers@ops.ietf.org Mon Aug 24 16:09: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 9C0583A6942; Mon, 24 Aug 2009 16:09:33 -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 4BPBwuIk1CaH; Mon, 24 Aug 2009 16:09:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA19428C3B4; Mon, 24 Aug 2009 16:09:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfid0-000Caj-7t for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:07:06 +0000 Received: from [209.85.146.177] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mficw-000CaG-VF for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:07:04 +0000 Received: by wa-out-1112.google.com with SMTP id j37so457659waf.9 for ; Mon, 24 Aug 2009 16:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.163.24 with SMTP id l24mr6633634wae.9.1251155222820; Mon, 24 Aug 2009 16:07:02 -0700 (PDT) In-Reply-To: <20090824230303.GA18538@vacation.karoshi.com.> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <4A9316FC.5050407@dougbarton.us> <20090824230303.GA18538@vacation.karoshi.com.> Date: Mon, 24 Aug 2009 16:07:02 -0700 Message-ID: Subject: Re: [dnsext] root DNSKEY response is 1749 bytes From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: Doug Barton , Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 4:03 PM, wrote: > On Mon, Aug 24, 2009 at 03:53:37PM -0700, Matthew Dempsky wrote: >> Do we have any sense for how many concurrent TCP connections name >> servers actually need to support in the worst case? =A0E.g., has anyone >> performed analysis of the DITL 2009 data to see how many unique source >> IP addresses are seen in rolling two minute windows? > > why yes.. ... um, and the conclusion is... ? From owner-namedroppers@ops.ietf.org Mon Aug 24 16:23: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 438F93A6B21; Mon, 24 Aug 2009 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYlz93huezAH; Mon, 24 Aug 2009 16:23:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 587C23A67B7; Mon, 24 Aug 2009 16:23:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfinq-000ELw-O0 for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:18:18 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfinm-000E9t-6N for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:18: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 n7ONFK8X018656; Mon, 24 Aug 2009 23:15:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7ONFJWV018655; Mon, 24 Aug 2009 23:15:19 GMT Date: Mon, 24 Aug 2009 23:15:19 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Doug Barton , Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <20090824231519.GC18538@vacation.karoshi.com.> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <4A9316FC.5050407@dougbarton.us> <20090824230303.GA18538@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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 04:07:02PM -0700, Matthew Dempsky wrote: > On Mon, Aug 24, 2009 at 4:03 PM, wrote: > > On Mon, Aug 24, 2009 at 03:53:37PM -0700, Matthew Dempsky wrote: > >> Do we have any sense for how many concurrent TCP connections name > >> servers actually need to support in the worst case? E.g., has anyone > >> performed analysis of the DITL 2009 data to see how many unique source > >> IP addresses are seen in rolling two minute windows? > > > > why yes.. > > ... um, and the conclusion is... ? my sense (there is some debate on this) or sense of an analysis of the DITL data? (no, have not done that, i'm chunking some root server logs for slightly other reasons at the moment - will get to this titbit in a couple weeks) --bill From owner-namedroppers@ops.ietf.org Mon Aug 24 16:45: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 EA7563A69F1; Mon, 24 Aug 2009 16:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9L+YhArvovq; Mon, 24 Aug 2009 16:45:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04BA93A6AEC; Mon, 24 Aug 2009 16:45:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjAJ-000HXs-JV for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:41:31 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjAE-000HVy-Ij for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:41:29 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id D3368327A76; Mon, 24 Aug 2009 23:41:25 +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 EE5F9327A6E; Mon, 24 Aug 2009 23:41:24 +0000 (UTC) Message-ID: <4A932524.1060500@isc.org> Date: Mon, 24 Aug 2009 18:41:24 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <20090824225239.GC18180@vacation.karoshi.com.> In-Reply-To: <20090824225239.GC18180@vacation.karoshi.com.> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bmanning@vacation.karoshi.com wrote: > sure. you can. whats your criteria for dropping a half-open > TCP connection for DNS service? 2 second timeout. It's what is in use on at least one DNS implementation I believe. > its 25,000 qps over UDP. move that to TCP, assume a 5% drop > and then your pushing 175,000 qps over TCP for the same goodput. Right now .org has what percentage of queries fall back to TCP? It's not like we need them all to suddenly go over TCP. We just need large responses to. DNSKEYs with reasonable TTLs should not cause a flood; it's not like a DNSKEY can't be cached. Setting a 0 TTL on a DNSKEY hurt ORG initially -- what is the percentage now that they have a IMHO still too short 900 second TTL? What would setting that TTL to 1 hour, or 12 hours, do to the TCP stats? > 175,000 open TCP sessions per second is slightly tougher nut to > crack - and no, i don't think that extrapolating HTTP over TCP is > quite the same as DNS over TCP. IRC servers have had long running TCP sessions open in the order of 30,000. If you run a zone that gets that many queries on a single machine, you might be in a world of hurt, but for TLDs and roots with ample equipment and ample horsepower, would this really pose a problem? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTJSMACgkQ+NNi0s9NRJ3KOgCglNRCaRVXlc163VXOCEEyktBv PV8An0sva7H5XmaWT0dJu5fNXdPfrcyH =3PeR -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 16:51: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 C7E7F28C3CF; Mon, 24 Aug 2009 16:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 i89VHaDJXxqY; Mon, 24 Aug 2009 16:51:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9CAF28C3A2; Mon, 24 Aug 2009 16:49:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjFQ-000IDA-R3 for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:46:48 +0000 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjFN-000ICY-9W for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:46:47 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id 5116F30F52C; Mon, 24 Aug 2009 16:46:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: [dnsext] BCP 152, RFC 5625 on DNS Proxy Implementation Guidelines From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Message-Id: <20090824234632.5116F30F52C@bosco.isi.edu> Date: Mon, 24 Aug 2009 16:46:32 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: A new Request for Comments is now available in online RFC libraries. BCP 152 RFC 5625 Title: DNS Proxy Implementation Guidelines Author: R. Bellis Status: Best Current Practice Date: August 2009 Mailbox: ray.bellis@nominet.org.uk Pages: 12 Characters: 24585 See Also: BCP0152 I-D Tag: draft-ietf-dnsext-dnsproxy-06.txt URL: http://www.rfc-editor.org/rfc/rfc5625.txt This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the DNS Extensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From owner-namedroppers@ops.ietf.org Mon Aug 24 16:54: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 3B22928C3EB; Mon, 24 Aug 2009 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id estJeAcKAz0Z; Mon, 24 Aug 2009 16:54:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 89C7828C3E5; Mon, 24 Aug 2009 16:54:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjJT-000J7Z-0O for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:50:59 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjJO-000J6b-NM for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:50:57 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 970AB327A76; Mon, 24 Aug 2009 23:50: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 10DEB327A6E; Mon, 24 Aug 2009 23:50:52 +0000 (UTC) Message-ID: <4A93275C.5060204@isc.org> Date: Mon, 24 Aug 2009 18:50:52 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> In-Reply-To: <20090824220451.GF17279@vacation.karoshi.com.> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bmanning@vacation.karoshi.com wrote: > sure you can -accept- thousands of TCP sessions per second. > how many can you keep open? IRC servers can maintain 10,000 to 20,000 TCP sessions open on modest (by modern definition) hardware using modern OS features like /dev/poll, epoll, and kqueue. It does not seem difficult for these server operators to handle the load. This whole issue (TCP server capacity) has been studied and handled in many other forums. Indeed, one of the discussion threads was about what OTHER protocols require (fragmented) UDP. Indeed, few do. Many use TCP in fact and I have yet to hear them screaming about a global meltdown. Perhaps I've gone through several of these myself; I used to run a fairly large (8,000 or to) connection IRC server back in the day. Perhaps that is why I'm not so scared. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTJ1wACgkQ+NNi0s9NRJ3aewCghGAdEHeiSo+uHDRuLUk6eY/c +gwAoIx4m9jOYRx4HjlxRP3Yxf4+bIG+ =yW3y -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 16:58: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 A42B33A6974; Mon, 24 Aug 2009 16:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OKTJqBkSjoX; Mon, 24 Aug 2009 16:58:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9EFDD28C3CB; Mon, 24 Aug 2009 16:58:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjNz-000Jy0-RF for namedroppers-data0@psg.com; Mon, 24 Aug 2009 23:55:39 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjNw-000JxK-70 for namedroppers@ops.ietf.org; Mon, 24 Aug 2009 23:55:38 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 7EB9D327A76; Mon, 24 Aug 2009 23:55:35 +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 C4FD1327A6E; Mon, 24 Aug 2009 23:55:34 +0000 (UTC) Message-ID: <4A932876.2070605@isc.org> Date: Mon, 24 Aug 2009 18:55:34 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Doug Barton CC: Nicholas Weaver , "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Suggested fallbacks... References: <4A930075.7080503@isc.org> <4A930D22.2090009@dougbarton.us> In-Reply-To: <4A930D22.2090009@dougbarton.us> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Barton wrote: > Michael Graff wrote: >> I don't think it's practical to expect to maintain state on every auth >> server I might speak to. > > Why not? BIND at least already keeps a running record of RTT for each > authority you query. This would just be one more data point, and > unlike RTT it would be static (for all practical purposes). It keeps a cache of them yes, but I don't think this cache is infinite, nor can it really be. Imagine if it was; I could kill your server trivially with a IPv6 tunnel. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTKHUACgkQ+NNi0s9NRJ1tcwCghOy0e+wiulj5F6YjmCzp1wOm iqQAoJpytTs0O22l/KLhGvMBL5IDDD8o =aqXk -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 17: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 B0B9128C135; Mon, 24 Aug 2009 17:19:25 -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 gUZjOFZxsE-B; Mon, 24 Aug 2009 17:19:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEF263A69CC; Mon, 24 Aug 2009 17:19:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfjgJ-000NWN-7v for namedroppers-data0@psg.com; Tue, 25 Aug 2009 00:14:35 +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 1MfjgE-000NUM-Hq for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 00:14:32 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2241DB3EEF for ; Tue, 25 Aug 2009 00:14:30 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Mon, 24 Aug 2009 16:08:14 EST." <4A93013E.6030806@isc.org> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 25 Aug 2009 00:14:30 +0000 Message-ID: <62670.1251159270@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 24 Aug 2009 16:08:14 -0500 > From: Michael Graff > > Now they can accept thousands of TCP sessions per second and not flinch. they do flinch. maybe try some dnsperf work in the nsf test lab and find out? From owner-namedroppers@ops.ietf.org Mon Aug 24 17:20: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 11C853A6AB8; Mon, 24 Aug 2009 17:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 wxvMF+fkncsG; Mon, 24 Aug 2009 17:20:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B2EC3A69CE; Mon, 24 Aug 2009 17:20:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfjje-000O7D-S5 for namedroppers-data0@psg.com; Tue, 25 Aug 2009 00:18: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 1Mfjja-000O6H-9S for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 00:18:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F0F03B3EF0 for ; Tue, 25 Aug 2009 00:17:57 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP? In-Reply-To: Your message of "Mon, 24 Aug 2009 16:14:20 EST." <4A9302AC.1060502@isc.org> References: <7DA949B3-460C-4788-87D7-5C13A7638A51@icsi.berkeley.edu> <20090824011031.GA7586@vacation.karoshi.com.> <90E8A0DF-12CA-4DF4-9CCE-7F51C92C53EE@ICSI.Berkeley.EDU> <20587.1251096604@nsa.vix.com> <4A9302AC.1060502@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 25 Aug 2009 00:17:57 +0000 Message-ID: <62800.1251159477@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 24 Aug 2009 16:14:20 -0500 > From: Michael Graff > > I will ask this in another thread. How is this at all any difference > than what we have today, as an attack vector? This is not the future > threat, it is a current one. > > It's not a shiny new target, that is. it's not a target today. to be a target you have to be attractive, which means if somebody blows it up it'll be missed. the moment someone adds a dependency on tcp/53 in any part of the dns design, the weakness of the target will become the fatness of the target. From owner-namedroppers@ops.ietf.org Mon Aug 24 17:52: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 1E67228C359; Mon, 24 Aug 2009 17:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A7QGXL83QDO; Mon, 24 Aug 2009 17:52:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 201823A682A; Mon, 24 Aug 2009 17:52:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkBt-0002VB-Bo for namedroppers-data0@psg.com; Tue, 25 Aug 2009 00:47:13 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkBd-0002TN-Ti for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 00:47:06 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 24C62327A70; Tue, 25 Aug 2009 00:46:57 +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 6D33A327A6D; Tue, 25 Aug 2009 00:46:56 +0000 (UTC) Message-ID: <4A93347F.4000306@isc.org> Date: Mon, 24 Aug 2009 19:46:55 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> In-Reply-To: <62670.1251159270@nsa.vix.com> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: >> Date: Mon, 24 Aug 2009 16:08:14 -0500 >> From: Michael Graff >> >> Now they can accept thousands of TCP sessions per second and not flinch. > > they do flinch. maybe try some dnsperf work in the nsf test lab and find out? Apples to oranges. DNS severs have, I suspect, never worried about TCP path performance until now. Thus, dnsperf against an unoptimized implementaion is pointless. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTNH8ACgkQ+NNi0s9NRJ1XKgCgg6o60k5/efW6PtgPkTDtSYg7 nysAoI1VC0IDfDHTY6g/n3bpFycJT0qO =13O6 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 17:52: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 ABCE73A69D3; Mon, 24 Aug 2009 17:52:16 -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 Bbx0qyKAAhVw; Mon, 24 Aug 2009 17:52:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B808B3A682A; Mon, 24 Aug 2009 17:52:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkDJ-0002gt-Cv for namedroppers-data0@psg.com; Tue, 25 Aug 2009 00:48:41 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkDC-0002fv-Rq for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 00:48:39 +0000 Received: by pzk38 with SMTP id 38so1205214pzk.5 for ; Mon, 24 Aug 2009 17:48:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.6.33 with SMTP id 33mr6903469waf.175.1251161314142; Mon, 24 Aug 2009 17:48:34 -0700 (PDT) In-Reply-To: <20090824220451.GF17279@vacation.karoshi.com.> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> Date: Mon, 24 Aug 2009 17:48:34 -0700 Message-ID: Subject: Re: [dnsext] root DNSKEY response is 1749 bytes From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 3:04 PM, wrote: > =A0 =A0 =A0 =A0remember that DNS sez you -MUST- keep a TCP session open f= or > =A0 =A0 =A0 =A0120 seconds. This seems like a bogus argument. I took a bunch of popular name servers, opened a TCP connection to port 53, and timed how long they took before closing the socket themselves, and repeated the experiment for each one 5 times for good measure. They all closed the connection after about 30 seconds of idle time. M.ROOT-SERVERS.NET. 30.02 30.01 30.02 30.01 30.02 A.ROOT-SERVERS.NET. 30.04 30.03 30.02 30.03 30.02 C.ROOT-SERVERS.NET. 30.05 33.03 30.03 30.03 30.02 D.ROOT-SERVERS.NET. 30.04 33.02 30.03 30.03 30.03 G.ROOT-SERVERS.NET. 33.01 30.04 30.03 30.02 30.03 E.ROOT-SERVERS.NET. 30.04 33.02 30.03 30.95 30.04 F.ROOT-SERVERS.NET. 33.00 32.00 32.02 30.03 33.03 B.ROOT-SERVERS.NET. 32.03 32.01 30.03 30.03 30.99 I.ROOT-SERVERS.NET. 30.04 30.03 30.03 30.02 30.03 H.ROOT-SERVERS.NET. 31.99 30.03 31.01 30.92 30.03 J.ROOT-SERVERS.NET. 30.03 31.99 30.03 30.04 30.04 K.ROOT-SERVERS.NET. 30.03 30.99 31.99 33.02 30.94 L.ROOT-SERVERS.NET. 30.04 30.03 30.03 30.03 30.94 b.gtld-servers.net. 31.95 30.03 30.03 33.04 30.02 a.gtld-servers.net. 30.04 30.03 30.98 30.04 30.02 c.gtld-servers.net. 30.94 30.96 33.03 30.04 32.02 e.gtld-servers.net. 30.94 30.04 33.02 30.03 30.03 d.gtld-servers.net. 30.95 30.95 30.03 31.98 30.03 g.gtld-servers.net. 30.02 33.01 30.95 31.98 30.04 h.gtld-servers.net. 30.02 30.03 30.03 30.97 33.03 f.gtld-servers.net. 30.03 30.04 30.03 30.98 30.03 i.gtld-servers.net. 33.02 30.03 30.04 30.02 32.00 j.gtld-servers.net. 33.02 32.01 30.04 30.03 33.03 k.gtld-servers.net. 30.04 32.01 33.04 30.03 31.98 l.gtld-servers.net. 30.04 33.02 33.01 33.02 30.03 D0.ORG.AFILIAS-NST.org. 30.99 30.03 31.02 33.03 30.03 m.gtld-servers.net. 31.00 30.03 32.01 30.03 30.03 B2.ORG.AFILIAS-NST.org. 30.03 30.99 32.01 32.02 30.96 A0.ORG.AFILIAS-NST.INFO. 30.02 30.03 30.03 30.92 30.95 C0.ORG.AFILIAS-NST.INFO. 33.02 30.98 30.03 30.04 30.03 A2.ORG.AFILIAS-NST.INFO. 30.03 30.98 30.02 32.01 30.95 ns.isc.afilias-nst.info. 30.95 30.02 31.98 31.03 30.03 B0.ORG.AFILIAS-NST.org. 30.03 30.01 30.98 30.04 30.03 sfba.sns-pb.isc.org. 30.03 30.03 30.03 30.04 31.05 ord.sns-pb.isc.org. 30.03 33.02 30.02 30.03 30.03 ams.sns-pb.isc.org. 30.03 30.03 30.02 30.98 30.03 dot.ep.net. 31.02 30.02 30.95 30.02 30.03 ns.isi.edu. 30.05 33.02 30.03 30.03 30.03 ns0.ietf.org. 31.00 31.01 30.03 33.02 30.03 ns1.mia1.afilias-nst.info. 30.05 33.02 30.04 30.03 30.03 ns1.ams1.afilias-nst.info. 32.01 30.03 31.01 30.02 30.97 flag.ep.net. 30.05 30.03 31.02 30.95 30.03 ns1.yyz1.afilias-nst.info. 31.97 30.99 30.03 30.02 30.03 ns1.sea1.afilias-nst.info. 31.98 30.03 31.00 30.03 30.04 ns1.hkg1.afilias-nst.info. 30.97 30.98 30.03 30.03 30.95 (The list of hosts came from "dig +short -t ns . com org isc.org karoshi.com ietf.org".) From owner-namedroppers@ops.ietf.org Mon Aug 24 17:58: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 8AECC3A6D95; Mon, 24 Aug 2009 17:58: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 7oLUiU3crGBv; Mon, 24 Aug 2009 17:58:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A839C3A69D3; Mon, 24 Aug 2009 17:58:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkKK-0003l7-7y for namedroppers-data0@psg.com; Tue, 25 Aug 2009 00:55: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 1MfkKG-0003kY-Lw for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 00:55:54 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 25665B3EFD for ; Tue, 25 Aug 2009 00:55:52 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Mon, 24 Aug 2009 19:46:55 EST." <4A93347F.4000306@isc.org> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> <4A93347F.4000306@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 25 Aug 2009 00:55:52 +0000 Message-ID: <64657.1251161752@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 24 Aug 2009 19:46:55 -0500 > From: Michael Graff > > Apples to oranges. DNS severs have, I suspect, never worried about TCP > path performance until now. Thus, dnsperf against an unoptimized > implementaion is pointless. i reckon that best-case QPS for UDP/53 will always be 2..100X higher than best-case QPS for TCP/53, for a typical offered (possibly simulated) load and a given topology (any determinate mix of LAN and WAN) and a given server, no matter what host OS or DNS application tuning is done. assume an authority server whose answer processing is always synchronous. the footprint of TCP/53 (7 packets, 3 round trips) vs. the footprint of UDP/53 (2 to 5 packets, one round trip) does not leave me a lot of room for speculation. i can probbaly be re-educated if somebody does some science. From owner-namedroppers@ops.ietf.org Mon Aug 24 18: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 865CE28C41C; Mon, 24 Aug 2009 18:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.848 X-Spam-Level: X-Spam-Status: No, score=-105.848 tagged_above=-999 required=5 tests=[AWL=0.751, 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 U3eWS0edxEQF; Mon, 24 Aug 2009 18:14:33 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id F0E9628C3FC; Mon, 24 Aug 2009 18:14:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkXq-0006Ag-S5 for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:09:54 +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 1MfkXn-00069p-1m for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:09:52 +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 n7P19kOf001709; Mon, 24 Aug 2009 18:09:46 -0700 (PDT) Cc: Nicholas Weaver , Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <7CCBC48A-ECBE-417B-8ADF-4300FF822657@ICSI.Berkeley.EDU> From: Nicholas Weaver To: bmanning@vacation.karoshi.com In-Reply-To: <20090824225239.GC18180@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 v936) Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Mon, 24 Aug 2009 18:07:21 -0700 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <20090824225239.GC18180@vacation.karoshi.com.> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 24, 2009, at 3:52 PM, bmanning@vacation.karoshi.com wrote: >> Why? That number is a holdover from when DNS over TCP was used >> primarily for zone transfers. IF it ends up being a common fallback >> mechanism for ~10% of the queries, thats a completely different story >> and a much more agressive timeout is far more appropriate. > > its in the spec Nicholas. thats why. So? The DNS specs are hardly a sacred document, especially if effectively wronged and obsoleted. >> Dealing with a 2,500 simple queries over TCP SHOULD NOT be a major >> issue. Its stuff that the web server community and related solved a >> decade ago. > > its 25,000 qps over UDP. move that to TCP, assume a 5% drop > and then your pushing 175,000 qps over TCP for the same goodput. Uhh, WTF? 25,000 qps over UDP, 10% of the resolvers can't hack UDP, gives you 2,500 TCP queries. And how does a 5% drop-rate, even assuming 25k QPS, push you to 175K? 5% drop does not mean you need to do 5X the # of queries... > 175,000 open TCP sessions per second is slightly tougher nut to > crack - and no, i don't think that extrapolating HTTP over TCP is > quite the same as DNS over TCP. Yeah. HTTP has keepalives that matter, and far more resources on the server side needed for processing. And people already doing low traffic rate interactive DOSes (which don't work on ISS, BTW), syn floods, and everything else. And it seems to work just fine. HTTP is a much much HARDER target for high-throughput over TCP than DNS. From owner-namedroppers@ops.ietf.org Mon Aug 24 18: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 09A7328C3FC; Mon, 24 Aug 2009 18:14:35 -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 J22LRl5dbX5c; Mon, 24 Aug 2009 18:14:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C055828C40A; Mon, 24 Aug 2009 18:14:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkXy-0006C0-Nk for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:10: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 1MfkXn-00069v-5q for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:09:52 +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 n7P19kOg001709; Mon, 24 Aug 2009 18:09:47 -0700 (PDT) Cc: Nicholas Weaver , Doug Barton , "namedroppers@ops.ietf.org WG" Message-Id: <99A1FB88-9BA7-4EB6-A4E5-D1E0B3B09E3C@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A932876.2070605@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Suggested fallbacks... Date: Mon, 24 Aug 2009 18:09:46 -0700 References: <4A930075.7080503@isc.org> <4A930D22.2090009@dougbarton.us> <4A932876.2070605@isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: WHich means you have all the information you need basically. TRW- based learning can handle a lot of fuzzyness. On Aug 24, 2009, at 4:55 PM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Doug Barton wrote: >> Michael Graff wrote: >>> I don't think it's practical to expect to maintain state on every >>> auth >>> server I might speak to. >> >> Why not? BIND at least already keeps a running record of RTT for each >> authority you query. This would just be one more data point, and >> unlike RTT it would be static (for all practical purposes). > > It keeps a cache of them yes, but I don't think this cache is > infinite, > nor can it really be. Imagine if it was; I could kill your server > trivially with a IPv6 tunnel. > > - --Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkqTKHUACgkQ+NNi0s9NRJ1tcwCghOy0e+wiulj5F6YjmCzp1wOm > iqQAoJpytTs0O22l/KLhGvMBL5IDDD8o > =aqXk > -----END PGP SIGNATURE----- > From owner-namedroppers@ops.ietf.org Mon Aug 24 18: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 8FBBA3A6B94; Mon, 24 Aug 2009 18:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.427 X-Spam-Level: * X-Spam-Status: No, score=1.427 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E--jZw6gOQv7; Mon, 24 Aug 2009 18:30:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 474E83A6963; Mon, 24 Aug 2009 18:30:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfkof-0008Rf-T6 for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:27:17 +0000 Received: from [209.85.216.173] (helo=mail-px0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfkoa-0008R4-Fp for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:27:15 +0000 Received: by pxi3 with SMTP id 3so6523770pxi.32 for ; Mon, 24 Aug 2009 18:27:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.251.13 with SMTP id y13mr6946165wah.208.1251163631440; Mon, 24 Aug 2009 18:27:11 -0700 (PDT) In-Reply-To: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> Date: Mon, 24 Aug 2009 18:27:11 -0700 Message-ID: Subject: Re: [dnsext] root DNSKEY response is 1749 bytes From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 24, 2009 at 5:48 PM, Matthew Dempsky wrote= : > This seems like a bogus argument. =A0I took a bunch of popular name > servers, opened a TCP connection to port 53, and timed how long they > took before closing the socket themselves, and repeated the experiment > for each one 5 times for good measure. =A0They all closed the connection > after about 30 seconds of idle time. Embarrassingly, I realized I left f.root-servers.net hard-coded in my scripts, so all of the tests ran against the same server... oops. Below are the timings against the correct name servers. A.ROOT-SERVERS.NET. 5.18 5.16 5.16 5.16 5.16 F.GTLD-SERVERS.NET. 5.44 4.38 5.52 5.22 5.66 A.GTLD-SERVERS.NET. 5.40 6.01 5.17 4.27 6.04 G.GTLD-SERVERS.NET. 5.92 5.56 5.82 5.06 5.57 I.GTLD-SERVERS.NET. 5.75 5.84 5.10 6.04 5.41 K.GTLD-SERVERS.NET. 4.93 5.97 5.39 5.49 6.37 M.GTLD-SERVERS.NET. 5.68 5.58 5.62 5.81 5.49 C.GTLD-SERVERS.NET. 5.96 5.40 6.14 5.45 5.45 J.GTLD-SERVERS.NET. 5.66 6.06 5.39 5.94 5.75 D.GTLD-SERVERS.NET. 5.68 5.97 5.43 5.86 5.92 H.GTLD-SERVERS.NET. 6.35 5.42 5.79 5.83 5.90 E.GTLD-SERVERS.NET. 6.21 5.81 5.45 6.16 6.35 B.GTLD-SERVERS.NET. 6.06 6.00 6.00 6.01 5.99 A0.ORG.AFILIAS-NST.INFO. 17.79 15.20 17.69 9.78 15.79 B0.ORG.AFILIAS-NST.org. 20.18 17.29 14.71 8.43 17.15 D0.ORG.AFILIAS-NST.org. 17.93 15.30 15.69 14.96 15.99 ns.isc.afilias-nst.info. 15.37 15.29 16.70 19.20 15.79 ns1.ams1.afilias-nst.info. 17.24 16.79 15.19 18.30 17.67 C0.ORG.AFILIAS-NST.INFO. 17.93 19.19 18.98 15.29 16.88 ns1.mia1.afilias-nst.info. 16.94 20.09 18.69 16.68 15.80 ns1.yyz1.afilias-nst.info. 18.63 19.17 17.39 14.59 19.19 ns1.sea1.afilias-nst.info. 18.73 19.20 15.76 16.18 19.19 F.ROOT-SERVERS.NET. 30.03 30.03 30.01 30.03 30.02 E.ROOT-SERVERS.NET. 30.03 30.02 30.02 30.03 30.01 sfba.sns-pb.isc.org. 30.01 30.03 30.01 30.01 30.01 C.ROOT-SERVERS.NET. 30.05 30.05 30.04 30.04 30.04 ns0.ietf.org. 30.02 30.01 30.02 30.01 30.01 dot.ep.net. 30.05 30.06 30.05 30.06 30.05 flag.ep.net. 30.05 30.05 30.05 30.05 30.05 G.ROOT-SERVERS.NET. 30.12 30.11 30.12 30.14 30.12 B.ROOT-SERVERS.NET. 30.69 30.04 30.03 30.03 30.03 D.ROOT-SERVERS.NET. 30.22 30.19 30.19 30.17 30.18 ord.sns-pb.isc.org. 30.17 30.17 30.17 30.17 30.17 I.ROOT-SERVERS.NET. 30.29 30.29 30.29 30.29 30.30 M.ROOT-SERVERS.NET. 30.33 30.34 30.34 30.34 30.33 J.ROOT-SERVERS.NET. 30.33 30.32 30.32 30.33 30.33 ams.sns-pb.isc.org. 30.43 30.44 30.44 30.44 30.46 ns.isi.edu. 30.04 30.94 31.01 30.99 30.04 L.GTLD-SERVERS.NET. 5.44 5.52 60.02 60.03 60.02 ns1.hkg1.afilias-nst.info. 60.02 60.02 60.02 60.03 60.03 A2.ORG.AFILIAS-NST.INFO. 74.03 59.74 65.32 90.95 64.74 B2.ORG.AFILIAS-NST.org. 74.06 60.16 65.87 90.67 64.76 L.ROOT-SERVERS.NET. 120.16 120.16 120.15 120.15 120.16 K.ROOT-SERVERS.NET. 122.20 120.21 120.21 120.20 120.20 H.ROOT-SERVERS.NET. 125.07 120.16 120.15 120.17 120.16 From owner-namedroppers@ops.ietf.org Mon Aug 24 18:38:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35E03A6E8E; Mon, 24 Aug 2009 18:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.571 X-Spam-Level: X-Spam-Status: No, score=-104.571 tagged_above=-999 required=5 tests=[AWL=2.028, 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 T0XUKDUgwnCl; Mon, 24 Aug 2009 18:38:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5E7CA3A6DFB; Mon, 24 Aug 2009 18:38:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfkwf-000AJb-3H for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:35: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 1Mfkwa-000AIf-RS for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:35: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 07F1BE6056; Tue, 25 Aug 2009 01:35: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 n7P1ZPJ0083976; Tue, 25 Aug 2009 11:35:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908250135.n7P1ZPJ0083976@drugs.dv.isc.org> To: Michael Graff Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org From: Mark Andrews References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <20090824225239.GC18180@vacation.karoshi.com.> <4A932524.1060500@isc.org> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-reply-to: Your message of "Mon, 24 Aug 2009 18:41:24 EST." <4A932524.1060500@isc.org> Date: Tue, 25 Aug 2009 11:35:25 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A932524.1060500@isc.org>, Michael Graff writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > bmanning@vacation.karoshi.com wrote: > > > sure. you can. whats your criteria for dropping a half-open > > TCP connection for DNS service? > > 2 second timeout. It's what is in use on at least one DNS > implementation I believe. > > > its 25,000 qps over UDP. move that to TCP, assume a 5% drop > > and then your pushing 175,000 qps over TCP for the same goodput. > > Right now .org has what percentage of queries fall back to TCP? It's > not like we need them all to suddenly go over TCP. We just need large > responses to. DNSKEYs with reasonable TTLs should not cause a flood; > it's not like a DNSKEY can't be cached. Setting a 0 TTL on a DNSKEY > hurt ORG initially -- what is the percentage now that they have a IMHO > still too short 900 second TTL? What would setting that TTL to 1 hour, > or 12 hours, do to the TCP stats? And the fact that at least some of the servers just set TC on DNSKEY queries. If you don't let fragmented answers go out then the broken middleware will not be made visible and it won't be fixed. All you do is penalise the sites that have done the correct thing by forcing them to use TCP when they don't need to. drugs:9.7.x 11:24 {566} % dig dnskey org @a0.org.afilias-nst.info. +ignore +dnssec ; <<>> DiG 9.3.6-P1 <<>> dnskey org @a0.org.afilias-nst.info. +ignore +dnssec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31422 ;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;org. IN DNSKEY ;; Query time: 261 msec ;; SERVER: 2001:500:e::1#53(2001:500:e::1) ;; WHEN: Tue Aug 25 11:24:21 2009 ;; MSG SIZE rcvd: 32 drugs:9.7.x 11:24 {567} % > > 175,000 open TCP sessions per second is slightly tougher nut to > > crack - and no, i don't think that extrapolating HTTP over TCP is > > quite the same as DNS over TCP. > > IRC servers have had long running TCP sessions open in the order of > 30,000. If you run a zone that gets that many queries on a single > machine, you might be in a world of hurt, but for TLDs and roots with > ample equipment and ample horsepower, would this really pose a problem? > > - --Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkqTJSMACgkQ+NNi0s9NRJ3KOgCglNRCaRVXlc163VXOCEEyktBv > PV8An0sva7H5XmaWT0dJu5fNXdPfrcyH > =3PeR > -----END PGP SIGNATURE----- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 24 18:42: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 891603A6E18; Mon, 24 Aug 2009 18:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 fy5t+WcYLeFX; Mon, 24 Aug 2009 18:42:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C20A3A6DFB; Mon, 24 Aug 2009 18:42:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfl0l-000B1w-J2 for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:39:47 +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 1Mfl0g-000AxC-7P for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:39:44 +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=ZS17HsVYb4GpPrQgl947phXDnSqeWegtdHhP4ZU0rRBLJXy/jv4ssCAcp9ymIBNdYAxIQnMU57zOQsUIFRUxTOXJbWwKK+omZZXibMxu14h73+YfxErFgDjKhCM3mfeW; Received: from [199.212.90.27] (helo=dh27.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfkzP-000CBU-6V; Tue, 25 Aug 2009 01:38:23 +0000 Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: Michael Graff In-Reply-To: <4A932524.1060500@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Mon, 24 Aug 2009 21:38:22 -0400 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <20090824225239.GC18180@vacation.karoshi.com.> <4A932524.1060500@isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 24-Aug-2009, at 19:41, Michael Graff wrote: > Right now .org has what percentage of queries fall back to TCP? It's > not like we need them all to suddenly go over TCP. We just need large > responses to. DNSKEYs with reasonable TTLs should not cause a flood; > it's not like a DNSKEY can't be cached. Setting a 0 TTL on a DNSKEY > hurt ORG initially ... and just on that, hurt how? My observation was that even though the increased amount of TCP state was not necessarily expected (or else perhaps the TTL 0 bug might have been fixed before signing) in fact the infrastructure held up just fine, and there was no pain. I am somewhat sympathetic to the argument that if ORG could be signed, running open source software which implements the DNS standards with no special magic, with an unexpected TTL 0 problem, with no other elaborate precautions and with a zone several orders of magnitude larger than what most people need to handle, then almost all other zone administrators have nothing to worry about. [I'll note in passing that I have conceded in the past that the root zone is at least potentially different, since its servers have the unusual property of having to respond to priming queries from every DNS client on the Internet, old and new. But the concern in this thread seems to be more about TCP in general, for the DNS in general, than for the root in particular.] Joe From owner-namedroppers@ops.ietf.org Mon Aug 24 18:58: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 94B0D28C284; Mon, 24 Aug 2009 18:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 ZqoTBEvOzb6p; Mon, 24 Aug 2009 18:58:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84C933A6858; Mon, 24 Aug 2009 18:58:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MflEw-000E1g-Gl for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:54:26 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MflEs-000E0u-N1 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:54:24 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id B5050327A73; Tue, 25 Aug 2009 01:54:21 +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 988E2327A71; Tue, 25 Aug 2009 01:54:20 +0000 (UTC) Message-ID: <4A93444B.7070401@isc.org> Date: Mon, 24 Aug 2009 20:54:19 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe Abley CC: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <20090824225239.GC18180@vacation.karoshi.com.> <4A932524.1060500@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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Abley wrote: > > On 24-Aug-2009, at 19:41, Michael Graff wrote: > >> Right now .org has what percentage of queries fall back to TCP? It's >> not like we need them all to suddenly go over TCP. We just need large >> responses to. DNSKEYs with reasonable TTLs should not cause a flood; >> it's not like a DNSKEY can't be cached. Setting a 0 TTL on a DNSKEY >> hurt ORG initially > > ... and just on that, hurt how? My observation was that even though the > increased amount of TCP state was not necessarily expected (or else > perhaps the TTL 0 bug might have been fixed before signing) in fact the > infrastructure held up just fine, and there was no pain. "hurt" was a bad choice here. I meant 'caused the big scare we are all talking about." That is, the huge increase graph I saw presented. I'm wondering if the 600x increase or whatever was artificially increased due to the 0 TTL thing. Your argument is stronger though -- if .org did not face-plant, and that with the worst choice of a TTL value which disabled caching and negative caching -- what are we all worried about again? I hold to my guns that TCP is not a problem here. Perhaps TCP code in the current DNS implementations just needs to be fixed up to be closer to http performance is all. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTREsACgkQ+NNi0s9NRJ2MgACgty2QyAY/D4Otdz+w9z1wKv10 QcIAoJ14hrD27zN+xHP7YcInN+FE8J2R =++xo -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 19:02: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 3A9023A6BAA; Mon, 24 Aug 2009 19:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEwdb4RHu2zp; Mon, 24 Aug 2009 19:02:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 532D13A6858; Mon, 24 Aug 2009 19:02:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MflJZ-000Ehm-4s for namedroppers-data0@psg.com; Tue, 25 Aug 2009 01:59:13 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MflJV-000EhD-4x for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 01:59:10 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 84AC6327A73; Tue, 25 Aug 2009 01:59:08 +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 8CBE1327A71; Tue, 25 Aug 2009 01:59:06 +0000 (UTC) Message-ID: <4A934569.2090205@isc.org> Date: Mon, 24 Aug 2009 20:59:05 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> <4A93347F.4000306@isc.org> <64657.1251161752@nsa.vix.com> In-Reply-To: <64657.1251161752@nsa.vix.com> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: > the footprint of TCP/53 (7 packets, 3 round trips) vs. the footprint of > UDP/53 (2 to 5 packets, one round trip) does not leave me a lot of room > for speculation. i can probbaly be re-educated if somebody does some > science. The packet round trip affects a single transaction. It does not affect answers per second unless the wire or switches are saturated with packet limits. That is, sure, a badly written client that sends one request over tcp, waits for the response, then sends another over a different stream would be hurting in your analysis. But that isn't what we have here. We have thousands of clients doing the handshake, each one takes a penalty for the RTT but the server should still be able to maintain a reasonable QPS measurement. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqTRWkACgkQ+NNi0s9NRJ05PwCfbcw6HsA3OGX3DXxNPXHPw/Wr Sn0AnA/uoxJeigEI7fqtE5wG3PtRJiZu =4UWx -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 24 19:27: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 D0B6F3A6E15; Mon, 24 Aug 2009 19:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=-0.195, 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 I8O6xHTV67lg; Mon, 24 Aug 2009 19:27:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCB983A6991; Mon, 24 Aug 2009 19:27:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MflhB-000IEu-4t for namedroppers-data0@psg.com; Tue, 25 Aug 2009 02:23:37 +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 1Mflh6-000IEW-UE for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 02:23:34 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 6DF23A9443E; Tue, 25 Aug 2009 02:23:32 +0000 (UTC) Message-ID: <4A934B24.9000402@mail-abuse.org> Date: Mon, 24 Aug 2009 19:23:32 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> <4A93347F.4000306@isc.org> <64657.1251161752@nsa.vix.com> In-Reply-To: <64657.1251161752@nsa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/24/09 5:55 PM, Paul Vixie wrote: >> Date: Mon, 24 Aug 2009 19:46:55 -0500 >> From: Michael Graff >> >> Apples to oranges. DNS severs have, I suspect, never worried about TCP >> path performance until now. Thus, dnsperf against an unoptimized >> implementaion is pointless. > > i reckon that best-case QPS for UDP/53 will always be 2..100X higher than > best-case QPS for TCP/53, for a typical offered (possibly simulated) load > and a given topology (any determinate mix of LAN and WAN) and a given > server, no matter what host OS or DNS application tuning is done. assume > an authority server whose answer processing is always synchronous. > > the footprint of TCP/53 (7 packets, 3 round trips) vs. the footprint of > UDP/53 (2 to 5 packets, one round trip) does not leave me a lot of room > for speculation. i can probbaly be re-educated if somebody does some > science. Once DNS UDP packets commonly exceed typical PMTUs, TCP will then become relied upon. Although .se TLD is signed, few domains below .se are signed. The same appears true for .org. It would be interesting to analyze perhaps an hours worth of DNS logs of an ISP's resolver. Two aspects need review. One would be the nature of traffic to between customers and the recursive resolver. The other would be the nature of traffic between recursive resolver and authoritative servers. It seems unlikely the path to the authoritative servers represent a significant factor in overhead or latency since most of the records will be published with long TTLs. The results obtained could then indicate an ideal Auto-Close duration for SCTP. From this, one could then estimate the expected overhead increase when using SCTP instead of UDP. Rather than relying upon TCP, SCTP offers important advantages. TCP requires ordered delivery, where DNS messages might not be packet aligned. In addition, any packet loss will hang subsequent processing. On the other hand, SCTP can establish DNS message alignment within the packet, and support out-of-order delivery to avoid buffering out-of-order information and the delay created by maliciously intentional or congestion related packet loss. The SCTP tag validation, in conjunction with DNS transaction-IDs, provide adequate protection from blind spoofing, regardless of the data-rate or the receive window size. That is not as true for TCP. TCP that encodes the byte sequence, also means it can not use options that are able to scale the 64KB receive window. SCTP does not suffer from these limitations. Rather than the DNS application being expected to handling large amounts of message reassembly and buffering, as well as timing the duration of connections, SCTP provides this functionality within the kernel. Unlike TCP, there is also no half-closed SCTP state. -Doug From owner-namedroppers@ops.ietf.org Mon Aug 24 21:59: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 5C57F3A6ED7; Mon, 24 Aug 2009 21:59:53 -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 Gg-LfT1tjIrQ; Mon, 24 Aug 2009 21:59:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 681C43A6859; Mon, 24 Aug 2009 21:59:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfo2N-000DlG-9u for namedroppers-data0@psg.com; Tue, 25 Aug 2009 04:53:39 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfo2I-000Dk7-C9 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 04:53:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AF368B3F30 for ; Tue, 25 Aug 2009 04:53:33 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Mon, 24 Aug 2009 20:59:05 EST." <4A934569.2090205@isc.org> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> <4A93347F.4000306@isc.org> <64657.1251161752@nsa.vix.com> <4A934569.2090205@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 25 Aug 2009 04:53:33 +0000 Message-ID: <74361.1251176013@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 24 Aug 2009 20:59:05 -0500 > From: Michael Graff > > > the footprint of TCP/53 (7 packets, 3 round trips) vs. the footprint of > > UDP/53 (2 to 5 packets, one round trip) does not leave me a lot of room > > for speculation. i can probbaly be re-educated if somebody does some > > science. > > The packet round trip affects a single transaction. It does not affect > answers per second unless the wire or switches are saturated with packet > limits. sounds like you're not going to have any problem proving this and thus advancing the debate beyond tcp-fear vs. tcp-nofear. (and note that the comparisons with http aren't useful unless you're comparing to http/0.9 since we're not going to see very many back to back queries in any flow.) > That is, sure, a badly written client that sends one request over tcp, > waits for the response, then sends another over a different stream would > be hurting in your analysis. But that isn't what we have here. We have > thousands of clients doing the handshake, each one takes a penalty for > the RTT but the server should still be able to maintain a reasonable QPS > measurement. i know the theory of windowing. i explicit think it does not apply here. in any case a proper simulation would (as i said earlier) be of a mix of lan and wan clients, not of a single client doing a deep queue. let me be clear. until someone does the test and shows that this can be done with the same general class of equipment that does high volume udp/53 today and gets the same order of magnitude of performance with tcp/53, the onus of proof will remain on those who assert that it can be done. From owner-namedroppers@ops.ietf.org Tue Aug 25 00:30: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 CA9A83A6B9E; Tue, 25 Aug 2009 00:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=0.038, 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 a2SYO9eVCnUy; Tue, 25 Aug 2009 00:30:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D99683A688B; Tue, 25 Aug 2009 00:30:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfqOL-000CYR-MY for namedroppers-data0@psg.com; Tue, 25 Aug 2009 07:24:29 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfqOI-000CXV-B4 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 07:24:27 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 8C1C61542837; Tue, 25 Aug 2009 08:24:23 +0100 (BST) Cc: Paul Vixie , namedroppers@ops.ietf.org Message-Id: From: Jim Reid To: Michael Graff In-Reply-To: <4A93347F.4000306@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] measuring TCP query performance Date: Tue, 25 Aug 2009 08:24:23 +0100 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> <4A93347F.4000306@isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 25 Aug 2009, at 01:46, Michael Graff wrote: > Apples to oranges. DNS severs have, I suspect, never worried about > TCP > path performance until now. Thus, dnsperf against an unoptimized > implementaion is pointless. Not really Michael. Even if the platforms in the lab environment are not optimised, a benchmark would provide real data: something that's missing from the discussion until now. Besides, the servers and TCP stacks in that lab should be representative of the sort of kit that's in use today. Even if the results show that the TCP throughput isn't good enough, at least there would be some data points for those who might work on optimising the name server and/or TCP software. From owner-namedroppers@ops.ietf.org Tue Aug 25 02:54:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3EB3A6998; Tue, 25 Aug 2009 02:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz0JEavxsiqe; Tue, 25 Aug 2009 02:54:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D76C43A6906; Tue, 25 Aug 2009 02:54:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfsdl-000ALH-SC for namedroppers-data0@psg.com; Tue, 25 Aug 2009 09:48:33 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfsdd-000AJy-Tn for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 09:48:27 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 435671C01D5 for ; Tue, 25 Aug 2009 11:48:25 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 3DFC81C01D4 for ; Tue, 25 Aug 2009 11:48:25 +0200 (CEST) Received: from sandoche-world (tirodite.nic.fr [192.134.4.66]) by relay2.nic.fr (Postfix) with ESMTP id 05E1B7B0036 for ; Tue, 25 Aug 2009 11:48:25 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by sandoche-world (Postfix) with ESMTP id 0A472742226 for ; Tue, 25 Aug 2009 11:48:06 +0200 (CEST) Message-ID: <4A93B355.1070108@afnic.fr> Date: Tue, 25 Aug 2009 11:48:05 +0200 From: sandoche BALAKRICHENAN User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] NAPTR vs (S-NAPTR & U-NAPTR) X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050701060008050006000401" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. --------------050701060008050006000401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all I am aware of the fact that "namedroppers" is not the concerned list for my question. If anyone is aware of any other list where i can get a response, i will be happy to have that information My question is : How "S-NAPTR" & "U-NAPTR" avoids application specific DDDS overhead? --------------050701060008050006000401 Content-Type: text/x-vcard; charset=utf-8; name="sandoche_balakrichenan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sandoche_balakrichenan.vcf" begin:vcard fn:Sandoche BALAKRICHENAN n:;Sandoche BALAKRICHENAN org:AFNIC email;internet:sandoche.balakrichenan@afnic.fr title:Ingenieur R&D note;quoted-printable:Move Together=0D=0A= x-mozilla-html:FALSE version:2.1 end:vcard --------------050701060008050006000401-- From owner-namedroppers@ops.ietf.org Tue Aug 25 05:20:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E6B3A6E0B; Tue, 25 Aug 2009 05:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.16 X-Spam-Level: **** X-Spam-Status: No, score=4.16 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8lmwtrPKORE; Tue, 25 Aug 2009 05:20:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFBE53A6C28; Tue, 25 Aug 2009 05:20:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfut5-0006tw-UX for namedroppers-data0@psg.com; Tue, 25 Aug 2009 12:12:31 +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 1Mfut0-0006sI-Bh for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 12:12:29 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Mfusz-0006dz-ET for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 13:12:25 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mfusv-0002FH-GR for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 13:12:21 +0100 Message-ID: From: "George Barwood" To: References: <406156C126454795B38BBC396D4DED73@localhost> <74329874920E437B883BB0B23B38BD93@localhost> <200908220111.n7M1BFE1029877@drugs.dv.isc.org> <5281A663D492453DB6C35DC47AC2BB9E@localhost> Subject: Re: [dnsext] EDNS Page Option draft updated Date: Tue, 25 Aug 2009 13:12:16 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: And text added re downgrade attack in security section, and tidy up. I finally figured the best URL to use seems to be http://tools.ietf.org/html/draft-barwood-dnsext-edns-page-option This appears to redirect to the latest version, and also has links to to allow differences and old versions to be viewed. Note: don't know what the "docs" link top left is meant to do, but it seems to be bust, if anyone knows who to report this to. George From owner-namedroppers@ops.ietf.org Tue Aug 25 07:28: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 72D4428C44E; Tue, 25 Aug 2009 07:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.186 X-Spam-Level: **** X-Spam-Status: No, score=4.186 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjozHhc7GCX7; Tue, 25 Aug 2009 07:28:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6EA528C449; Tue, 25 Aug 2009 07:28:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfwtu-000P5p-VC for namedroppers-data0@psg.com; Tue, 25 Aug 2009 14:21:30 +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 1Mfwtp-000P3O-KT for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 14:21:29 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Mfwto-00075V-Fe for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 15:21:24 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mfwto-00059A-0D for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 15:21:24 +0100 Message-ID: <4CB0582F89044745BF1D1EBF09E549B6@localhost> From: "George Barwood" To: Subject: [dnsext] Working around proxies Date: Tue, 25 Aug 2009 15:21:19 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Has anyone considered a standard way to work around proxies that prevent responses > 512 bytes being received? I very tentatively suggest a new tld, say localservers could be defined. A query from a stub resolver to the proxy of localservers A would return the IP address of a fully functional local cache. The idea being that it's not necessary to update the middlebox for this to work. If this server failed, the query could be repeated to obtain an alternative. Any good? George From owner-namedroppers@ops.ietf.org Tue Aug 25 09:46: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 3B6A928C1D0; Tue, 25 Aug 2009 09:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 AtbAjtIb0XQU; Tue, 25 Aug 2009 09:46:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D4103A6F25; Tue, 25 Aug 2009 09:46:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfz4g-000KS5-VF for namedroppers-data0@psg.com; Tue, 25 Aug 2009 16:40:46 +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 1Mfz4c-000KRE-MC for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 16:40:45 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 445AFA9443C; Tue, 25 Aug 2009 16:40:42 +0000 (UTC) Message-ID: <4A941409.4000005@mail-abuse.org> Date: Tue, 25 Aug 2009 09:40:41 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option draft updated References: <406156C126454795B38BBC396D4DED73@localhost> <74329874920E437B883BB0B23B38BD93@localhost> <200908220111.n7M1BFE1029877@drugs.dv.isc.org> <5281A663D492453DB6C35DC47AC2BB9E@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/25/09 5:12 AM, George Barwood wrote: > And text added re downgrade attack in security section, and tidy up. > > http://tools.ietf.org/html/draft-barwood-dnsext-edns-page-option This extension leaves congestion avoidance and network amplification considerations to the server. As such, there should be strong recommendations to constrain these risks. After all, this extension will otherwise increase network amplification above that of UDP jumbo frames. This does not make the Internet safer. The security consideration section does not consider the impact of there being no congestion avoidance with "Send All Pages" where there can be large responses (as big as 64KB) and, by using the recommended page size of 512B, 128 packets might be sent back to back. The draft also indicates the server might refuse or partially refuse a request, but does not provide clear indications for the cause of the refusal. Perhaps a 'P' flag for partial response (when something is omitted), and an 'R' flag for response refused. When the response is refused, the cookie parameter and below could then contain extended error information. -Doug From owner-namedroppers@ops.ietf.org Tue Aug 25 10:50: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 8999E3A6BF2; Tue, 25 Aug 2009 10:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-0.696, 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 DzXr4bNxkvrI; Tue, 25 Aug 2009 10:50:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E0733A6F3A; Tue, 25 Aug 2009 10:50:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg04p-0004mT-55 for namedroppers-data0@psg.com; Tue, 25 Aug 2009 17:44:59 +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 1Mg04k-0004lh-E0 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 17:44: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 n7PHiqmI073529 for ; Tue, 25 Aug 2009 13:44:52 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200908251744.n7PHiqmI073529@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Aug 2009 13:44:28 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson/DNSEXT chair Subject: [dnsext] EDNS0 fallback "revisited" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, After reading all the messages on EDNS0 buffer sizes and fallback your chairs have huddled and tried to agree on an approach to go forward and what/if protocol work is needed. For the sake of argument we want to limit the discussion to "ENDS0 capable entities" and their behavior. The goal is to minimize fallback. By decreasing fallback cases we speed up DNS resolution for everyone. We think that the current evidence suggests three main problems: - inability or refusal to handle UDP packets larger than 600 bytes. - inability or refusal to handle UDP fragments. - failure to set the advertised EDNS0 buffer sizes correctly given the actual network conditions Model: A is the issuer of a DNS query B is the target server of the query A <---pipe1---> INTERNET <----pipe2----> B If A advertises a ENDS0 buffer size that is larger than will go through "pipe1" then B may send back an answer that is larger than fits through the pipe. Then A will time-out and do a fallback. If B attempts to put an answer into "pipe2" that is larger than fits into it A will not get an answer and will do a fallback. If both A and B know the "width" of their LOCAL pipes fallback between them is rare and if B has an answer that does not fit, it will set the TC bit. If the problem is actually in the INTERNET part of the diagram, fallback is needed no matter what. We can put of evaluation of how much of the problem is in fact in the middle, because we know for sure right now that there are problems at the end points. Since those are under the control of the affected parties, we can tackle this problem first. The assumption here is A and B can detect the "width" of their local pipes and either fix them or set UDP-buffersize parameters to values that their local pipe will pass. If either A or B have multiple paths to the Internet they should set their buffer sizes to the smallest pipe width. In particular B should NEVER provide an answer to a normal (i.e. non ANY and non RRSIG) query that does not pass through "Pipe2". Work to be done: - Provide tools that measure local pipes and provide configuration hints - Educate users to use the tools, where to look for problems and how to update configurations. - Make the firewall community aware that firewall's are causing DNS problems and educate them in how to update their configurations, to allow well formed UDP fragments to pass. (i.e. non overlapping fragments) - ditto for DNS proxy vendors. - Improve EDNS0 fallback strategies. Only the last one is a protocol work that DNSEXT can undertake, all the others are external educations activities that are outside the scope of the working group. As DNS is not the only UDP based protocol that is affected by the restrictions on UDP packets, modifying DNS to work around misbehaving middle boxes is counter productive to making the Internet better in the long run. Adding complexity to DNS to handle the misbehaving units is a wasted effort as the educational tasks will still have to be undertaken and provide a quicker return on investment. Olafur & Andrew From driftst4@iseharaminori.com Tue Aug 25 10:55: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 613743A6FB7; Tue, 25 Aug 2009 10:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.44 X-Spam-Level: X-Spam-Status: No, score=-16.44 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, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, 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, 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, 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 XPew3oqWeBcx; Tue, 25 Aug 2009 10:55:41 -0700 (PDT) Received: from 189-93-16-246.3g.claro.net.br (189-92-223-156.3g.claro.net.br [189.92.223.156]) by core3.amsl.com (Postfix) with ESMTP id AFB893A6826; Tue, 25 Aug 2009 10:55:23 -0700 (PDT) Received: from 189.92.223.156 by iseharaminori.com with smtp 92DQGPIV8107; Tue, 25 Aug 2009 22:22:32 +0430 Message-ID: <000d01ca25ac$d1f5a5e0$6400a8c0@driftst4> From: Kiana Werner To: Subject: My new ambition is to make this happen, I am testing it free Date: Tue, 25 Aug 2009 22:22:32 +0430 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA25AC.D1F5A5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA25AC.D1F5A5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Victims of obesity and unhealthy lifestyles are ready for a free trail solu= tion.   Acai Berry is your ticket to a slim sexy new you. =A0 Have a=20 look ------=_NextPart_000_0007_01CA25AC.D1F5A5E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Victims of obesity and unhealthy lifestyles are read= y for a free trail solution.
 
Acai Berry is your ticket to a slim sexy new= you.
=A0
Have a=20 look
------=_NextPart_000_0007_01CA25AC.D1F5A5E0-- From owner-namedroppers@ops.ietf.org Tue Aug 25 11:36: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 32D253A6B75; Tue, 25 Aug 2009 11:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=0.064, 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 HPJqmzM4Cutc; Tue, 25 Aug 2009 11:36:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 565293A6B50; Tue, 25 Aug 2009 11:36:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg0ox-000D5h-Eg for namedroppers-data0@psg.com; Tue, 25 Aug 2009 18:32:39 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg0ot-000D4x-L3 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 18:32:37 +0000 Received: from [192.168.1.10] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 4FCD9C2DA5; Tue, 25 Aug 2009 19:32:33 +0100 (BST) Date: Tue, 25 Aug 2009 19:32:31 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] EDNS0 fallback "revisited" Message-ID: <7D875E0A04BC5DD3AB13F501@nimrod.home> In-Reply-To: <200908251744.n7PHiqmI073529@stora.ogud.com> References: <200908251744.n7PHiqmI073529@stora.ogud.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 25 August 2009 13:44:28 -0400 "Olafur Gudmundsson/DNSEXT chair" wrote: > Work to be done: > - Provide tools that measure local pipes and provide configuration hints > - Educate users to use the tools, where to look for problems and how > to update configurations. > - Make the firewall community aware that firewall's are causing DNS > problems > and educate them in how to update their configurations, to allow well > formed UDP fragments to pass. (i.e. non overlapping fragments) > - ditto for DNS proxy vendors. > - Improve EDNS0 fallback strategies. > > Only the last one is a protocol work that DNSEXT can undertake, all the > others are external educations activities that are outside the scope > of the working group. a) Re 2nd & 3rd, was BCP 152 / RFC 5625 out of scope for the working group? b) I note that as currently formulated, 4th would exclude (e.g.) EDNS Paging strategies if not implemented as a fallback). Is this deliberate? It might be that the best strategy when querying for DNSSEC records is to use as a first strategy (rather than a fallback) a technique that that will allow replies greater than 1492 bytes without fragmentation, given large replies seem common and there seems to be at some degree of support for the idea that either fragmentation is bad and should be avoided per se (even if middleboxen were perfectly behaved), or that it is commonly dropped by middleboxen. Perhaps your final para (which I chopped off - sorry) precludes this approach. c) I would have thought new algorithms to reduce the prevalence of large replies (e.g. ECC) would be in scope for this w/g. This is arguably desirable quite aside from the middlebox problem. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 25 12:36:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75133A6FE1; Tue, 25 Aug 2009 12:36:52 -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 laZT5-vDdXot; Tue, 25 Aug 2009 12:36:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FFE63A6900; Tue, 25 Aug 2009 12:36:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg1kT-000Mhk-7H for namedroppers-data0@psg.com; Tue, 25 Aug 2009 19:32:05 +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 1Mg1kP-000Mh3-8b for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 19:32:03 +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 n7PJV84G028718; Tue, 25 Aug 2009 12:31:08 -0700 (PDT) Cc: Nicholas Weaver , "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org Message-Id: <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> From: Nicholas Weaver To: Alex Bligh In-Reply-To: <7D875E0A04BC5DD3AB13F501@nimrod.home> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Tue, 25 Aug 2009 12:31:08 -0700 References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 25, 2009, at 11:32 AM, Alex Bligh wrote: > > > --On 25 August 2009 13:44:28 -0400 "Olafur Gudmundsson/DNSEXT chair" > wrote: > >> Work to be done: >> - Provide tools that measure local pipes and provide configuration >> hints >> - Educate users to use the tools, where to look for problems and how >> to update configurations. >> - Make the firewall community aware that firewall's are causing DNS >> problems >> and educate them in how to update their configurations, to allow >> well >> formed UDP fragments to pass. (i.e. non overlapping fragments) >> - ditto for DNS proxy vendors. >> - Improve EDNS0 fallback strategies. >> >> Only the last one is a protocol work that DNSEXT can undertake, all >> the >> others are external educations activities that are outside the scope >> of the working group. > > a) Re 2nd & 3rd, was BCP 152 / RFC 5625 out of scope for the working > group? > > b) I note that as currently formulated, 4th would exclude (e.g.) > EDNS Paging > strategies if not implemented as a fallback). Is this deliberate? > It might be that the best strategy when querying for DNSSEC records > is > to use as a first strategy (rather than a fallback) a technique that > that will allow replies greater than 1492 bytes without > fragmentation, given large replies seem common and there seems to be > at some degree of support for the idea that either fragmentation is > bad and should be avoided per se (even if middleboxen were perfectly > behaved), or that it is commonly dropped by middleboxen. Perhaps your > final para (which I chopped off - sorry) precludes this approach. Its actually interesting. I'll argue as follows: Fragmentation is NOT a problem for ~85% +/- some delta of resolvers. Which means, for MOST resolvers, its OK if the response fragments. So let the responses be large, we have these large DNSSEC responses anyway, so go for it. But fragmentation IS a problem for ~15%. This is probably too large a number for education strategies to work, since that requires upgrading/replacing existing middleboxes. And too large a number for any strategy which requires timeouts per authority before deciding its a problem, which will kill performance and cause "DNSSEC is broken" complaints once .com starts signing data. But it is a small enough number that these CAN specify an EDNS buffer small enough to fragment, if the resolver can detect that its a global problem, with fallback to TCP on truncation: you're talking ~10-20% of the total queries, assuming all responses exceed the ~1400 MTU of a typical fallback: significant but hardly a killer. Especially since the .org TCP load is probably representative: significant but should be tolerable. Resolvers behind broken middleboxes will today do the fallback to TCP eventually when querying .org for a large response, they are just going through an annoying, performance-killing timeout first. As for authorities, if the authority has a problem SENDING fragments, let it get hammered by having all its responses over TCP: Either it can keep up with the load and they only see an extra couple of RTTs on DNS lookups, or it falls over dead until the offending middlebox get fixed: a self-correcting situation. And as for the rest of the Internet protocols, I think its probably safe to say everyone else has given up on UDP fragments working always on the Internet, judging by the workarounds for IKE. Thus I don't see the particular problem in the DNS protocol saying "We MUST NOT rely on UDP fragmentation working in all cases, but MAY rely on fragmentation working in most cases" Therefore, I believe the objective should be "Make sure that DNSSEC works on an Internet that MOSTLY is OK with UDP fragments, but understands that some resolvers can't handle fragments, and some authorities can't handle fragments", without ANY protocol changes and single-sided changes to just resolvers. Which appears quite doable. From owner-namedroppers@ops.ietf.org Tue Aug 25 13:10: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 5DD013A6FFE; Tue, 25 Aug 2009 13:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.105 X-Spam-Level: **** X-Spam-Status: No, score=4.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lEE-e-3A5wj; Tue, 25 Aug 2009 13:10:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A979A3A6FFB; Tue, 25 Aug 2009 13:10:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg2I4-0001yn-OL for namedroppers-data0@psg.com; Tue, 25 Aug 2009 20:06:48 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg2Hz-0001wR-DY for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 20:06:46 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id BBA043EC1F; Wed, 26 Aug 2009 00:06:40 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a1zJ+Q+oiJIM; Wed, 26 Aug 2009 00:06:40 +0400 (MSD) Received: from [192.168.63.201] (ppp85-140-246-225.pppoe.mtu-net.ru [85.140.246.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 720103EC08; Wed, 26 Aug 2009 00:06:40 +0400 (MSD) Message-ID: <4A94444D.1020509@cryptocom.ru> Date: Wed, 26 Aug 2009 00:06:37 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Hoffman CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Hoffman пишет: 
Greetings again. At the WG meeting in Stockholm, I agreed to write this document to allow crypto algorithms in non-standards-track RFCs to get allocations from the IANA registry. I incorporated a variety of ideas from different folks, including a review of the new policy long before the registry gets full. The document also gives the motivations for the proposed change.

Please consider adopting this short document as a WG work item.
I think that the ideas presented in this document are quite reasonable and the solution it proposes is properly addressing most of the issues which were discussed considering algorithm number allocations.

I support adoption of this document as a WG  work item.

Basil Dolmatov
==========
Cryptocom Ltd.

--Paul Hoffman

  
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Cryptographic Algorithm Identifier Allocation for DNSSEC
	Author(s)       : P. Hoffman
	Filename        : draft-hoffman-dnssec-alg-allocation-00.txt
	Pages           : 4
	Date            : 2009-08-23

This document specifies how DNSSEC cryptographic algorithm
identifiers in the IANA registries are allocated.  It changes the
rule from "standard required" to "RFC required".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-00.txt

From owner-namedroppers@ops.ietf.org Tue Aug 25 13:50: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 20D9A28C36B; Tue, 25 Aug 2009 13:50:27 -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 LjsvO09CRzBD; Tue, 25 Aug 2009 13:50:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4BE1E28C4A0; Tue, 25 Aug 2009 13:48:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg2qp-00073G-PG for namedroppers-data0@psg.com; Tue, 25 Aug 2009 20:42:43 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg2ql-00072Z-HO for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 20:42:41 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1EA91B4067 for ; Tue, 25 Aug 2009 20:42:39 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS0 fallback "revisited" In-Reply-To: Your message of "Tue, 25 Aug 2009 12:31:08 MST." <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 25 Aug 2009 20:42:39 +0000 Message-ID: <14111.1251232959@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Nicholas Weaver > Date: Tue, 25 Aug 2009 12:31:08 -0700 > ... > And as for the rest of the Internet protocols, I think its probably safe > to say everyone else has given up on UDP fragments working always on the > Internet, judging by the workarounds for IKE. Thus I don't see the > particular problem in the DNS protocol saying "We MUST NOT rely on UDP > fragmentation working in all cases, but MAY rely on fragmentation working > in most cases" > > Therefore, I believe the objective should be "Make sure that DNSSEC works > on an Internet that MOSTLY is OK with UDP fragments, but understands that > some resolvers can't handle fragments, and some authorities can't handle > fragments", without ANY protocol changes and single-sided changes to just > resolvers. Which appears quite doable. i recognize in the above text the voice of reason, and i concur with it. meanwhile i still hope for improvements to tcp itself or udp itself, and i have not quite given up on sctp. From owner-namedroppers@ops.ietf.org Tue Aug 25 13:55: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 436973A6BCD; Tue, 25 Aug 2009 13:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWQRAWm+CukN; Tue, 25 Aug 2009 13:55:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 618893A677D; Tue, 25 Aug 2009 13:55:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg2yN-0008E7-Cd for namedroppers-data0@psg.com; Tue, 25 Aug 2009 20:50:31 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg2yJ-0008Df-Id for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 20:50:29 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 9CB34327A7E; Tue, 25 Aug 2009 20:50:26 +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 A1DB6327A79; Tue, 25 Aug 2009 20:50:25 +0000 (UTC) Message-ID: <4A944E90.4040106@isc.org> Date: Tue, 25 Aug 2009 15:50:24 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jim Reid CC: Paul Vixie , namedroppers@ops.ietf.org Subject: [dnsext] Re: measuring TCP query performance References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <62670.1251159270@nsa.vix.com> <4A93347F.4000306@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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Reid wrote: > On 25 Aug 2009, at 01:46, Michael Graff wrote: > >> Apples to oranges. DNS severs have, I suspect, never worried about TCP >> path performance until now. Thus, dnsperf against an unoptimized >> implementaion is pointless. > > Not really Michael. Even if the platforms in the lab environment are not > optimised, a benchmark would provide real data: something that's missing > from the discussion until now. Besides, the servers and TCP stacks in > that lab should be representative of the sort of kit that's in use > today. Even if the results show that the TCP throughput isn't good > enough, at least there would be some data points for those who might > work on optimising the name server and/or TCP software. Very true. All I'm saying is that I don't want someone to benchmark current DNS implementations (which are likely optimized only for UDP) and then use this as proof that the sky is falling. Knowing two data points -- what a well tuned TCP based system can do, vs what we can do out of the box with current implementations, is useful. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqUTpAACgkQ+NNi0s9NRJ0MdgCfZq5fLTxNMSM62rHqL0ZTMvvH PTsAn3I9mruZiXcvB0h6FM3+efE+q7h2 =IoOx -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Tue Aug 25 15:28: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 BA0543A6878; Tue, 25 Aug 2009 15:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 r2k+Yv2ElLbz; Tue, 25 Aug 2009 15:28:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C47593A6B50; Tue, 25 Aug 2009 15:28:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4Q3-000OLa-JX for namedroppers-data0@psg.com; Tue, 25 Aug 2009 22:23:11 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4Pz-000OKk-M2 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 22:23:09 +0000 Received: by ewy11 with SMTP id 11so3645670ewy.11 for ; Tue, 25 Aug 2009 15:23:06 -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=Iu+jc0C8GNnmYH6iDjSnMZZX8aXrt2TKafOZAf+hTKg=; b=TmTcCjnCvMa7WY07fVS3OH7ILcpUiO/Rrt8FPSdUFYXmLJ+tH4bfHw6vpM6k1O010a 3loWxp7qJxfABHsvO2j/yjsmaroRXznuHIDMV+aYGl9e1WUVJAvZwVAT1SaY4t71zjGW RDBpd+u4IBt6jLOILEVvj/F2QcL0klEKBYO8U= 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=dhFVhHb5rXXfDHdFdCcZfz4+9qj/88f3I0Idt9uADYAyCAeWDOnSlseGA7PoTs5SYU 2MgvkP9DAu7gCXvVauju6AAqP+7aDviv3uGMDboGjVkINn1sJc1ktL6dDE/ctZ72OgZ0 ocRUknqOa6feANnLZw1icPoPf9xVlQiD59dUY= MIME-Version: 1.0 Received: by 10.216.89.138 with SMTP id c10mr1434903wef.47.1251238986092; Tue, 25 Aug 2009 15:23:06 -0700 (PDT) In-Reply-To: <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> From: bert hubert Date: Wed, 26 Aug 2009 00:22:46 +0200 Message-ID: <3efd34cc0908251522h208813b5neb5bbee9071827d8@mail.gmail.com> Subject: Re: [dnsext] EDNS0 fallback "revisited" To: Nicholas Weaver Cc: Alex Bligh , "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 25, 2009 at 9:31 PM, Nicholas Weaver wrote: > Its actually interesting. =A0I'll argue as follows: > > Fragmentation is NOT a problem for ~85% +/- some delta of resolvers. =A0W= hich > means, for MOST resolvers, its OK if the response fragments. =A0So let th= e > responses be large, we have these large DNSSEC responses anyway, so go fo= r > it. Nicholas, In order to guide this discussion, it would help tremendously if you had some report of all your relevant DNS/UDP/TCP statistics (with their caveats). Have you published something like that? Would you consider doing so? Because that would be great. Thanks. From owner-namedroppers@ops.ietf.org Tue Aug 25 15:49: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 2D2433A69B5; Tue, 25 Aug 2009 15:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.889 X-Spam-Level: * X-Spam-Status: No, score=1.889 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbc88qMz6o02; Tue, 25 Aug 2009 15:49:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55B0D3A6BCA; Tue, 25 Aug 2009 15:49:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4mE-0001Aj-RG for namedroppers-data0@psg.com; Tue, 25 Aug 2009 22:46:06 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4m7-00019u-Rf for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 22:46:04 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7CE742FE8CBB for ; Tue, 25 Aug 2009 22:45:58 +0000 (UTC) Date: Tue, 25 Aug 2009 18:45:56 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Minutes from IETF-75 uploaded Message-ID: <20090825224556.GI4142@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, I have just uploaded minutes from the IETF-75 meeting to the materials site. You may view them at http://www.ietf.org/proceedings/75/minutes/dnsext.txt. I would appreciate participants checking them to ensure that they find nothing incorrect in them. Thanks to Peter Koch and Joe Abley for acting (respectively) as minute and jabber scribes. I edited Peter's minutes, so errors and omissions are attributable to me. Thanks and best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 25 15:49: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 719093A6D9B; Tue, 25 Aug 2009 15:49:18 -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 wepHMHDBhhZ2; Tue, 25 Aug 2009 15:49:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93CC83A6BCA; Tue, 25 Aug 2009 15:49:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4lU-00015a-4F for namedroppers-data0@psg.com; Tue, 25 Aug 2009 22:45:20 +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 1Mg4lP-00014r-11 for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 22:45: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 n7PMifRT019637; Tue, 25 Aug 2009 15:44:41 -0700 (PDT) Cc: Nicholas Weaver , Alex Bligh , "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: bert hubert In-Reply-To: <3efd34cc0908251522h208813b5neb5bbee9071827d8@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 v936) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Tue, 25 Aug 2009 15:44:41 -0700 References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> <3efd34cc0908251522h208813b5neb5bbee9071827d8@mail.gmail.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 25, 2009, at 3:22 PM, bert hubert wrote: > On Tue, Aug 25, 2009 at 9:31 PM, Nicholas > Weaver wrote: >> Its actually interesting. I'll argue as follows: >> >> Fragmentation is NOT a problem for ~85% +/- some delta of >> resolvers. Which >> means, for MOST resolvers, its OK if the response fragments. So >> let the >> responses be large, we have these large DNSSEC responses anyway, so >> go for >> it. > > Nicholas, > > In order to guide this discussion, it would help tremendously if you > had some report of all your relevant DNS/UDP/TCP statistics (with > their caveats). Have you published something like that? Would you > consider doing so? > > Because that would be great. We didn't do anything with TCP: in fact, our authority is UDP only for testing. The stats for fragmentation behavior based on EDNS size we already posted in the group, although we want to do an extended version that checks reordering and similar, but thats on the low-priortiy todo pile because we need to write up everything else. From owner-namedroppers@ops.ietf.org Tue Aug 25 15:50: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 8B06B3A6C48; Tue, 25 Aug 2009 15:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.144 X-Spam-Level: * X-Spam-Status: No, score=1.144 tagged_above=-999 required=5 tests=[AWL=0.744, 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 bPuLLy1qjBEe; Tue, 25 Aug 2009 15:50:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C22E53A6BCA; Tue, 25 Aug 2009 15:50:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4nh-0001NP-E9 for namedroppers-data0@psg.com; Tue, 25 Aug 2009 22:47:37 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg4ne-0001Mw-Gm for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 22:47:35 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6362C2FE8CBC for ; Tue, 25 Aug 2009 22:47:33 +0000 (UTC) Date: Tue, 25 Aug 2009 18:47:31 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Editor needed Message-ID: <20090825224731.GJ4142@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, One of the milestones on the Charter that we've been waiting to send to our AD is a document that clarifies that TCP transport is mandatory for DNS. We need a volunteer to edit that draft. Does anyone want to do this? Best regards, Andrew (for the Chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 25 16: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 D90033A6933; Tue, 25 Aug 2009 16:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPO+SYirMok4; Tue, 25 Aug 2009 16:11:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 125813A6864; Tue, 25 Aug 2009 16:11:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg56r-0003yb-II for namedroppers-data0@psg.com; Tue, 25 Aug 2009 23:07:25 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg56m-0003nh-4D for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 23:07: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 n7PN5qOn029657; Tue, 25 Aug 2009 23:05:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7PN5qxE029656; Tue, 25 Aug 2009 23:05:52 GMT Date: Tue, 25 Aug 2009 23:05:52 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed Message-ID: <20090825230552.GA29636@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090825224731.GJ4142@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: i've written it - but the nits/tools folks are intolerent of format anomolies. I'm kind of wrapped around another axel for the mo, but fully expect to whip that draft into shape in the next week. --bill On Tue, Aug 25, 2009 at 06:47:31PM -0400, Andrew Sullivan wrote: > Dear colleagues, > > One of the milestones on the Charter that we've been waiting to send > to our AD is a document that clarifies that TCP transport is mandatory > for DNS. We need a volunteer to edit that draft. Does anyone want to > do this? > > Best regards, > > Andrew (for the Chairs) > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 25 16:28: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 84A743A6C7F; Tue, 25 Aug 2009 16:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.271 X-Spam-Level: X-Spam-Status: No, score=0.271 tagged_above=-999 required=5 tests=[AWL=0.144, 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 kwi9eMGDEfDP; Tue, 25 Aug 2009 16:28:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB9283A6A8F; Tue, 25 Aug 2009 16:28:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg5N0-0005nL-9e for namedroppers-data0@psg.com; Tue, 25 Aug 2009 23:24:06 +0000 Received: from [209.85.216.183] (helo=mail-px0-f183.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg5Mw-0005mn-Io for namedroppers@ops.ietf.org; Tue, 25 Aug 2009 23:24:03 +0000 Received: by pxi13 with SMTP id 13so6813337pxi.10 for ; Tue, 25 Aug 2009 16:24:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.138.10 with SMTP id l10mr8594017wad.122.1251242641993; Tue, 25 Aug 2009 16:24:01 -0700 (PDT) In-Reply-To: <20090825224731.GJ4142@shinkuro.com> References: <20090825224731.GJ4142@shinkuro.com> Date: Tue, 25 Aug 2009 16:24:01 -0700 Message-ID: Subject: Re: [dnsext] Editor needed 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 25, 2009 at 3:47 PM, Andrew Sullivan wrote: > One of the milestones on the Charter that we've been waiting to send > to our AD is a document that clarifies that TCP transport is mandatory > for DNS. =A0We need a volunteer to edit that draft. =A0Does anyone want t= o > do this? What's the rationale for this? I don't see why TCP transport should be mandatory for authoritative name servers that only send responses that fit within the 512 byte limit for UDP. From owner-namedroppers@ops.ietf.org Tue Aug 25 17:46: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 823D33A686D; Tue, 25 Aug 2009 17:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_WORKS=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 Uaww5eO-utWZ; Tue, 25 Aug 2009 17:46:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 91F3B3A6A60; Tue, 25 Aug 2009 17:46:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg6Yl-000Gcn-Cf for namedroppers-data0@psg.com; Wed, 26 Aug 2009 00:40: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 1Mg6Yh-000Gbg-9C for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 00:40:17 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 83344E6056; Wed, 26 Aug 2009 00:40:11 +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 n7Q0e7g2001921; Wed, 26 Aug 2009 10:40:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Tue, 25 Aug 2009 15:21:19 +0100." <4CB0582F89044745BF1D1EBF09E549B6@localhost> Date: Wed, 26 Aug 2009 10:40:07 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4CB0582F89044745BF1D1EBF09E549B6@localhost>, "George Barwood" write s: > Has anyone considered a standard way to work around proxies that > prevent responses > 512 bytes being received? > > I very tentatively suggest a new tld, say > > localservers > > could be defined. A query from a stub resolver to the proxy of > > localservers A > > would return the IP address of a fully functional local cache. > > The idea being that it's not necessary to update the middlebox for this to wo > rk. > > If this server failed, the query could be repeated to obtain an alternative. > > Any good? > > George If you are behind a firewall which blocks answers > 512 bytes there is only one solution. FIX THE FIREWALL. If you are behind a NAT/firewall which drops IP fragments there is only one solution. Fix/replace the NAT/firewall. If you are using a proxy which is unintentially breaking EDNS then just stop using it. There are lots of solutions already for this. We don't need yet another one. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 25 18:41: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 C34B33A6C5A; Tue, 25 Aug 2009 18:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.209 X-Spam-Level: **** X-Spam-Status: No, score=4.209 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2vUdp92XC2q; Tue, 25 Aug 2009 18:41:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8200F3A6F14; Tue, 25 Aug 2009 18:41:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg7Rv-000O1Z-Ax for namedroppers-data0@psg.com; Wed, 26 Aug 2009 01:37:19 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg7Rs-000O16-4h for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 01:37:17 +0000 Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Mg7Rl-00017n-Sm; Wed, 26 Aug 2009 02:37:09 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mg7Rl-0003e0-FC; Wed, 26 Aug 2009 02:37:09 +0100 Message-ID: From: "George Barwood" To: "Mark Andrews" Cc: References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Wed, 26 Aug 2009 02:37:03 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > If you are using a proxy which is unintentially breaking EDNS then > just stop using it. There are lots of solutions already for this. > We don't need yet another one. I'm not aware of any solution. I know that my ISP's cache supports DNSSEC ( by sending a suitable query through the proxy ). But I have no way of find it's IP address(es). I don't want to use a remote open cache (for performance reasons), and using a local recursor is anti-social ( if everyone does this the load on TLD servers will increase considerably, and my ISP might block the traffic in any case ). I don't see why I or anyone else should be required to buy a new box simply because the DNSSEC standard has not foreseen this problem, which appears to be easy to fix. And even if I did buy a new box, the chances are it wouldn't help. From owner-namedroppers@ops.ietf.org Tue Aug 25 18:41: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 522293A6D17; Tue, 25 Aug 2009 18:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=-0.174, 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 eBEJT+c5dRHx; Tue, 25 Aug 2009 18:41:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06B323A6C5A; Tue, 25 Aug 2009 18:41:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg7TP-000OBk-Rc for namedroppers-data0@psg.com; Wed, 26 Aug 2009 01:38:51 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg7TM-000OB8-P7 for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 01:38:50 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5ED7EA9443E; Wed, 26 Aug 2009 01:38:48 +0000 (UTC) Message-ID: <4A949228.3040700@mail-abuse.org> Date: Tue, 25 Aug 2009 18:38:48 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Mark Andrews CC: George Barwood , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> In-Reply-To: <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/25/09 5:40 PM, Mark Andrews wrote: > > If you are behind a firewall which blocks answers >512 bytes there is > only one solution. FIX THE FIREWALL. > > If you are behind a NAT/firewall which drops IP fragments there is only > one solution. Fix/replace the NAT/firewall. > > If you are using a proxy which is unintentially breaking EDNS then > just stop using it. There are lots of solutions already for this. > We don't need yet another one. Jumbo frames themselves are fine, but after the source of a request has been confirmed. Unfortunately, this is not how EDNS0 has been structured. How does one prevent distributed UDP jumbo frame reflected attacks emitted from a range of authoritative DNS servers? Is it really safe to promote the use of UDP jumbo frames, or will the Internet need protection from the malicious use of UDP jumbo frames? With bot-nets, BCP38's protection is limited. A small request returning a maximal response might produce upwards to an eighty to one network amplification. This amplification also hides the source of an attack. How would you view this problem? This is not a problem solved by a Firewall, NAT, or Proxy. Do you expect the Internet will also incorporate additional network and resource margins just to sustain potential abuse of EDNS0? -Doug From estrangelkcr@irie-f.com Tue Aug 25 20:01: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 C8DE428C2C8; Tue, 25 Aug 2009 20:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.542 X-Spam-Level: X-Spam-Status: No, score=-42.542 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_IPADDR=2.426, 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_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_FREE_BANG=0.7, 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 zrHZRURg6GuS; Tue, 25 Aug 2009 20:01:49 -0700 (PDT) Received: from pool-72-73-95-135.ptldme.east.myfairpoint.net (pool-72-73-95-135.ptldme.east.myfairpoint.net [72.73.95.135]) by core3.amsl.com (Postfix) with ESMTP id C115728C2D4; Tue, 25 Aug 2009 20:01:48 -0700 (PDT) Received: from 72.73.95.135 by irie-f.com with smtp 063BEJ276; Tue, 25 Aug 2009 20:00:42 -0800 Message-ID: <000d01ca25f9$65e632f0$6400a8c0@estrangelkcr> From: Carroll Sheehan To: Subject: So many people have been telling me about this, and I got it free!! Date: Tue, 25 Aug 2009 20:00:42 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA25F9.65E632F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA25F9.65E632F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Only a few trials left, with this GROUND BREAKING miracel produ= ct, its free.   =A0=A0=A0 Just press the button To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, TamnySystems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA25F9.65E632F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Only a few trials left, with this GROUND BREAKING mira= cel product, its free.
&nb= sp;
=A0=A0=A0 = Just press the button


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top
Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, TamnySystems, In= c.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA25F9.65E632F0-- From owner-namedroppers@ops.ietf.org Tue Aug 25 20:14: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 38AF528C3E5; Tue, 25 Aug 2009 20:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFFidpAvBPmd; Tue, 25 Aug 2009 20:14:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50BC93A6AE8; Tue, 25 Aug 2009 20:14:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg8t2-000AoQ-Lf for namedroppers-data0@psg.com; Wed, 26 Aug 2009 03: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 1Mg8sz-000Anw-6t for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 03:09: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 2D193E601C; Wed, 26 Aug 2009 03:09: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 n7Q39Cc3004273; Wed, 26 Aug 2009 13:09:15 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908260309.n7Q39Cc3004273@drugs.dv.isc.org> To: Matthew Dempsky Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews References: <20090825224731.GJ4142@shinkuro.com> Subject: Re: [dnsext] Editor needed In-reply-to: Your message of "Tue, 25 Aug 2009 16:24:01 MST." Date: Wed, 26 Aug 2009 13:09:12 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Matth ew Dempsky writes: > On Tue, Aug 25, 2009 at 3:47 PM, Andrew Sullivan wrote: > > One of the milestones on the Charter that we've been waiting to send > > to our AD is a document that clarifies that TCP transport is mandatory > > for DNS. =A0We need a volunteer to edit that draft. =A0Does anyone want t= > o > > do this? > > What's the rationale for this? I don't see why TCP transport should > be mandatory for authoritative name servers that only send responses > that fit within the 512 byte limit for UDP. Why do people only think about QUERY. There are multiple opcodes and for some of operations involving these opcodes TCP is the better/only way to talk to the authoritative servers to achieve the desired aims. Being able to say "go way" with a NOTIMP/REFUSED will allow the client to stop making the attempts rather than continually retrying as the TCP connection keeps failing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 25 20:18: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 4AAC928C3DB; Tue, 25 Aug 2009 20:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.257 X-Spam-Level: X-Spam-Status: No, score=0.257 tagged_above=-999 required=5 tests=[AWL=0.130, 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 C8EeQGSjnWGC; Tue, 25 Aug 2009 20:18:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88EBD3A69A0; Tue, 25 Aug 2009 20:18:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg8zg-000Bd2-Hv for namedroppers-data0@psg.com; Wed, 26 Aug 2009 03:16:16 +0000 Received: from [209.85.216.183] (helo=mail-px0-f183.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg8zc-000BcM-E0 for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 03:16:13 +0000 Received: by pxi13 with SMTP id 13so6940707pxi.10 for ; Tue, 25 Aug 2009 20:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.7.2 with SMTP id 2mr8951217wag.211.1251256571883; Tue, 25 Aug 2009 20:16:11 -0700 (PDT) In-Reply-To: <200908260309.n7Q39Cc3004273@drugs.dv.isc.org> References: <20090825224731.GJ4142@shinkuro.com> <200908260309.n7Q39Cc3004273@drugs.dv.isc.org> Date: Tue, 25 Aug 2009 20:16:11 -0700 Message-ID: Subject: Re: [dnsext] Editor needed From: Matthew Dempsky To: Mark Andrews Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 25, 2009 at 8:09 PM, Mark Andrews wrote: > Why do people only think about QUERY. =A0There are multiple opcodes > and for some of operations involving these opcodes TCP is the > better/only way to talk to the authoritative servers to achieve the > desired aims. If you want to require TCP for name servers providing those services, I'm less opposed. But for a server that only supports QUERY and only returns responses within the 512 byte limit for UDP, I don't think TCP transport should be mandatory. From owner-namedroppers@ops.ietf.org Tue Aug 25 20:42: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 C281E3A6930; Tue, 25 Aug 2009 20:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 nhuo5DfC5cLJ; Tue, 25 Aug 2009 20:42:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A5253A6938; Tue, 25 Aug 2009 20:42:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg9LL-000EWp-Tb for namedroppers-data0@psg.com; Wed, 26 Aug 2009 03:38:39 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mg9LG-000EVs-81 for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 03:38:36 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Aug 2009 20:38:33 -0700 Received: from TK5EX14MBXC128.redmond.corp.microsoft.com ([169.254.7.19]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Tue, 25 Aug 2009 20:38:27 -0700 From: Dan Simon To: 'Paul Hoffman' , "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJCCHeefBgCOc+k2vL+wvSdVygpC3On1w Date: Wed, 26 Aug 2009 03:38:26 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: As far as I can tell, the only purpose for this draft is to make it easier = for new algorithms to be introduced into DNSSEC without any WG vetting. I = honestly can't imagine why on earth the WG would want that. There are some obvious *dis*advantages to the proliferation of unvetted cry= ptographic algorithms in DNSSEC. It increases the likelihood that DNS clie= nts will be unable to verify signed DNS records. It increases the likeliho= od that at least some DNSSEC signatures will be insecure (i.e., forgeable).= It increases the likelihood that DNS clients will have to use and integra= te software from multiple sources, including possibly unreliable or even un= trustworthy software, in order to verify DNS signatures. And it increases = the likelihood that the algorithm identifier space will be used up at some = point in the future, when security considerations actually require large-sc= ale conversion to new, safer algorithms. Those are some of the disadvantages. What are the advantages? The draft o= ffers two: governments might wish to impose--er, introduce new, unevaluate= d algorithms, and someone might want to introduce an intellectual property = rights-encumbered algorithm. To me, these seem like great arguments *again= st* this proposal. Put them together, in fact, and we have what I consider= the ultimate nightmare scenario: a government imposes a proprietary, IPR-= encumbered algorithm on its ccTLD, requiring clients all over the world to = install and run software supplied by that government in order to validate t= hat country's DNS records. Why on earth would this WG want to facilitate s= uch an outcome? Baffled, Dan Simon Microsoft Corp. -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Paul Hoffman Sent: Sunday, August 23, 2009 11:33 AM To: namedroppers@ops.ietf.org Subject: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Greetings again. At the WG meeting in Stockholm, I agreed to write this doc= ument to allow crypto algorithms in non-standards-track RFCs to get allocat= ions from the IANA registry. I incorporated a variety of ideas from differe= nt folks, including a review of the new policy long before the registry get= s full. The document also gives the motivations for the proposed change. Please consider adopting this short document as a WG work item. --Paul Hoffman >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > Title : Cryptographic Algorithm Identifier Allocation for= DNSSEC > Author(s) : P. Hoffman > Filename : draft-hoffman-dnssec-alg-allocation-00.txt > Pages : 4 > Date : 2009-08-23 > >This document specifies how DNSSEC cryptographic algorithm >identifiers in the IANA registries are allocated. It changes the >rule from "standard required" to "RFC required". > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-00= .txt From owner-namedroppers@ops.ietf.org Tue Aug 25 21:33: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 100F63A681C; Tue, 25 Aug 2009 21:33: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=[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 JP3QNmDC2ym7; Tue, 25 Aug 2009 21:33:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83E553A6A7B; Tue, 25 Aug 2009 21:32:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgA8n-000MNP-9A for namedroppers-data0@psg.com; Wed, 26 Aug 2009 04:29: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 1MgA8j-000MMs-HV for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 04:29:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1A2A9B40FF for ; Wed, 26 Aug 2009 04:29:41 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies In-Reply-To: Your message of "Wed, 26 Aug 2009 02:37:03 +0100." References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 26 Aug 2009 04:29:41 +0000 Message-ID: <33834.1251260981@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Wed, 26 Aug 2009 02:37:03 +0100 > > ... and using a local recursor is anti-social ( if everyone does this the > load on TLD servers will increase considerably, ... bring it on. we get way more queries from people who don't cache at all, or from people who firewall our answers even though they fail to firewall their own questions, then we would ever see from a change wherein every host on the internet became its own caching recursive nameserver. bring it on. (really.) From owner-namedroppers@ops.ietf.org Tue Aug 25 21:33: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 75CA93A681C; Tue, 25 Aug 2009 21:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 gTcpmNJr7B6P; Tue, 25 Aug 2009 21:33:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 967253A6C0D; Tue, 25 Aug 2009 21:32:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgA6L-000M1x-7r for namedroppers-data0@psg.com; Wed, 26 Aug 2009 04:27:13 +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 1MgA6H-000M0t-NW for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 04: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 72567E605D; Wed, 26 Aug 2009 04:27: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 n7Q4R4Eo004891; Wed, 26 Aug 2009 14:27:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Wed, 26 Aug 2009 02:37:03 +0100." Date: Wed, 26 Aug 2009 14:27:04 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , "George Barwood" write s: > > If you are using a proxy which is unintentially breaking EDNS then > > just stop using it. There are lots of solutions already for this. > > We don't need yet another one. > > I'm not aware of any solution. > > I know that my ISP's cache supports DNSSEC ( by sending a suitable query > through the proxy ). > > But I have no way of find it's IP address(es). There is this thing called the phone if you can't look at the diagnostics of your NAT to see what it is talking too. The phone is actually the best way to solve this if your ISP supplies the offending CPE equipment. They are in a much better position to presure the CPE manufacturer to create a fix. > I don't want to use a remote open cache (for performance reasons), > and using a local recursor is anti-social ( if everyone does > this the load on TLD servers will increase considerably, > and my ISP might block the traffic in any case ). It's not anti-social. No the load won't increase dramatically. If your ISP blocks the traffic get another ISP or forward the queries to the ISP's servers. > I don't see why I or anyone else should be required to buy a new box simply b > ecause the DNSSEC standard has not foreseen this > problem, which appears to be easy to fix. And even if I did buy a new box, th > e chances are it wouldn't help. Buy a new box? You can run a DNS server on just about anything. If you are commenting on me saying replace the firewall then that is the only solution. Similarly NAT's which don't support fragments when talking through them (not at them). You won't be able to talk to your ISP's servers if you don't fix the underlying problem. There are somethings you and work around and others that you can't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 25 21:37: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 0593D3A696A; Tue, 25 Aug 2009 21:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=-0.879, 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 NlW+m1-JzVXi; Tue, 25 Aug 2009 21:37:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 196DB3A6C22; Tue, 25 Aug 2009 21:36:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgACk-000MvP-Lw for namedroppers-data0@psg.com; Wed, 26 Aug 2009 04:33: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 1MgACh-000Muu-Hc for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 04:33:48 +0000 Received: from crankycanuck.ca (72-255-94-185.client.stsn.net [72.255.94.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 645022FE8CBB for ; Wed, 26 Aug 2009 04:33:46 +0000 (UTC) Date: Wed, 26 Aug 2009 00:33:44 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090826043344.GI5405@shinkuro.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. I want to emphasise that the below are questions, and not rhetorical devices. They're leading questions on purpose, because I want to explore a particular possibility. I don't have a well-formulated position on any of this at the moment. On Wed, Aug 26, 2009 at 03:38:26AM +0000, Dan Simon wrote: > seem like great arguments *against* this proposal. Put them > together, in fact, and we have what I consider the ultimate > nightmare scenario: a government imposes a proprietary, > IPR-encumbered algorithm on its ccTLD, requiring clients all over > the world to install and run software supplied by that government in > order to validate that country's DNS records. Do you think it is possible that nobody -- or, more exactly, a tiny subset of the world community -- will actually do what that government wants, such that the government's actions not only fail to achieve the desired action, but embarrass the government in question into recognising that interoperability is more important than whatever it was they wanted from their algorithm? If so, does that countervailing consideration affect your view about this topic? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 25 21:41: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 413983A6C0D; Tue, 25 Aug 2009 21:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 9AVLPkRwH1B8; Tue, 25 Aug 2009 21:41:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6BE03A6B3E; Tue, 25 Aug 2009 21:41:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgAHT-000NZh-4L for namedroppers-data0@psg.com; Wed, 26 Aug 2009 04:38: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 1MgAHP-000NZ1-Ba for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 04:38: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 992DCE6059; Wed, 26 Aug 2009 04:38:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7Q4cXBi004999; Wed, 26 Aug 2009 14:38:36 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908260438.n7Q4cXBi004999@drugs.dv.isc.org> To: Douglas Otis Cc: George Barwood , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <4A949228.3040700@mail-abuse.org> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Tue, 25 Aug 2009 18:38:48 MST." <4A949228.3040700@mail-abuse.org> Date: Wed, 26 Aug 2009 14:38:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A949228.3040700@mail-abuse.org>, Douglas Otis writes: > On 8/25/09 5:40 PM, Mark Andrews wrote: > > > > If you are behind a firewall which blocks answers >512 bytes there is > > only one solution. FIX THE FIREWALL. > > > > If you are behind a NAT/firewall which drops IP fragments there is only > > one solution. Fix/replace the NAT/firewall. > > > > If you are using a proxy which is unintentially breaking EDNS then > > just stop using it. There are lots of solutions already for this. > > We don't need yet another one. > > Jumbo frames themselves are fine, but after the source of a request has > been confirmed. Unfortunately, this is not how EDNS0 has been structured. This is a IP problem, not a EDNS problem. > How does one prevent distributed UDP jumbo frame reflected attacks > emitted from a range of authoritative DNS servers? Is it really safe to > promote the use of UDP jumbo frames, or will the Internet need > protection from the malicious use of UDP jumbo frames? With bot-nets, > BCP38's protection is limited. A bot behind a link that is enforcing BCP38 can only directly attack targets. UDP jumbo frames are a non-issue as the replies can only come back to the compromised machine. > A small request returning a maximal response might produce upwards to an > eighty to one network amplification. This amplification also hides the > source of an attack. How would you view this problem? This is not a > problem solved by a Firewall, NAT, or Proxy. Do you expect the Internet > will also incorporate additional network and resource margins just to > sustain potential abuse of EDNS0? No. I just expect ISP's to actually enforce BCP 38. If they don't in your jurisdiction talk to your local legislators. > -Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 25 22: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 3312A3A7041; Tue, 25 Aug 2009 22:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 9S0sYvWOdl+0; Tue, 25 Aug 2009 22:06:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11FA03A6F65; Tue, 25 Aug 2009 22:06:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgAfO-00014u-Rz for namedroppers-data0@psg.com; Wed, 26 Aug 2009 05:03: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 1MgAfL-00014V-Cl for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 05:03: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 608D9E6059; Wed, 26 Aug 2009 05:03: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 n7Q53E01005353; Wed, 26 Aug 2009 15:03:15 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908260503.n7Q53E01005353@drugs.dv.isc.org> To: Matthew Dempsky Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews References: <20090825224731.GJ4142@shinkuro.com> <200908260309.n7Q39Cc3004273@drugs.dv.isc.org> Subject: Re: [dnsext] Editor needed In-reply-to: Your message of "Tue, 25 Aug 2009 20:16:11 MST." Date: Wed, 26 Aug 2009 15:03:14 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Matth ew Dempsky writes: > On Tue, Aug 25, 2009 at 8:09 PM, Mark Andrews wrote: > > Why do people only think about QUERY. =A0There are multiple opcodes > > and for some of operations involving these opcodes TCP is the > > better/only way to talk to the authoritative servers to achieve the > > desired aims. > > If you want to require TCP for name servers providing those services, > I'm less opposed. But for a server that only supports QUERY and only > returns responses within the 512 byte limit for UDP, I don't think TCP > transport should be mandatory. It should be manditory because it people get that analysis wrong. It should be manditory because the SHOULD allows shoddy vendors to ship servers without any TCP support despite all the problems it causes and yet claim RFC compliance. It should be manditory because there are lots of sites that are scared to make their responses bigger than 512 bytes due to the existance of the shoddy products above. If you can get away with blocking TCP well and good but the moment it causes any problem the onest should be on you to fix the problem and it won't be there until TCP support is a MUST. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Aug 25 22:24: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 2C8B93A67AE; Tue, 25 Aug 2009 22:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 Qqy1eyjLzFS7; Tue, 25 Aug 2009 22:24:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 242CA3A7042; Tue, 25 Aug 2009 22:24:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgAwZ-0003Sy-0O for namedroppers-data0@psg.com; Wed, 26 Aug 2009 05:21:11 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgAwV-0003R8-MR for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 05:21:09 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Aug 2009 22:21:07 -0700 Received: from TK5EX14MBXC128.redmond.corp.microsoft.com ([169.254.7.19]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 25 Aug 2009 22:21:05 -0700 From: Dan Simon To: Andrew Sullivan , "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJgbE2de2TGIz+k2u8mmcnOCLfJC3wvXQ Date: Wed, 26 Aug 2009 05:21:04 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> In-Reply-To: <20090826043344.GI5405@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew, it's certainly *possible* that a government trying to shove its sof= tware down every DNS client's throat via a proprietary DNSSEC algorithm mig= ht fail miserably. In fact, I have absolutely no idea how likely it would = be to succeed in its attempt. Presumably, a lot would depend on the partic= ular government in question, and the degree to which the world comes to rel= y on DNSSEC, among other factors. But however low or high such a government's a priori odds of success, those= odds--and therefore its likelihood of attempting such a move in the first = place--could only be increased, and quite possibly dramatically so, by the = prospect of its proprietary algorithm having the imprimatur of the IETF and= IANA, as an official part of the DNSSEC standard. Why on earth would we want to give it that imprimatur by default, automatic= ally and without even the opportunity for review? Again, what conceivable = benefit does the DNSSEC community stand to get in return for that heightene= d risk? Still baffled, Dan Simon Microsoft Corp. -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Andrew Sullivan Sent: Tuesday, August 25, 2009 9:34 PM To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNS= SEC No hat. I want to emphasise that the below are questions, and not rhetorical devices. They're leading questions on purpose, because I want to explore a particular possibility. I don't have a well-formulated position on any of this at the moment. On Wed, Aug 26, 2009 at 03:38:26AM +0000, Dan Simon wrote: > seem like great arguments *against* this proposal. Put them > together, in fact, and we have what I consider the ultimate > nightmare scenario: a government imposes a proprietary, > IPR-encumbered algorithm on its ccTLD, requiring clients all over > the world to install and run software supplied by that government in > order to validate that country's DNS records. Do you think it is possible that nobody -- or, more exactly, a tiny subset of the world community -- will actually do what that government wants, such that the government's actions not only fail to achieve the desired action, but embarrass the government in question into recognising that interoperability is more important than whatever it was they wanted from their algorithm? If so, does that countervailing consideration affect your view about this topic? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 25 23: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 05EB23A6910; Tue, 25 Aug 2009 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.088 X-Spam-Level: *** X-Spam-Status: No, score=3.088 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 VXbIglG2defE; Tue, 25 Aug 2009 23:41:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F01BC3A6AFE; Tue, 25 Aug 2009 23:41:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgC7P-000Ds6-9v for namedroppers-data0@psg.com; Wed, 26 Aug 2009 06:36:27 +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 1MgC7K-000Dq0-Pz for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 06:36:24 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MgC7D-0006gD-8q; Wed, 26 Aug 2009 07:36:15 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MgC7C-0002Df-Pt; Wed, 26 Aug 2009 07:36:14 +0100 Message-ID: From: "George Barwood" To: "Mark Andrews" Cc: References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Wed, 26 Aug 2009 07:36:08 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Mark Andrews" To: "George Barwood" Cc: Sent: Wednesday, August 26, 2009 5:27 AM Subject: Re: [dnsext] Working around proxies > > In message , "George Barwood" write > s: >> > If you are using a proxy which is unintentially breaking EDNS then >> > just stop using it. There are lots of solutions already for this. >> > We don't need yet another one. >> >> I'm not aware of any solution. >> >> I know that my ISP's cache supports DNSSEC ( by sending a suitable query >> through the proxy ). >> >> But I have no way of find it's IP address(es). > > There is this thing called the phone if you can't look at the > diagnostics of your NAT to see what it is talking too. The phone > is actually the best way to solve this if your ISP supplies the > offending CPE equipment. They are in a much better position to > presure the CPE manufacturer to create a fix. This is not a scalable solution. The idea that hundreds of millions of consumers will update/upgrade these boxes to improve DNS security is not going to work. I consider this completely unrealistic and also unnecessary. These boxes are quite capable of routing large DNS responses over UDP and TCP, as Ray Bellis has shown. >> I don't want to use a remote open cache (for performance reasons), >> and using a local recursor is anti-social ( if everyone does >> this the load on TLD servers will increase considerably, >> and my ISP might block the traffic in any case ). > > It's not anti-social. No the load won't increase dramatically. If > your ISP blocks the traffic get another ISP or forward the queries > to the ISP's servers. > >> I don't see why I or anyone else should be required to buy a new box simply b >> ecause the DNSSEC standard has not foreseen this >> problem, which appears to be easy to fix. And even if I did buy a new box, th >> e chances are it wouldn't help. > > Buy a new box? You can run a DNS server on just about anything. Problem with running a local recursor is that your non-DNSSEC traffic becomes vulnerable, because port randomization may not work. Well, as you probably know, I have a resolver that uses repetition to overcome this, but it's not ( and probably never will be ) a standard-conformant solution. I don't think there are any servers that allow you to switch to a forwarder for insecure zones ( this might be a useful feature though ). > If you are commenting on me saying replace the firewall then that > is the only solution. Similarly NAT's which don't support fragments > when talking through them (not at them). You won't be able to talk > to your ISP's servers if you don't fix the underlying problem. > > There are somethings you and work around and others that you can't. Agreed. But this is something that is easily worked around, albeit requiring standards action. George > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > From owner-namedroppers@ops.ietf.org Wed Aug 26 00: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 7728F3A6A77; Wed, 26 Aug 2009 00:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 eG6XByONnX32; Wed, 26 Aug 2009 00:55:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D9D03A6919; Wed, 26 Aug 2009 00:55:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgDGE-000O2G-Pr for namedroppers-data0@psg.com; Wed, 26 Aug 2009 07:49: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 1MgDGA-000O0n-7c for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 07:49: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 107DCE605D; Wed, 26 Aug 2009 07:49: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 n7Q7nTPN008951; Wed, 26 Aug 2009 17:49:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Wed, 26 Aug 2009 07:36:08 +0100." Date: Wed, 26 Aug 2009 17:49:29 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , "George Barwood" write s: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: > Sent: Wednesday, August 26, 2009 5:27 AM > Subject: Re: [dnsext] Working around proxies > > > > > > In message , "George Barwood" w > rite > > s: > >> > If you are using a proxy which is unintentially breaking EDNS then > >> > just stop using it. There are lots of solutions already for this. > >> > We don't need yet another one. > >> > >> I'm not aware of any solution. > >> > >> I know that my ISP's cache supports DNSSEC ( by sending a suitable query > >> through the proxy ). > >> > >> But I have no way of find it's IP address(es). > > > > There is this thing called the phone if you can't look at the > > diagnostics of your NAT to see what it is talking too. The phone > > is actually the best way to solve this if your ISP supplies the > > offending CPE equipment. They are in a much better position to > > presure the CPE manufacturer to create a fix. > > This is not a scalable solution. The idea that hundreds of millions > of consumers will update/upgrade these boxes to improve DNS security > is not going to work. I consider this completely unrealistic > and also unnecessary. These boxes are quite capable of routing > large DNS responses over UDP and TCP, as Ray Bellis has shown. What's not scalable? Looking at the NAT's diagnostics or ringing the ISP? As far as I can tell they are both scaleable or you need a new ISP if they can't answer their phones :-) > >> I don't want to use a remote open cache (for performance reasons), > >> and using a local recursor is anti-social ( if everyone does > >> this the load on TLD servers will increase considerably, > >> and my ISP might block the traffic in any case ). > > > > It's not anti-social. No the load won't increase dramatically. If > > your ISP blocks the traffic get another ISP or forward the queries > > to the ISP's servers. > > > >> I don't see why I or anyone else should be required to buy a new box simpl > y b > >> ecause the DNSSEC standard has not foreseen this > >> problem, which appears to be easy to fix. And even if I did buy a new box, > th > >> e chances are it wouldn't help. > > > > Buy a new box? You can run a DNS server on just about anything. > > Problem with running a local recursor is that your non-DNSSEC traffic > becomes vulnerable, because port randomization may not work. And that is not also a issue with stub resolvers talking to the recursive server out on the net identified by your proposal? > Well, as you probably know, I have a resolver that uses repetition > to overcome this, but it's not ( and probably never will be ) a > standard-conformant solution. > > I don't think there are any servers that allow you to switch to > a forwarder for insecure zones ( this might be a useful feature though ). > > > If you are commenting on me saying replace the firewall then that > > is the only solution. Similarly NAT's which don't support fragments > > when talking through them (not at them). You won't be able to talk > > to your ISP's servers if you don't fix the underlying problem. > > > > There are somethings you and work around and others that you can't. > > Agreed. But this is something that is easily worked around, albeit > requiring standards action. > > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 26 01:39: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 0399A3A6907; Wed, 26 Aug 2009 01:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.903 X-Spam-Level: ** X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn+JwL3zXzDv; Wed, 26 Aug 2009 01:39:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9127E3A690F; Wed, 26 Aug 2009 01:39:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgDyc-0003n3-B6 for namedroppers-data0@psg.com; Wed, 26 Aug 2009 08:35:30 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgDyX-0003lv-MG for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 08:35:27 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MgDyU-0007Sq-JN; Wed, 26 Aug 2009 09:35:22 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MgDyU-0005BZ-0D; Wed, 26 Aug 2009 09:35:22 +0100 Message-ID: From: "George Barwood" To: "Mark Andrews" Cc: References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Wed, 26 Aug 2009 09:35:15 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: ----- Original Message ----- From: "Mark Andrews" To: "George Barwood" Cc: Sent: Wednesday, August 26, 2009 8:49 AM Subject: Re: [dnsext] Working around proxies > > In message , "George Barwood" write > s: >> >> ----- Original Message ----- >> From: "Mark Andrews" >> To: "George Barwood" >> Cc: >> Sent: Wednesday, August 26, 2009 5:27 AM >> Subject: Re: [dnsext] Working around proxies >> >> >> > >> > In message , "George Barwood" w >> rite >> > s: >> >> > If you are using a proxy which is unintentially breaking EDNS then >> >> > just stop using it. There are lots of solutions already for this. >> >> > We don't need yet another one. >> >> >> >> I'm not aware of any solution. >> >> >> >> I know that my ISP's cache supports DNSSEC ( by sending a suitable query >> >> through the proxy ). >> >> >> >> But I have no way of find it's IP address(es). >> > >> > There is this thing called the phone if you can't look at the >> > diagnostics of your NAT to see what it is talking too. The phone >> > is actually the best way to solve this if your ISP supplies the >> > offending CPE equipment. They are in a much better position to >> > presure the CPE manufacturer to create a fix. >> >> This is not a scalable solution. The idea that hundreds of millions >> of consumers will update/upgrade these boxes to improve DNS security >> is not going to work. I consider this completely unrealistic >> and also unnecessary. These boxes are quite capable of routing >> large DNS responses over UDP and TCP, as Ray Bellis has shown. > > What's not scalable? Looking at the NAT's diagnostics or ringing the ISP? > As far as I can tell they are both scaleable or you need a new ISP if > they can't answer their phones :-) > >> >> I don't want to use a remote open cache (for performance reasons), >> >> and using a local recursor is anti-social ( if everyone does >> >> this the load on TLD servers will increase considerably, >> >> and my ISP might block the traffic in any case ). >> > >> > It's not anti-social. No the load won't increase dramatically. If >> > your ISP blocks the traffic get another ISP or forward the queries >> > to the ISP's servers. >> > >> >> I don't see why I or anyone else should be required to buy a new box simpl >> y b >> >> ecause the DNSSEC standard has not foreseen this >> >> problem, which appears to be easy to fix. And even if I did buy a new box, >> th >> >> e chances are it wouldn't help. >> > >> > Buy a new box? You can run a DNS server on just about anything. >> >> Problem with running a local recursor is that your non-DNSSEC traffic >> becomes vulnerable, because port randomization may not work. > > And that is not also a issue with stub resolvers talking to the > recursive server out on the net identified by your proposal? It seems relatively hard to attack stub resolvers, although I haven't seen much analysis on this. Anyway, I only intended to raise the topic to see if anyone had put much thought into it. The thought experiment is "what if microsoft ship a recursive validating cache with Windows 8" ? What sort of TCP load does that create on the org servers? I'm uneasy about abandoning ISP caches entirely, it seems like a retrograde step. George >> Well, as you probably know, I have a resolver that uses repetition >> to overcome this, but it's not ( and probably never will be ) a >> standard-conformant solution. >> >> I don't think there are any servers that allow you to switch to >> a forwarder for insecure zones ( this might be a useful feature though ). >> >> > If you are commenting on me saying replace the firewall then that >> > is the only solution. Similarly NAT's which don't support fragments >> > when talking through them (not at them). You won't be able to talk >> > to your ISP's servers if you don't fix the underlying problem. >> > >> > There are somethings you and work around and others that you can't. >> >> Agreed. But this is something that is easily worked around, albeit >> requiring standards action. >> >> George > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > From kana0223@777m.jp Wed Aug 26 02:21: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 075A33A708D for ; Wed, 26 Aug 2009 02:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.224 X-Spam-Level: X-Spam-Status: No, score=-14.224 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr-k8oFskdP5 for ; Wed, 26 Aug 2009 02:21:12 -0700 (PDT) Received: from altex.com (unknown [122.168.214.27]) by core3.amsl.com (Postfix) with SMTP id 31E3C3A698E for ; Wed, 26 Aug 2009 02:21:10 -0700 (PDT) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090826092111.31E3C3A698E@core3.amsl.com> Date: Wed, 26 Aug 2009 02:21:10 -0700 (PDT) Show picture and go to site now! From owner-namedroppers@ops.ietf.org Wed Aug 26 07:36: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 60F3F3A6B98; Wed, 26 Aug 2009 07:36:02 -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 6amnFBiJKiwC; Wed, 26 Aug 2009 07:36:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 593523A6B78; Wed, 26 Aug 2009 07:36:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgJTy-0001Mi-Sc for namedroppers-data0@psg.com; Wed, 26 Aug 2009 14:28:14 +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 1MgJTu-0001L6-MZ for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 14:28:12 +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 n7QCIh6B028195; Wed, 26 Aug 2009 05:18:43 -0700 (PDT) Cc: Nicholas Weaver , Andrew Sullivan , "namedroppers@ops.ietf.org" Message-Id: From: Nicholas Weaver To: Dan Simon In-Reply-To: <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Wed, 26 Aug 2009 05:18:29 -0700 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 25, 2009, at 10:21 PM, Dan Simon wrote: > Andrew, it's certainly *possible* that a government trying to shove > its software down every DNS client's throat via a proprietary DNSSEC > algorithm might fail miserably. In fact, I have absolutely no idea > how likely it would be to succeed in its attempt. Presumably, a lot > would depend on the particular government in question, and the > degree to which the world comes to rely on DNSSEC, among other > factors. > > But however low or high such a government's a priori odds of > success, those odds--and therefore its likelihood of attempting such > a move in the first place--could only be increased, and quite > possibly dramatically so, by the prospect of its proprietary > algorithm having the imprimatur of the IETF and IANA, as an official > part of the DNSSEC standard. A related case would be WiFi encryption, where China attempted to do just this with WAPI. Although unsuccesfull in forcing WAPI on the rest of the world, it is a data point that governments will attempt such moves. From owner-namedroppers@ops.ietf.org Wed Aug 26 07:37: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 ECBF23A6B71; Wed, 26 Aug 2009 07:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.865 X-Spam-Level: X-Spam-Status: No, score=-105.865 tagged_above=-999 required=5 tests=[AWL=0.734, 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 7PG-BA305L7U; Wed, 26 Aug 2009 07:37:06 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 239C628C0EE; Wed, 26 Aug 2009 07:37:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgJTw-0001M6-Ns for namedroppers-data0@psg.com; Wed, 26 Aug 2009 14:28:12 +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 1MgJTr-0001L6-TZ for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 14:28:10 +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 n7QCLTRm028482; Wed, 26 Aug 2009 05:21:29 -0700 (PDT) Cc: Nicholas Weaver , "George Barwood" , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200908260749.n7Q7nTPN008951@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 v936) Subject: Re: [dnsext] Working around proxies Date: Wed, 26 Aug 2009 05:21:29 -0700 References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 26, 2009, at 12:49 AM, Mark Andrews wrote: >> This is not a scalable solution. The idea that hundreds of millions >> of consumers will update/upgrade these boxes to improve DNS security >> is not going to work. I consider this completely unrealistic >> and also unnecessary. These boxes are quite capable of routing >> large DNS responses over UDP and TCP, as Ray Bellis has shown. > > What's not scalable? Looking at the NAT's diagnostics or ringing > the ISP? > As far as I can tell they are both scaleable or you need a new ISP if > they can't answer their phones :-) Do you wish to try explaining this to your mother? Everything we do which touches end-users should pass the "Mother" test. Can you explain, quickly and easily, how your mother should go about fixing/improving the problem? From owner-namedroppers@ops.ietf.org Wed Aug 26 07:48: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 0AA2E3A68AE; Wed, 26 Aug 2009 07:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=0.607, 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 860Zg4qEdsIe; Wed, 26 Aug 2009 07:48:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D4413A6973; Wed, 26 Aug 2009 07:48:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgJjj-00046D-US for namedroppers-data0@psg.com; Wed, 26 Aug 2009 14:44:31 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgJjf-00044u-Rc for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 14:44:29 +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 n7QEiKYE093732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 07:44:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> Date: Wed, 26 Aug 2009 07:44:19 -0700 To: Dan Simon , "namedroppers@ops.ietf.org" From: Paul Hoffman Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 3:38 AM +0000 8/26/09, Dan Simon wrote: >As far as I can tell, the only purpose for this draft is to make it easier for new algorithms to be introduced into DNSSEC without any WG vetting. Actually, that scenario is not one of the ones that are covered in the draft. There were other scenarios that *are* covered in the draft, so it is unclear why you would think this was "the only purpose". The WG does not only work on standards-track documents. It is common for WGs in the IETF to produce both Informational and Experimental RFCs. Does this help? >There are some obvious *dis*advantages to the proliferation of unvetted cryptographic algorithms in DNSSEC. Let's look at them, remembering that DNSSEC is the only (or maybe one of the only) security protocol in the IETF that has the restriction that identifiers can only be issued for standards-track RFCs. >It increases the likelihood that DNS clients will be unable to verify signed DNS records. The same is true for every other IETF protocol, yet in practice, this has not been a problem. The market completely trumps any power-hoarding done by the IETF. >It increases the likelihood that at least some DNSSEC signatures will be insecure (i.e., forgeable). That assumes that the WG will quickly put on standards track the best possible signature algorithms. Recent evidence does not support that claim. >It increases the likelihood that DNS clients will have to use and integrate software from multiple sources, including possibly unreliable or even untrustworthy software, in order to verify DNS signatures. What does *have to* mean? In every other security protocol in the IETF, no one has felt a need to add validating software for algorithms that had identifiers, but for which the software didn't care. Not to pick on dol@, but I have not seen S/MIME software that does GOST, even though the Informational RFCs have been out for many years. In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm? >And it increases the likelihood that the algorithm identifier space will be used up at some point in the future, when security considerations actually require large-scale conversion to new, safer algorithms. Hm. I'm getting the feeling that you didn't actually read the draft; this is explicitly covered. >Those are some of the disadvantages. What are the advantages? The draft offers two: governments might wish to impose--er, introduce new, unevaluated algorithms, and someone might want to introduce an intellectual property rights-encumbered algorithm. Funny, I don't see the word "impose" or "unevaluated" in the document. There are plenty of algorithms that are not mandatory that have been widely evaluated that are not on standards track. >To me, these seem like great arguments *against* this proposal. Put them together, in fact, and we have what I consider the ultimate nightmare scenario: a government imposes a proprietary, IPR-encumbered algorithm on its ccTLD, requiring clients all over the world to install and run software supplied by that government in order to validate that country's DNS records. Stop right there. How does the government of some country *require* the clients used in some other country to do anything? No one has to be able to verify all zones. In fact, we already are in the situation where some signatures using standards-track DNSSEC algorithms might not be allowed to be verified. (Will your software verify an RSA-SHA1 signature with a 256-bit key? Should it?) This proposal doesn't change the situation at all. > Why on earth would this WG want to facilitate such an outcome? It wouldn't, of course. Why on earth do you think that outcome is possible? --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 26 08:19: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 461553A68E0; Wed, 26 Aug 2009 08:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-1.691, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIIY2WZVQfV4; Wed, 26 Aug 2009 08:19:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1BBDB3A687D; Wed, 26 Aug 2009 08:19:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKE5-0009yT-LK for namedroppers-data0@psg.com; Wed, 26 Aug 2009 15:15:53 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKE1-0009wd-Ly for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 15:15:51 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 9D7993EC34; Wed, 26 Aug 2009 14:22:27 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xUj5niz2JiiE; Wed, 26 Aug 2009 14:22:27 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 34C6C3EC21; Wed, 26 Aug 2009 14:22:27 +0400 (MSD) Message-ID: <4A950CE2.9080707@cryptocom.ru> Date: Wed, 26 Aug 2009 14:22:26 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dan Simon CC: 'Paul Hoffman' , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> In-Reply-To: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dan Simon пишет: Put them together, in fact, and we have what I consider the ultimate nightmare scenario: a government imposes a proprietary, IPR-encumbered algorithm on its ccTLD, requiring clients all over the world to install and run software supplied by that government in order to validate that country's DNS records. > > Baffled, > > Dan Simon Microsoft Corp. This is exactly that was made with RSA/SHA, moreover it is supposed to be used in order to validate _all_other_countries_ DNS records. Looks like dual-standard approach, heh? dol@ > From owner-namedroppers@ops.ietf.org Wed Aug 26 08: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 A6ACA3A6F02; Wed, 26 Aug 2009 08:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.768 X-Spam-Level: *** X-Spam-Status: No, score=3.768 tagged_above=-999 required=5 tests=[AWL=-0.127, 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 ex7hlQy41S0z; Wed, 26 Aug 2009 08:40:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E9EC3A6D27; Wed, 26 Aug 2009 08:40:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKWt-000DLh-8o for namedroppers-data0@psg.com; Wed, 26 Aug 2009 15:35:19 +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 1MgKWp-000DL6-FF for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 15:35:17 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MgKWf-0003Zu-14; Wed, 26 Aug 2009 16:35:05 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MgKWe-0002ns-E7; Wed, 26 Aug 2009 16:35:04 +0100 Message-ID: <97E179C03BD54602B49D84BD7FDFBBFA@localhost> From: "George Barwood" To: "Nicholas Weaver" , "Mark Andrews" Cc: "Nicholas Weaver" , References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Wed, 26 Aug 2009 16:34:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk5pY2hvbGFzIFdlYXZlciIg PG53ZWF2ZXJASUNTSS5CZXJrZWxleS5FRFU+DQpUbzogIk1hcmsgQW5kcmV3cyIgPG1hcmthQGlz Yy5vcmc+DQpDYzogIk5pY2hvbGFzIFdlYXZlciIgPG53ZWF2ZXJASUNTSS5CZXJrZWxleS5FRFU+ OyAiR2VvcmdlIEJhcndvb2QiIDxnZW9yZ2UuYmFyd29vZEBibHVleW9uZGVyLmNvLnVrPjsgPG5h bWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNiwgMjAw OSAxOjIxIFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gV29ya2luZyBhcm91bmQgcHJveGllcyAN Cg0KDQo+IA0KPiBPbiBBdWcgMjYsIDIwMDksIGF0IDEyOjQ5IEFNLCBNYXJrIEFuZHJld3Mgd3Jv dGU6DQo+Pj4gVGhpcyBpcyBub3QgYSBzY2FsYWJsZSBzb2x1dGlvbi4gVGhlIGlkZWEgdGhhdCBo dW5kcmVkcyBvZiBtaWxsaW9ucw0KPj4+IG9mIGNvbnN1bWVycyB3aWxsIHVwZGF0ZS91cGdyYWRl IHRoZXNlIGJveGVzIHRvIGltcHJvdmUgRE5TIHNlY3VyaXR5DQo+Pj4gaXMgbm90IGdvaW5nIHRv IHdvcmsuIEkgY29uc2lkZXIgdGhpcyBjb21wbGV0ZWx5IHVucmVhbGlzdGljDQo+Pj4gYW5kIGFs c28gdW5uZWNlc3NhcnkuIFRoZXNlIGJveGVzIGFyZSBxdWl0ZSBjYXBhYmxlIG9mIHJvdXRpbmcN Cj4+PiBsYXJnZSBETlMgcmVzcG9uc2VzIG92ZXIgVURQIGFuZCBUQ1AsIGFzIFJheSBCZWxsaXMg aGFzIHNob3duLg0KPj4NCj4+IFdoYXQncyBub3Qgc2NhbGFibGU/ICBMb29raW5nIGF0IHRoZSBO QVQncyBkaWFnbm9zdGljcyBvciByaW5naW5nICANCj4+IHRoZSBJU1A/DQo+PiBBcyBmYXIgYXMg SSBjYW4gdGVsbCB0aGV5IGFyZSBib3RoIHNjYWxlYWJsZSBvciB5b3UgbmVlZCBhIG5ldyBJU1Ag aWYNCj4+IHRoZXkgY2FuJ3QgYW5zd2VyIHRoZWlyIHBob25lcyA6LSkNCj4gDQo+IERvIHlvdSB3 aXNoIHRvIHRyeSBleHBsYWluaW5nIHRoaXMgdG8geW91ciBtb3RoZXI/DQo+IA0KPiBFdmVyeXRo aW5nIHdlIGRvIHdoaWNoIHRvdWNoZXMgZW5kLXVzZXJzIHNob3VsZCBwYXNzIHRoZSAiTW90aGVy IiAgDQo+IHRlc3QuICBDYW4geW91IGV4cGxhaW4sIHF1aWNrbHkgYW5kIGVhc2lseSwgaG93IHlv dXIgbW90aGVyIHNob3VsZCBnbyAgDQo+IGFib3V0IGZpeGluZy9pbXByb3ZpbmcgdGhlIHByb2Js ZW0/DQoNCisxDQoNCkFmdGVyIGZ1cnRoZXIgY29uc2lkZXJhdGlvbiwgSSB0aGluayByYXRoZXIg dGhhbiBhIFRMRCwgYW4gRUROUyBvcHRpb24gLCBxdWl0ZSBzaW1pbGFyIHRvIE5TSUQgKE5TSVA/ KSB3b3VsZCBiZSBiZXR0ZXIuDQoNCkl0IHdvdWxkIHJldHVybiBhIHR5cGUgKCBBIG9yIEFBQUEg KSBhbmQgdGhlIElQIGFkZHJlc3MgdGhlIHF1ZXJ5IHdhcyBhZGRyZXNzZWQgdG8uDQoNCkdlb3Jn ZQ0KDQoNCg0K From owner-namedroppers@ops.ietf.org Wed Aug 26 08:40: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 752503A704C; Wed, 26 Aug 2009 08:40:46 -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 0yJ3XypBxufb; Wed, 26 Aug 2009 08:40:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB8FD3A7015; Wed, 26 Aug 2009 08:40:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKZV-000DjQ-2k for namedroppers-data0@psg.com; Wed, 26 Aug 2009 15:38:01 +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 1MgKZR-000Dit-UT for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 15:37: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 n7QFbrhP016982; Wed, 26 Aug 2009 08:37:53 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <97E179C03BD54602B49D84BD7FDFBBFA@localhost> Subject: Re: [dnsext] Working around proxies X-Priority: 3 References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> <97E179C03BD54602B49D84BD7FDFBBFA@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 08:37:53 -0700 Cc: Nicholas Weaver , "Mark Andrews" , X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 26, 2009, at 8:34 AM, George Barwood wrote: >> On Aug 26, 2009, at 12:49 AM, Mark Andrews wrote: >>>> This is not a scalable solution. The idea that hundreds of millions >>>> of consumers will update/upgrade these boxes to improve DNS >>>> security >>>> is not going to work. I consider this completely unrealistic >>>> and also unnecessary. These boxes are quite capable of routing >>>> large DNS responses over UDP and TCP, as Ray Bellis has shown. >>> >>> What's not scalable? Looking at the NAT's diagnostics or ringing >>> the ISP? >>> As far as I can tell they are both scaleable or you need a new ISP >>> if >>> they can't answer their phones :-) >> >> Do you wish to try explaining this to your mother? >> >> Everything we do which touches end-users should pass the "Mother" >> test. Can you explain, quickly and easily, how your mother should go >> about fixing/improving the problem? > > +1 > > After further consideration, I think rather than a TLD, an EDNS > option , quite similar to NSID (NSIP?) would be better. > > It would return a type ( A or AAAA ) and the IP address the query > was addressed to. The address of the recursive resolver where the query comes from often does not equal the address where a query to the recursive resolver should be address to. EG, for OpenDNS: There are two addresses where recursive requests should be addressed TO, but >30 where queries to the authorities may come from. From owner-namedroppers@ops.ietf.org Wed Aug 26 09:00: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 4B4E828C270; Wed, 26 Aug 2009 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 I-B5hU07YkVg; Wed, 26 Aug 2009 09:00:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 566E928C15D; Wed, 26 Aug 2009 09:00:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKsh-000HUq-Fx for namedroppers-data0@psg.com; Wed, 26 Aug 2009 15:57:51 +0000 Received: from [206.190.53.31] (helo=smtp126.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKsd-000HUD-Me for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 15:57:49 +0000 Received: (qmail 5785 invoked from network); 26 Aug 2009 15:57:46 -0000 Received: from unknown (HELO ?192.168.1.239?) (thierry.moreau@209.148.165.15 with plain) by smtp126.rog.mail.re2.yahoo.com with SMTP; 26 Aug 2009 15:57:46 -0000 X-YMail-OSG: P7W1_5oVM1k7LH053VPuHJWYY1vBFKnMvpK5DPSUMpjuQjAH2LHlJnD3WFOwJcOqzg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A94EBF6.3030603@connotech.com> Date: Wed, 26 Aug 2009 04:01:58 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Paul Hoffman CC: Dan Simon , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Hoffman wrote: > In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm? > Because the institutional dedication to have a single root deployed. The DNS is a critical infrastructure and I see the point made by Dan as an attempt to keep it manageable once DNSSEC is deployed. None of the other uses of public key cryptography are similarly tied to a single focal point of governance. If you have multiple roots subjected to diverse DNSSEC deployment policies, then market forces would play as in other PK deployment fronts. My 0.02 cents ... - Thierry Moreau From owner-namedroppers@ops.ietf.org Wed Aug 26 09:01: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 1A57D3A709E; Wed, 26 Aug 2009 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=0.588, 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 naq8v90Nwmk3; Wed, 26 Aug 2009 09:01:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2807B3A6F79; Wed, 26 Aug 2009 09:01:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKu0-000Hrd-Kw for namedroppers-data0@psg.com; Wed, 26 Aug 2009 15:59:12 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgKtv-000Hqb-7a for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 15:59:10 +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 n7QFx395099712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 08:59:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.micros oft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.micros oft.com> Date: Wed, 26 Aug 2009 08:58:31 -0700 To: Dan Simon , Andrew Sullivan , "namedroppers@ops.ietf.org" From: Paul Hoffman Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 5:21 AM +0000 8/26/09, Dan Simon wrote: >But however low or high such a government's a priori odds of success, those odds--and therefore its likelihood of attempting such a move in the first place--could only be increased, and quite possibly dramatically so, by the prospect of its proprietary algorithm having the imprimatur of the IETF and IANA, as an official part of the DNSSEC standard. The "imprimatur" of an IANA value? That seems a bit far-fetched, given the same imprimatur is granted for other security protocols which are basically never heard from again. To use your company's products as an example, I do not believe that your web clients, nor your IIS server, implements all of the TLS ciphersuites in the range 0xC001 through 0xC019. Those have the imprimatur of IANA, and are defined in RFC 4492, which is an Informational RFC. However, I believe that your company has implemented some of them. But, more importantly, the supposed government *does not need an RFC today*. They could demand that their zones are signed with DNSSEC algorithm 254 and an OID that is controlled by the government. We already allow that in the DNSSEC standard. In such a situation, would your company feel obligated to be able to verify those signatures, use the proprietary software demanded by that government, and so on? Of course not. >Why on earth would we want to give it that imprimatur by default, automatically and without even the opportunity for review? Because we already are. >Again, what conceivable benefit does the DNSSEC community stand to get in return for that heightened risk? The benefit of better interoperability for algorithms that for whatever reason could not be on standards track. This is the same benefit that other IETF security protocols have been using for over a decade. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 26 09:36: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 875AB3A70B3; Wed, 26 Aug 2009 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.924 X-Spam-Level: X-Spam-Status: No, score=-3.924 tagged_above=-999 required=5 tests=[AWL=0.571, 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 n-pmf50s0Nl6; Wed, 26 Aug 2009 09:36:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9586E3A69F3; Wed, 26 Aug 2009 09:36:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgLQ5-000NPc-1v for namedroppers-data0@psg.com; Wed, 26 Aug 2009 16:32:21 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgLQ1-000NP1-Lu for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 16:32:19 +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 n7QGVrsV002192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 09:31:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A94EBF6.3030603@connotech.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> Date: Wed, 26 Aug 2009 09:31:51 -0700 To: Thierry Moreau From: Paul Hoffman Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Cc: Dan Simon , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 4:01 AM -0400 8/26/09, Thierry Moreau wrote: >Paul Hoffman wrote: >>In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm? >> >Because the institutional dedication to have a single root deployed. The DNS is a critical infrastructure and I see the point made by Dan as an attempt to keep it manageable once DNSSEC is deployed. None of the other uses of public key cryptography are similarly tied to a single focal point of governance. This is a valid point, but not one that is affected by the proposal at hand. I would expect the root to only sign with algorithms that they believe everyone can validate; we just had that discussion with respect to RSA-SHA256. The question is what do other zones further down the hierarchy want to sign with. Some might say "we will only sign with algorithms that not everyone will validate", and then need to deal with the effects of their zone rendering bogus for some queries. Others will dual-sign with an algorithm that they trust more than the universally-implemented algorithms, and require that some people validate only the non-universal signature but allow others to still validate with the universal one. >If you have multiple roots subjected to diverse DNSSEC deployment policies, then market forces would play as in other PK deployment fronts. Fortunately, we are not talking about multiple roots. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 26 12:29: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 55CD53A6EEB; Wed, 26 Aug 2009 12:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.647 X-Spam-Level: ** X-Spam-Status: No, score=2.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xzWasVw1mvC; Wed, 26 Aug 2009 12:29:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B5B03A6AD9; Wed, 26 Aug 2009 12:29:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgO7u-00031p-MN for namedroppers-data0@psg.com; Wed, 26 Aug 2009 19:25:46 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgO7r-00031F-0c for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 19:25:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 6A8B53EC3F; Wed, 26 Aug 2009 23:25:41 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hdfMkE+DWZKC; Wed, 26 Aug 2009 23:25:41 +0400 (MSD) Received: from [192.168.63.201] (unknown [91.78.157.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id F1BD73EC34; Wed, 26 Aug 2009 23:25:40 +0400 (MSD) Message-ID: <4A958C33.1010009@cryptocom.ru> Date: Wed, 26 Aug 2009 23:25:39 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Thierry Moreau CC: Paul Hoffman , Dan Simon , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> In-Reply-To: <4A94EBF6.3030603@connotech.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Thierry Moreau пишет: > Paul Hoffman wrote: >> In other words: what makes DNSSEC systems different than those of >> TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need >> to implemet every registered algorithm? Diverse algorithms have been implemented _already_ in TLS, S/MIME (consult the corresponding RFCs), work is in progress on IPSec, and approach is made to SSH too, being the most rigid and inflexible, though. So, one can say: nothing makes DNSSec different in _this_ aspect from these protocols. ;) dol@ > Because the institutional dedication to have a single root deployed. > The DNS is a critical infrastructure and I see the point made by Dan > as an attempt to keep it manageable once DNSSEC is deployed. None of > the other uses of public key cryptography are similarly tied to a > single focal point of governance. > > If you have multiple roots subjected to diverse DNSSEC deployment > policies, then market forces would play as in other PK deployment fronts. > > My 0.02 cents ... > > - Thierry Moreau > From owner-namedroppers@ops.ietf.org Wed Aug 26 12:30: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 DC38B3A70C8; Wed, 26 Aug 2009 12:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 AVckj785MXvR; Wed, 26 Aug 2009 12:30:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D504A3A6AD9; Wed, 26 Aug 2009 12:30:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgO5h-0002ji-C5 for namedroppers-data0@psg.com; Wed, 26 Aug 2009 19:23:29 +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 1MgO5e-0002j6-65 for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 19:23:27 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 50973A9443E; Wed, 26 Aug 2009 19:23:25 +0000 (UTC) Message-ID: <4A958BAD.7020400@mail-abuse.org> Date: Wed, 26 Aug 2009 12:23:25 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Mark Andrews CC: George Barwood , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <4A949228.3040700@mail-abuse.org> <200908260438.n7Q4cXBi004999@drugs.dv.isc.org> In-Reply-To: <200908260438.n7Q4cXBi004999@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/25/09 9:38 PM, Mark Andrews wrote: > In message<4A949228.3040700@mail-abuse.org>, Douglas Otis writes: Mark, >> Jumbo frames themselves are fine, but after the source of a >> request has been confirmed. Unfortunately, this is not how EDNS0 >> has been structured. > > This is a IP problem, not a EDNS problem. Risks related to jumbo frames are fully dependent upon the protocol. Protocols that establish connections or associations do not represent a potential jumbo frame threat. Jumbo frames represent a protocol concern. After all, 1,522 octets was (and is) the maximum Ethernet tagged frame when UDP was established. >> Is it really safe to promote the use of UDP jumbo frames, or will >> the Internet need protection from the malicious use of UDP jumbo >> frames? With bot-nets, BCP38's protection is limited. > > A bot behind a link that is enforcing BCP38 can only directly attack > targets. UDP jumbo frames are a non-issue as the replies can only > come back to the compromised machine. BCP38 restricts forged source IP addresses, but this does not protect addresses within the source IP address filter CIDR, nor does it protect from foreign networks that do not filter source IP addresses. Since the threat is reflective, three or more entities, networks, and regions might be involved. While good, BCP38 is not a complete solution. >> Do you expect the Internet will also incorporate additional >> network and resource margins just to sustain potential abuse of >> EDNS0? > > No. I just expect ISP's to actually enforce BCP 38. If they don't > in your jurisdiction talk to your local legislators. Local legislators can not regulate foreign networks, or even thousands of sources within local source egress filters. Only protocols offer comprehensive solutions. As currently structured, abuse of EDNS0 may allow attacks to be more severe. Defending against attacks touches everything, and represents a greater expense than what would be needed to deploy safe protocols initially. -Doug From reindeeraj@ismenteks.com Wed Aug 26 13:09: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 AD6C63A6D6A; Wed, 26 Aug 2009 13:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.833 X-Spam-Level: X-Spam-Status: No, score=-16.833 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, 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_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_8627E=3.462] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORfmC7jPH9gL; Wed, 26 Aug 2009 13:09:02 -0700 (PDT) Received: from pool-70-22-29-226.balt.east.verizon.net (pool-70-22-39-136.balt.east.verizon.net [70.22.39.136]) by core3.amsl.com (Postfix) with ESMTP id 6DA8F28C56C; Wed, 26 Aug 2009 13:07:54 -0700 (PDT) Received: from 70.22.39.136 by mx.ismenteks.com with smtp DR2B0NZ246; Wed, 26 Aug 2009 16:07:54 -0500 Message-ID: <000d01ca2688$e5ce7100$6400a8c0@reindeeraj> From: Gussie Spencer To: Subject: I am not going to let you pass this opportunity, click and try Date: Wed, 26 Aug 2009 16:07:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2688.E5CE7100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA2688.E5CE7100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not everyone is going to be able to try this miracle product, try it free.   Acai Berry is your ticket to a new life. =A0 Have a=20 look ------=_NextPart_000_0007_01CA2688.E5CE7100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not everyone is going to be able to try this miracle= product, try it free.
 
Acai Berry is your ticket to a new life.
=A0
Have a=20 look
------=_NextPart_000_0007_01CA2688.E5CE7100-- From owner-namedroppers@ops.ietf.org Wed Aug 26 13:38: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 59F2628C2B4; Wed, 26 Aug 2009 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.804 X-Spam-Level: ** X-Spam-Status: No, score=2.804 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, 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 Q4BiswhI5hAx; Wed, 26 Aug 2009 13:38:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A6F528C589; Wed, 26 Aug 2009 13:38:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgPAY-0000VF-UH for namedroppers-data0@psg.com; Wed, 26 Aug 2009 20:32:34 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgPAU-0000UO-J1 for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 20:32:32 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id C09013EC3F; Wed, 26 Aug 2009 23:34:17 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A6PuP+R1TfeF; Wed, 26 Aug 2009 23:34:17 +0400 (MSD) Received: from [192.168.63.201] (unknown [91.78.157.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 7C0E93EC34; Wed, 26 Aug 2009 23:34:17 +0400 (MSD) Message-ID: <4A958E39.5000703@cryptocom.ru> Date: Wed, 26 Aug 2009 23:34:17 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Hoffman CC: Dan Simon , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Hoffman пишет: > What does *have to* mean? In every other security protocol in the IETF, no one has felt a need to add validating software for algorithms that had identifiers, but for which the software didn't care. Not to pick on dol@, but I have not seen S/MIME software that does GOST, even though the Informational RFCs have been out for many years. > > Yes. You have no need to use it. But we _are_using it for all these years. ;) And that is good (IMHO), that this operations are documented in RFCs. This definitely follows the general IETF idea about "rough concensus and running code" (c). We have a running code and the auditory of possible users of this code in several dozens of millions of Russian Internet users is worth be considered a solid ground for _rough_ concensus (IMHO), even if Dan and Microsoft are not supporting it (unfortunately, because Windows users here are forced to install additional software in order to get necessary algorithm support ;), nevertheless it does not affect algorithm usage at whole ;) dol@ From owner-namedroppers@ops.ietf.org Wed Aug 26 13:38: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 7111128C2B4; Wed, 26 Aug 2009 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.245 X-Spam-Level: X-Spam-Status: No, score=0.245 tagged_above=-999 required=5 tests=[AWL=0.118, 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 iBebWJKcAhPd; Wed, 26 Aug 2009 13:38:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF15428C59B; Wed, 26 Aug 2009 13:38:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgPD9-0000m4-Ew for namedroppers-data0@psg.com; Wed, 26 Aug 2009 20:35:15 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgPD6-0000lK-0k for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 20:35:13 +0000 Received: by pxi8 with SMTP id 8so503750pxi.9 for ; Wed, 26 Aug 2009 13:35:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.7.25 with SMTP id 25mr11502007wag.21.1251317001237; Wed, 26 Aug 2009 13:03:21 -0700 (PDT) In-Reply-To: <20090826195944.87ECD3A6CB3@core3.amsl.com> References: <20090826195944.87ECD3A6CB3@core3.amsl.com> Date: Wed, 26 Aug 2009 13:03:21 -0700 Message-ID: Subject: [dnsext] Fwd: New Version Notification for draft-dempsky-dnscurve-00 From: Matthew Dempsky To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: For anyone interested, I've submitted an Internet-Draft describing DNSCurve= . ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Wed, Aug 26, 2009 at 12:59 PM Subject: New Version Notification for draft-dempsky-dnscurve-00 To: matthew@dempsky.org A new version of I-D, draft-dempsky-dnscurve-00.txt has been successfuly submitted by Matthew Dempsky and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-dempsky-dnscurve Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 DNSCurve: Link-level security for the Domain Nam= e System Creation_date: =A0 2009-08-26 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 9 Abstract: This document describes DNSCurve, a protocol extension that adds link-level security to the Domain Name System (DNS). The IETF Secretariat. From naomi7moe@accessmail.jp Wed Aug 26 14:29: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 4A50C3A6D70 for ; Wed, 26 Aug 2009 14:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.786 X-Spam-Level: X-Spam-Status: No, score=-37.786 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj1R3eFWoJdu for ; Wed, 26 Aug 2009 14:29:15 -0700 (PDT) Received: from accept.com.br (unknown [189.75.136.52]) by core3.amsl.com (Postfix) with SMTP id DEA5628C2DA for ; Wed, 26 Aug 2009 14:27:48 -0700 (PDT) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090826212749.DEA5628C2DA@core3.amsl.com> Date: Wed, 26 Aug 2009 14:27:48 -0700 (PDT) Show picture and go to site now! From owner-namedroppers@ops.ietf.org Wed Aug 26 14:30: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 E2D683A6CF5; Wed, 26 Aug 2009 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[AWL=-0.626, 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 4RZDA+HG97Ky; Wed, 26 Aug 2009 14:30:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 160113A672F; Wed, 26 Aug 2009 14:30:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgQ0g-0007zO-Cp for namedroppers-data0@psg.com; Wed, 26 Aug 2009 21:26: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 1MgQ0c-0007yq-Ml for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 21:26:24 +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 n7QLQDCl090000; Wed, 26 Aug 2009 17:26:13 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200908262126.n7QLQDCl090000@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Aug 2009 17:25:43 -0400 To: Basil Dolmatov From: Olafur Gudmundsson Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Cc: Paul Hoffman , Dan Simon , "namedroppers@ops.ietf.org" In-Reply-To: <4A958C33.1010009@cryptocom.ru> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 15:25 26/08/2009, Basil Dolmatov wrote: >Thierry Moreau =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>Paul Hoffman wrote: >>>In other words: what makes DNSSEC systems=20 >>>different than those of TLS, IPsec, S/MIME,=20 >>>SSH, and so on, none of which have felt the=20 >>>need to implemet every registered algorithm? >Diverse algorithms have been implemented=20 >_already_ in TLS, S/MIME (consult the=20 >corresponding RFCs), work is in progress on=20 >IPSec, and approach is made to SSH too, being=20 >the most rigid and inflexible, though. > >So, one can say: nothing makes DNSSec different=20 >in _this_ aspect from these protocols. ;) All the protocols you mention are handshake protocols, DNSSEC is a broadcast protocol. In the first case the two parties (client and server) can check if they support a common protocol and then use it. The server will be able to log the event that a client connected that it did not have any mechanism in common with. In Broadcast protocols there is no feedback mechanism for clients to advertise that alg X is supported. Thus there is no way for DNS publisher to determine if by signing by algorithm Y some significant portion of the Internet can not validate her data. Olafur=20 From stuccoingel28@93-47-36-154.ip111.fastwebnet.it Wed Aug 26 15:13: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 851343A6817 for ; Wed, 26 Aug 2009 15:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.913 X-Spam-Level: *** X-Spam-Status: No, score=3.913 tagged_above=-999 required=5 tests=[AWL=-14.123, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_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_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29K-zVvALgZr for ; Wed, 26 Aug 2009 15:13:50 -0700 (PDT) Received: from 93-47-36-154.ip111.fastwebnet.it (93-47-36-154.ip111.fastwebnet.it [93.47.36.154]) by core3.amsl.com (Postfix) with ESMTP id AD4773A70D8 for ; Wed, 26 Aug 2009 15:13:49 -0700 (PDT) Received: from 93.47.36.154 by razormansion.com; Wed, 26 Aug 2009 23:13:55 +0100 From: "Shannon A. Elzey" To: Subject: great summer Date: Wed, 26 Aug 2009 23:13:55 +0100 Message-ID: <01ca26a2$e20c6120$9a242f5d@stuccoingel28> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Doctor's warning, health risks need to be taken seriously, try it free. http://SMITHABOVE.COM You pay nothing for it. From owner-namedroppers@ops.ietf.org Wed Aug 26 15:15: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 95ED53A67A6; Wed, 26 Aug 2009 15:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=0.518, 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 hdOli4jXO96Y; Wed, 26 Aug 2009 15:15:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0A683A68D2; Wed, 26 Aug 2009 15:15:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgQhy-000EwP-VF for namedroppers-data0@psg.com; Wed, 26 Aug 2009 22:11:10 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgQhv-000EvF-M7 for namedroppers@ops.ietf.org; Wed, 26 Aug 2009 22:11:09 +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 n7QM8P6v024476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 15:08:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200908262126.n7QLQDCl090000@stora.ogud.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> Date: Wed, 26 Aug 2009 15:08:20 -0700 To: Olafur Gudmundsson , Basil Dolmatov From: Paul Hoffman Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Cc: Dan Simon , "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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 5:25 PM -0400 8/26/09, Olafur Gudmundsson wrote: >At 15:25 26/08/2009, Basil Dolmatov wrote: >>Thierry Moreau ®¢¿®¢¸Ñ–®¢µÑ’: >>>Paul Hoffman wrote: >>>>In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm? >>Diverse algorithms have been implemented _already_ in TLS, S/MIME (consult the corresponding RFCs), work is in progress on IPSec, and approach is made to SSH too, being the most rigid and inflexible, though. >> >>So, one can say: nothing makes DNSSec different in _this_ aspect from these protocols. ;) > > >All the protocols you mention are handshake protocols, DNSSEC is a >broadcast protocol. S/MIME, used as email, is *far* from a handshake protocol. If I send you signed email, I have no idea if you can verify it. For example, even though you could verify the signature yesterday on your desktop computer running a proper S/MIME client, you might be receiving the message on your Gmail account today. The fancy footwork the S/MIME community does with the SMIMECapabilities extension to make it look like a handshake protocol is humorous, but ultimately mostly futile. >In Broadcast protocols there is no feedback mechanism for clients >to advertise that alg X is supported. Thus there is no way for DNS publisher >to determine if by signing by algorithm Y some significant portion of >the Internet can not validate her data. The out-of-band feedback in DNSSEC ("why is your domain bogus?") will be infinitely more effective than the out-of-band feedback for signature failures in TLS or S/MIME. Really: the market will truly count here. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 26 18:16: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 7559D3A6E0B; Wed, 26 Aug 2009 18:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 V5MDRWzJTW-s; Wed, 26 Aug 2009 18:16:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BF283A6452; Wed, 26 Aug 2009 18:16:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgTUy-000FYV-Ny for namedroppers-data0@psg.com; Thu, 27 Aug 2009 01:09:56 +0000 Received: from [131.107.115.212] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgTUu-000FXu-HZ for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 01:09:54 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 26 Aug 2009 18:09:51 -0700 Received: from TK5EX14MBXC121.redmond.corp.microsoft.com ([169.254.1.194]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Wed, 26 Aug 2009 17:17:52 -0700 From: Dan Simon To: Basil Dolmatov CC: 'Paul Hoffman' , "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJCCHeefBgCOc+k2vL+wvSdVygpC3On1wgAFg0QCAAA3NoA== Date: Thu, 27 Aug 2009 00:17:51 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05BEB0@TK5EX14MBXC121.redmond.corp.microsoft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <4A950CE2.9080707@cryptocom.ru> In-Reply-To: <4A950CE2.9080707@cryptocom.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: QmFzaWwsIGFzIGZhciBhcyBJIGtub3csIFJTQS9TSEEgaXMgKDEpIG5vdCBpbnRlbGxlY3R1YWwg cHJvcGVydHkgcmlnaHRzLWVuY3VtYmVyZWQgYW55d2hlcmUsIGFuZCAoMikgbm90IHJlcXVpcmVk LS1sZWdhbGx5IG9yIG90aGVyd2lzZS0tdG8gYmUgdXNlZCB3aXRoIEROU1NFQyBpbiB0aGUgVVMg b3IgYW55d2hlcmUgZWxzZS4gIChJZiBJJ20gbWlzdGFrZW4gb24gZWl0aGVyIGNvdW50LCBwbGVh c2UgbGV0IG1lIGtub3cuKSAgUlNBIHVzZWQgdG8gYmUgSVBSLWVuY3VtYmVyZWQsIGFuZCBteSBp bXByZXNzaW9uIGlzIHRoYXQgdGhlIElFVEYgYmFjayB0aGVuIHdhcyB2ZXJ5IGxlZXJ5IGFib3V0 IGluY29ycG9yYXRpbmcgaXQgaW50byBJbnRlcm5ldCBzdGFuZGFyZHMsIGZvciBwcmVjaXNlbHkg dGhhdCByZWFzb24uICAgICANCg0KCQkJCQlEYW4gU2ltb24NCgkJCQkJTWljcm9zb2Z0IENvcnAu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYXNpbCBEb2xtYXRvdiBbbWFp bHRvOmRvbEBjcnlwdG9jb20ucnVdIA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjYsIDIwMDkg MzoyMiBBTQ0KVG86IERhbiBTaW1vbg0KQ2M6ICdQYXVsIEhvZmZtYW4nOyBuYW1lZHJvcHBlcnNA b3BzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gQ3J5cHRvZ3JhcGhpYyBBbGdvcml0 aG0gSWRlbnRpZmllciBBbGxvY2F0aW9uIGZvciBETlNTRUMNCg0KDQoNCkRhbiBTaW1vbiDQv9C4 0YjQtdGCOg0KDQpQdXQgdGhlbSB0b2dldGhlciwgaW4gZmFjdCwgYW5kIHdlIGhhdmUgd2hhdCBJ IGNvbnNpZGVyIHRoZSB1bHRpbWF0ZQ0KbmlnaHRtYXJlIHNjZW5hcmlvOg0KDQogIGEgZ292ZXJu bWVudCBpbXBvc2VzIGEgcHJvcHJpZXRhcnksIElQUi1lbmN1bWJlcmVkIGFsZ29yaXRobSBvbiBp dHMNCmNjVExELCByZXF1aXJpbmcgY2xpZW50cyBhbGwgb3ZlciB0aGUgd29ybGQgdG8gaW5zdGFs bCBhbmQgcnVuIHNvZnR3YXJlDQpzdXBwbGllZA0KDQpieSB0aGF0IGdvdmVybm1lbnQgaW4gb3Jk ZXIgdG8gdmFsaWRhdGUgdGhhdCBjb3VudHJ5J3MgRE5TIHJlY29yZHMuDQoNCj4NCj4gQmFmZmxl ZCwNCj4NCj4gRGFuIFNpbW9uIE1pY3Jvc29mdCBDb3JwLg0KVGhpcyBpcyBleGFjdGx5IHRoYXQg d2FzIG1hZGUgd2l0aCBSU0EvU0hBLCBtb3Jlb3ZlciBpdCBpcyBzdXBwb3NlZCB0bw0KYmUgdXNl ZCBpbiBvcmRlciB0byB2YWxpZGF0ZSBfYWxsX290aGVyX2NvdW50cmllc18gRE5TIHJlY29yZHMu DQoNCg0KTG9va3MgbGlrZSBkdWFsLXN0YW5kYXJkIGFwcHJvYWNoLCBoZWg/DQoNCmRvbEANCg0K Pg0KDQoNCg== From owner-namedroppers@ops.ietf.org Wed Aug 26 18:53: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 868E63A63CB; Wed, 26 Aug 2009 18:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 Myugq8u8E7Pi; Wed, 26 Aug 2009 18:53:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 765393A67B8; Wed, 26 Aug 2009 18:53:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgU6A-000L6P-0p for namedroppers-data0@psg.com; Thu, 27 Aug 2009 01:48:22 +0000 Received: from [68.142.225.234] (helo=smtp118.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgU65-000L5h-Uf for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 01:48:19 +0000 Received: (qmail 92428 invoked from network); 27 Aug 2009 01:48:16 -0000 Received: from unknown (HELO ?192.168.1.239?) (thierry.moreau@209.148.165.15 with plain) by smtp118.rog.mail.re2.yahoo.com with SMTP; 27 Aug 2009 01:48:16 -0000 X-YMail-OSG: OwI1QKUVM1kHjGVDVgBfckwsstqufyUUsRUWyVx6lBfNK3U21KczI61KKcSYbNCO6g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95765E.8040301@connotech.com> Date: Wed, 26 Aug 2009 13:52:30 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Paul Hoffman CC: Olafur Gudmundsson , Basil Dolmatov , Dan Simon , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Hoffman wrote: > At 5:25 PM -0400 8/26/09, Olafur Gudmundsson wrote: > >> At 15:25 26/08/2009, Basil Dolmatov wrote: >> >>> Thierry Moreau ®¢¿®¢¸Ñ–®¢µÑ’: >>> >>>> Paul Hoffman wrote: >>>> >>>>> In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm? >>>>> >>> Diverse algorithms have been implemented _already_ in TLS, S/MIME (consult the corresponding RFCs), work is in progress on IPSec, and approach is made to SSH too, being the most rigid and inflexible, though. >>> >>> So, one can say: nothing makes DNSSec different in _this_ aspect from these protocols. ;) >>> >> >> All the protocols you mention are handshake protocols, DNSSEC is a >> broadcast protocol. >> > > S/MIME, used as email, is *far* from a handshake protocol. If I send you signed email, I have no idea if you can verify it. For example, even though you could verify the signature yesterday on your desktop computer running a proper S/MIME client, you mi > ght be receiving the message on your Gmail account today. The fancy footwork the S/MIME community does with the SMIMECapabilities extension to make it look like a handshake protocol is humorous, but ultimately mostly futile. > > >> In Broadcast protocols there is no feedback mechanism for clients >> to advertise that alg X is supported. Thus there is no way for DNS publisher >> to determine if by signing by algorithm Y some significant portion of >> the Internet can not validate her data. >> > > The out-of-band feedback in DNSSEC ("why is your domain bogus?") will be infinitely more effective than the out-of-band feedback for signature failures in TLS or S/MIME. Really: the market will truly count here. > > "My domain is not bogus, please have your resolver updated to support the DNSSEC compliant signature algorithm XYZ recently endorsed by IANA (... under a contract with the US government ...)." If there are too many algorithms in the DNS zone hierarchy, the market signal may be "no, thanks" to DNSSEC deployment. I think that the draft allows too many algorithms in the DNS zone hierarchy and thus makes seamless DNSSEC validation harder to deploy, without a say from the IETF wg. - Thierry Moreau From owner-namedroppers@ops.ietf.org Wed Aug 26 19:36: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 1D1C43A6B45; Wed, 26 Aug 2009 19:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 9QRl6u4HcfXz; Wed, 26 Aug 2009 19:36:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3604A3A6AAA; Wed, 26 Aug 2009 19:36:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgUlT-0001y0-A6 for namedroppers-data0@psg.com; Thu, 27 Aug 2009 02:31:03 +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 1MgUlP-0001x8-HX for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 02:31: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 2A0F6E601C; Thu, 27 Aug 2009 02:30:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7R2Urux023666; Thu, 27 Aug 2009 12:30:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908270230.n7R2Urux023666@drugs.dv.isc.org> To: Nicholas Weaver Cc: "George Barwood" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Wed, 26 Aug 2009 05:21:29 MST." Date: Thu, 27 Aug 2009 12:30:53 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Nicholas W eaver writes: > > On Aug 26, 2009, at 12:49 AM, Mark Andrews wrote: > >> This is not a scalable solution. The idea that hundreds of millions > >> of consumers will update/upgrade these boxes to improve DNS security > >> is not going to work. I consider this completely unrealistic > >> and also unnecessary. These boxes are quite capable of routing > >> large DNS responses over UDP and TCP, as Ray Bellis has shown. > > > > What's not scalable? Looking at the NAT's diagnostics or ringing > > the ISP? > > As far as I can tell they are both scaleable or you need a new ISP if > > they can't answer their phones :-) > > Do you wish to try explaining this to your mother? > > Everything we do which touches end-users should pass the "Mother" > test. Can you explain, quickly and easily, how your mother should go > about fixing/improving the problem? We really don't need to fix this. Truly. Let natural attrition take care of the existing bad boxes. Let IPv6 deployment take care of the existing bad boxes. Most of them will be replaced within the next 5 years due to the need to get IPv6 support. There is no need to design a protocol to work around the current crop of rubbish that is out there. What we need to do is educate the CPE and CGN developers that are currently working on the next generation of products which support both IPv4 and IPv6 and make sure they don't cut corners. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 26 19:57: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 AE40D3A6CA1; Wed, 26 Aug 2009 19:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZEbndKdv3mZ; Wed, 26 Aug 2009 19:57:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4C5C3A6811; Wed, 26 Aug 2009 19:57:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgV7F-0006Of-Hp for namedroppers-data0@psg.com; Thu, 27 Aug 2009 02:53: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 1MgV7B-0006OA-Oj for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 02: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 C2487E6024; Thu, 27 Aug 2009 02:53:28 +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 n7R2rQii024055; Thu, 27 Aug 2009 12:53:26 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908270253.n7R2rQii024055@drugs.dv.isc.org> To: "George Barwood" Cc: "Nicholas Weaver" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> <97E179C03BD54602B49D84BD7FDFBBFA@localhost> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Wed, 26 Aug 2009 16:34:52 +0100." <97E179C03BD54602B49D84BD7FDFBBFA@localhost> Date: Thu, 27 Aug 2009 12:53:26 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <97E179C03BD54602B49D84BD7FDFBBFA@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Nicholas Weaver" > To: "Mark Andrews" > Cc: "Nicholas Weaver" ; "George Barwood" ; > Sent: Wednesday, August 26, 2009 1:21 PM > Subject: Re: [dnsext] Working around proxies > > > > > > On Aug 26, 2009, at 12:49 AM, Mark Andrews wrote: > >>> This is not a scalable solution. The idea that hundreds of millions > >>> of consumers will update/upgrade these boxes to improve DNS security > >>> is not going to work. I consider this completely unrealistic > >>> and also unnecessary. These boxes are quite capable of routing > >>> large DNS responses over UDP and TCP, as Ray Bellis has shown. > >> > >> What's not scalable? Looking at the NAT's diagnostics or ringing > >> the ISP? > >> As far as I can tell they are both scaleable or you need a new ISP if > >> they can't answer their phones :-) > > > > Do you wish to try explaining this to your mother? > > > > Everything we do which touches end-users should pass the "Mother" > > test. Can you explain, quickly and easily, how your mother should go > > about fixing/improving the problem? > > +1 > > After further consideration, I think rather than a TLD, an EDNS > option , quite similar to NSID (NSIP?) would be better. > > It would return a type ( A or AAAA ) and the IP address the query > was addressed to. Which would then often be a NAT'd address because the ISP is running a server farm for the cache. This would require manual configuration of the servers or more DPI in the NAT to reverse this. This is work that does not need to be done and by the time the client sides get deployed and the servers are upgraded, IPv6 will be apon us and the boxes we are worried about will be being replaced. Mark > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 26 20:30: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 B01113A6CDC; Wed, 26 Aug 2009 20:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 ZtI+lHtxtx2U; Wed, 26 Aug 2009 20:30:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3CFE3A6B0A; Wed, 26 Aug 2009 20:30:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgVcz-000Ctj-Qq for namedroppers-data0@psg.com; Thu, 27 Aug 2009 03:26: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 1MgVcw-000Ct7-4K for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 03:26: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 n7R3QDjj004409; Wed, 26 Aug 2009 20:26:13 -0700 (PDT) Cc: Nicholas Weaver , "George Barwood" , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200908270230.n7R2Urux023666@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 v936) Subject: Re: [dnsext] Working around proxies Date: Wed, 26 Aug 2009 20:26:13 -0700 References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> <200908270230.n7R2Urux023666@drugs.dv.isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 26, 2009, at 7:30 PM, Mark Andrews wrote: > We really don't need to fix this. Truly. Let natural attrition > take care of the existing bad boxes. Let IPv6 deployment take care > of the existing bad boxes. Most of them will be replaced within > the next 5 years due to the need to get IPv6 support. > > There is no need to design a protocol to work around the current > crop of rubbish that is out there. What we need to do is educate > the CPE and CGN developers that are currently working on the next > generation of products which support both IPv4 and IPv6 and make > sure they don't cut corners. I wish I shared your optimism. Right now, IPv6 adoption is pathetic. Almost nobody is using it now, why would people use it later? Rather, the lessons of the horribly painful digital cable transition the cable companies are going through to try to get more bandwidth makes me think that the ISPs will try to keep everyone on IPv4 as long as humanly possible, using carrier-grade NATs and similar devices to prevent address space exhaustion from becoming a problem. Yes, they may begin to offer IPv6, but mostly as an option, not as a replacement, for the IPv4 service already present. Look at it this way. You are an ISP. The cost of putting 1000 customers behind a carrier grade NAT is what, $10K, so $10/customer. The cost of providing/forcing a new NAT/AP device for every customer, including the cost of the service calls you will get trying to get someone like my great aunt to switch out to a new Linksys, is going to be an order of magnitude more per customer. I don't think we should design protocols to specifically avoid the crap, but we should design the software to deal with it, and accept that the crap will still be here tomorrow. From owner-namedroppers@ops.ietf.org Wed Aug 26 20:49: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 CD94F28C0D8; Wed, 26 Aug 2009 20:49:31 -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.144, 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 0-ai4vPaQCXU; Wed, 26 Aug 2009 20:49:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABFF03A688D; Wed, 26 Aug 2009 20:49:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgVuw-000GGQ-Po for namedroppers-data0@psg.com; Thu, 27 Aug 2009 03:44: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 1MgVus-000GFp-UG for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 03:44:52 +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 CA907E601C; Thu, 27 Aug 2009 03:44:49 +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 n7R3ihxg024895; Thu, 27 Aug 2009 13:44:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908270344.n7R3ihxg024895@drugs.dv.isc.org> To: Nicholas Weaver Cc: "George Barwood" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> <200908270230.n7R2Urux023666@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Wed, 26 Aug 2009 20:26:13 MST." Date: Thu, 27 Aug 2009 13:44:43 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Nicholas Weaver writes: > > On Aug 26, 2009, at 7:30 PM, Mark Andrews wrote: > > We really don't need to fix this. Truly. Let natural attrition > > take care of the existing bad boxes. Let IPv6 deployment take care > > of the existing bad boxes. Most of them will be replaced within > > the next 5 years due to the need to get IPv6 support. > > > > There is no need to design a protocol to work around the current > > crop of rubbish that is out there. What we need to do is educate > > the CPE and CGN developers that are currently working on the next > > generation of products which support both IPv4 and IPv6 and make > > sure they don't cut corners. > > I wish I shared your optimism. > > Right now, IPv6 adoption is pathetic. Almost nobody is using it now, > why would people use it later? People wait to the last minute, so what? > Rather, the lessons of the horribly painful digital cable transition > the cable companies are going through to try to get more bandwidth > makes me think that the ISPs will try to keep everyone on IPv4 as long > as humanly possible, using carrier-grade NATs and similar devices to > prevent address space exhaustion from becoming a problem. CGN requires CPE upgrades. The traffic is carried over IPv6 between the CPE and the CGN box operated by the ISP. > Yes, they may begin to offer IPv6, but mostly as an option, not as a > replacement, for the IPv4 service already present. > > Look at it this way. You are an ISP. The cost of putting 1000 > customers behind a carrier grade NAT is what, $10K, so $10/customer. > > The cost of providing/forcing a new NAT/AP device for every customer, > including the cost of the service calls you will get trying to get > someone like my great aunt to switch out to a new Linksys, is going to > be an order of magnitude more per customer. > > I don't think we should design protocols to specifically avoid the > crap, but we should design the software to deal with it, and accept > that the crap will still be here tomorrow. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 26 21:18: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 A5DA728C115; Wed, 26 Aug 2009 21:18:35 -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 5FeQxLYJQHgb; Wed, 26 Aug 2009 21:18:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D56603A6D5C; Wed, 26 Aug 2009 21:18:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgWMI-000LRh-HV for namedroppers-data0@psg.com; Thu, 27 Aug 2009 04:13:10 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgWME-000LR2-9g for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 04:13:08 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKuklUpAZnmf/2dsb2JhbAC/dog5kBcFhBo X-IronPort-AV: E=Sophos;i="4.44,283,1249257600"; d="sig'?scan'208";a="55692511" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Aug 2009 04:13:05 +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 n7R4D5qM009181; Thu, 27 Aug 2009 00:13:05 -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.14.3) with ESMTP id n7R4D5s3007630; Thu, 27 Aug 2009 04:13:05 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.3959); Thu, 27 Aug 2009 00:13:04 -0400 Received: from [192.168.1.4] ([10.82.239.7]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 00:13:03 -0400 Cc: Olafur Gudmundsson , Basil Dolmatov , Dan Simon , Gordon Lennox , "namedroppers@ops.ietf.org WG" Message-Id: <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-260-308758463" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Thu, 27 Aug 2009 06:13:01 +0200 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Aug 2009 04:13:04.0293 (UTC) FILETIME=[AC82FD50:01CA26CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1382; t=1251346385; x=1252210385; 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]=20Cryptographic=20Algorithm=20 Identifier=20Allocation=20for=20=20=20=20DNSSEC |Sender:=20 |To:=20Paul=20Hoffman=20; bh=1sNEN591YzbjTtlq0gY12cDlhXpvBF817qozmequDAc=; b=fK1tpmzdNvbd3fgTZAcjFGNrWpqmpWVUj3tYYxQ6TtW0nJaX6/r8BhJSsn ZxT6s3+cZAIvv3CEM7PwxHtGuBp4jA6LRHyRXu0qxSxhfbaueYuzPSSZt1sS YSuYVC8FoJ; 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-260-308758463 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 aug 2009, at 00.08, Paul Hoffman wrote: > The out-of-band feedback in DNSSEC ("why is your domain bogus?") > will be infinitely more effective than the out-of-band feedback for > signature failures in TLS or S/MIME. Really: the market will truly > count here. The feedback will not be "why is your domain bogus". Your feedback, when you try to access a website, and you can not, is to call your own ISP and say "why is your DNS server broken". And the ISP then have two choices: Bite their tongue and calm the customer down, or stop verifying DNSSEC signed responses. We can _not_ risk having non-interoperability of DNSSEC globally by having everyone picking their own crypto algorithm. Patrik --Apple-Mail-260-308758463 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) iD8DBQFKlgfNvHlR2X0luNwRAnYYAKCStOVQ3DkRbH13VMgYs43oJI2EYACeM/ZB bK/VFkWuBc9SbsTYQszLo24= =gObX -----END PGP SIGNATURE----- --Apple-Mail-260-308758463-- From owner-namedroppers@ops.ietf.org Wed Aug 26 21:23: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 58F273A68B1; Wed, 26 Aug 2009 21:23:41 -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 agq3qlpD9J33; Wed, 26 Aug 2009 21:23:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27FDA28C12C; Wed, 26 Aug 2009 21:23:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgWSS-000MHv-2y for namedroppers-data0@psg.com; Thu, 27 Aug 2009 04:19:32 +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 1MgWSO-000MGv-1d for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 04:19:30 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE+mlUpAZnme/2dsb2JhbAC/eYg5kBQFhBo X-IronPort-AV: E=Sophos;i="4.44,283,1249257600"; d="sig'?scan'208";a="55661035" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Aug 2009 04:19:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7R4JQ2r020305; Thu, 27 Aug 2009 00:19:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7R4JQA5019986; Thu, 27 Aug 2009 04:19:26 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.3959); Thu, 27 Aug 2009 00:18:32 -0400 Received: from [192.168.1.4] ([10.82.239.7]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 00:18:31 -0400 Cc: "namedroppers@ops.ietf.org WG" Message-Id: <434ECD68-79BB-45F1-8A68-A4CD8E4A3E11@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Andrew Sullivan Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-261-309086428" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Fwd: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time please! Date: Thu, 27 Aug 2009 06:18:29 +0200 References: <583565A9-886F-41FB-92EA-B9F3E6741A7C@cisco.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Aug 2009 04:18:32.0085 (UTC) FILETIME=[6FE41450:01CA26CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3264; t=1251346766; x=1252210766; c=relaxed/simple; s=rtpdkim1001; 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:=20Fwd=3A=20[dnsext]=20draft-crocker-dnssec-algo-s ignal-03=20--=20more=20time=20please! |Sender:=20 |To:=20=3D?ISO-8859-1?Q?=3DD3lafur_Gu=3DF0mundsson?=3D=20,=0A=20=20=20=20=20=20=20=20Andrew=20Sullivan=2 0; bh=9Cb6lkwUh8fYls1PqbMZFWAy+xDk0v8I7+vBr2mBhLQ=; b=WC9grPidJG1SJidzAKG6WsKcJJhD8+qVh7V5h8tRqlODSqeFEJ+wzeEAd7 LXKcAGLBeh/JYXMUWepNS65ZjLICyzfe/K65eva39t1tXgew+lktrTxkDNWB 3tTiS3SMJ/; Authentication-Results: rtp-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-261-309086428 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit So, my final conclusion after talking with people is what I describe here. That we before starting accepting drafts that "signal" crypto algorithms, we need something stating: - what the impact *really* is on DNSSEC deployment if we have multiple algorithms - how an algorithm change is to handled - how to handle the selection process of preferred (plural) algorithms (one main, and one secondary that is rolled in or out?) Given this, we can talk about how to do the wording in documents that talk about how to register/signal algorithms. In short, people are worried about non-interoperability regarding deployment. So for this document (draft-crocker-dnssec-algo-signal-03) people said "I think we should wait...nothing wrong with *this* document, but we are missing some pieces in the architecture". Patrik Begin forwarded message: > From: "Patrik Faltstrom (pfaltstr)" > Date: to 30 jul 2009 09.54.07 GMT+02:00 > To: > Subject: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time > please! > > A status report... > > People are still reaching out to me, and it is pretty clear to me > that many people have problems answering yes or no to the question, > and that seems to be similar reasons as both yes and no people want > to talk so much about the issue. > > I will next week summarize in a bit more detail, but it seems people > have the feeling that as the overall goal for standards in the IETF > is interoperability, and the question is really what impact multiple > algorithms have on real life interoperability. How are the > algorithms selected? What if everyone "just pick" a favorite? If we > are going to have preferred algorithms, how do we shift in and shift > out algorithms in that pool (that might have only one entry)? How do > we roll over algorithms? Etc... > > Everyone (almost) I have talked with think that if we only talked > about the real problem, then most certainly one of the things that > will be needed is some kind of signalling, for example in the > transition from one algorithm to another, but at this point in time > -- that is impossible to say. > > So at the moment, I see the consensus in the wg is "not yet, we need > to work on other documents first, or at least in parallell". > > But, I at the same time think I have been contacted by "no" sayers > more than "yes" sayers, so I ask the wg chairs for another week of > work on what my findings on what the consensus of the wg is. > > Patrik > --Apple-Mail-261-309086428 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) iD8DBQFKlgkVvHlR2X0luNwRAuhUAJ4gmTE8upPPbqiSzq3068K81NRkIQCgl4Za y8LK5uME9C3Oi6lyuHkomI4= =KuZ6 -----END PGP SIGNATURE----- --Apple-Mail-261-309086428-- From owner-namedroppers@ops.ietf.org Wed Aug 26 22: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 F06B53A6BA3; Wed, 26 Aug 2009 22:30:51 -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 e1k2ILKaduVp; Wed, 26 Aug 2009 22:30:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E63C3A6B07; Wed, 26 Aug 2009 22:30:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgXUB-0005Nj-JG for namedroppers-data0@psg.com; Thu, 27 Aug 2009 05:25:23 +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 1MgXU8-0005NE-6k for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 05:25:21 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id CE563B42F5 for ; Thu, 27 Aug 2009 05:25:19 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-Reply-To: Your message of "Thu, 27 Aug 2009 06:13:01 +0200." <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 27 Aug 2009 05:25:19 +0000 Message-ID: <3004.1251350719@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > We can _not_ risk having non-interoperability of DNSSEC globally by having > everyone picking their own crypto algorithm. > > Patrik how will we prevent this, other than with local policy in validators that says, treat unknown algos as indeterminate (which effectively means, treat them as unsigned data). if a national government decides to use their own crypto on their own names, the ietf's only recourse against such (assuming the ietf would act against such) is to refuse to allocate a code point and refuse to publish an rfc -- all of which seems terribly unlikely to me. From owner-namedroppers@ops.ietf.org Wed Aug 26 22:33: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 CB5733A6C79; Wed, 26 Aug 2009 22:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgsCgQcyAMJA; Wed, 26 Aug 2009 22:33:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68AF43A6B07; Wed, 26 Aug 2009 22:32:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgXYb-00061F-Hw for namedroppers-data0@psg.com; Thu, 27 Aug 2009 05:29:57 +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 1MgXXv-0005wE-KW for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 05:29:52 +0000 Received: (qmail 37547 invoked from network); 27 Aug 2009 05:37:59 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (59.8.63.163) by necom830.hpcl.titech.ac.jp with SMTP; 27 Aug 2009 05:37:59 -0000 Message-ID: <4A961976.5030004@necom830.hpcl.titech.ac.jp> Date: Thu, 27 Aug 2009 14:28: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: Mark Andrews CC: Nicholas Weaver , George Barwood , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> <200908270230.n7R2Urux023666@drugs.dv.isc.org> <200908270344.n7R3ihxg024895@drugs.dv.isc.org> In-Reply-To: <200908270344.n7R3ihxg024895@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark Andrews wrote: >>Right now, IPv6 adoption is pathetic. Almost nobody is using it now, >>why would people use it later? > People wait to the last minute, so what? And being rescued. >>Rather, the lessons of the horribly painful digital cable transition >>the cable companies are going through to try to get more bandwidth >>makes me think that the ISPs will try to keep everyone on IPv4 as long >>as humanly possible, using carrier-grade NATs and similar devices to >>prevent address space exhaustion from becoming a problem. > CGN requires CPE upgrades. The traffic is carried over IPv6 between > the CPE and the CGN box operated by the ISP. It means most ISPs simply use legacy NAT. Or, see draft-ohta-e2e-nat-00.txt. End to end NAT can be upper compatible to legacy NAT box (perhaps as COE) and, if end hosts are upgraded, offer complete end to end transparency without any IPv6 tunneling. A+P does not need IPv6 tunneling, either, though it also involves COE upgrading (if COE does not already have port based routing capability). Masataka Ohta From owner-namedroppers@ops.ietf.org Wed Aug 26 23:48: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 9C9DD3A6C3B; Wed, 26 Aug 2009 23:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4WjXc4yxs18; Wed, 26 Aug 2009 23:48:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 048AA3A6CD7; Wed, 26 Aug 2009 23:48:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgYfe-000GL0-4g for namedroppers-data0@psg.com; Thu, 27 Aug 2009 06:41: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 1MgYfa-000GKX-O0 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 06:41:16 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 724F7E6023; Thu, 27 Aug 2009 06:41:13 +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 n7R6f78T026596; Thu, 27 Aug 2009 16:41:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908270641.n7R6f78T026596@drugs.dv.isc.org> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Paul Hoffman , Olafur Gudmundsson , Basil Dolmatov , Dan Simon , Gordon Lennox , "namedroppers@ops.ietf.org WG" From: Mark Andrews References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Thu, 27 Aug 2009 06:13:01 +0200." <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> Date: Thu, 27 Aug 2009 16:41:07 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com>, =?ISO-8859-1?Q?Pat rik_F=E4ltstr=F6m?= writes: > On 27 aug 2009, at 00.08, Paul Hoffman wrote: > > > The out-of-band feedback in DNSSEC ("why is your domain bogus?") > > will be infinitely more effective than the out-of-band feedback for > > signature failures in TLS or S/MIME. Really: the market will truly > > count here. > > The feedback will not be "why is your domain bogus". Your feedback, > when you try to access a website, and you can not, is to call your own > ISP and say "why is your DNS server broken". And the ISP then have two > choices: Bite their tongue and calm the customer down, or stop > verifying DNSSEC signed responses. > > We can _not_ risk having non-interoperability of DNSSEC globally by > having everyone picking their own crypto algorithm. > > Patrik Please go read how DNSSEC work before more mis-information is spread. If a validator doesn't understand any of the algorithms then the zone is treated as insecure. You only get bogus when: 1. The validator knows one or more of the algorithms used to sign the zone and 2. All the signatures for the algorithms fail or you don't get then necessary proofs supplied with the response. Bogus indicates validation failed, not you can't validate the answer because you don't understand the algorithm. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Aug 26 23:49: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 5F1B43A6813; Wed, 26 Aug 2009 23:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.125 X-Spam-Level: * X-Spam-Status: No, score=1.125 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3BNBc5Q+tMk; Wed, 26 Aug 2009 23:49:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B55C3A68AA; Wed, 26 Aug 2009 23:49:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgYki-000H6X-CL for namedroppers-data0@psg.com; Thu, 27 Aug 2009 06:46:32 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgYkd-000H5W-Om for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 06:46:29 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 8DAD73EC3B; Thu, 27 Aug 2009 10:46:26 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yN85bYrMUI5f; Thu, 27 Aug 2009 10:46:26 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 3DDB13EC32; Thu, 27 Aug 2009 10:46:26 +0400 (MSD) Message-ID: <4A962BC1.5080701@cryptocom.ru> Date: Thu, 27 Aug 2009 10:46:25 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dan Simon CC: 'Paul Hoffman' , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <4A950CE2.9080707@cryptocom.ru> <934623C28D56444CB073F90BC35244BB05BEB0@TK5EX14MBXC121.redmond.corp.microsoft.com> In-Reply-To: <934623C28D56444CB073F90BC35244BB05BEB0@TK5EX14MBXC121.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dan, keywords were "a government imposes" and not any IPR-related words. Where "a" means "some". dol@ Dan Simon пишет: > Basil, as far as I know, RSA/SHA is (1) not intellectual property rights-encumbered anywhere, and (2) not required--legally or otherwise--to be used with DNSSEC in the US or anywhere else. (If I'm mistaken on either count, please let me know.) RSA used to be IPR-encumbered, and my impression is that the IETF back then was very leery about incorporating it into Internet standards, for precisely that reason. > > Dan Simon > Microsoft Corp. > > -----Original Message----- > From: Basil Dolmatov [mailto:dol@cryptocom.ru] > Sent: Wednesday, August 26, 2009 3:22 AM > To: Dan Simon > Cc: 'Paul Hoffman'; namedroppers@ops.ietf.org > Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC > > > > Dan Simon пишет: > > Put them together, in fact, and we have what I consider the ultimate > nightmare scenario: > > a government imposes a proprietary, IPR-encumbered algorithm on its > ccTLD, requiring clients all over the world to install and run software > supplied > > by that government in order to validate that country's DNS records. > >> Baffled, >> >> Dan Simon Microsoft Corp. > This is exactly that was made with RSA/SHA, moreover it is supposed to > be used in order to validate _all_other_countries_ DNS records. > > > Looks like dual-standard approach, heh? > > dol@ > > > From owner-namedroppers@ops.ietf.org Thu Aug 27 00:10: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 23B2C3A6B2D; Thu, 27 Aug 2009 00:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_62=0.6, MANGLED_PLEASE=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 AMTDj+3EWAO8; Thu, 27 Aug 2009 00:10:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14B853A6988; Thu, 27 Aug 2009 00:10:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZ52-000KAg-Vj for namedroppers-data0@psg.com; Thu, 27 Aug 2009 07:07: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 1MgZ4y-000K9v-Jy for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 07:07:30 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 9614DE601E; Thu, 27 Aug 2009 07:07: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 n7R77O5S026754; Thu, 27 Aug 2009 17:07:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908270707.n7R77O5S026754@drugs.dv.isc.org> To: Dmitry Burkov Cc: Dan Simon , Basil Dolmatov , "'Paul Hoffman'" , "namedroppers@ops.ietf.org" From: Mark Andrews References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <4A950CE2.9080707@cryptocom.ru> <934623C28D56444CB073F90BC35244BB05BEB0@TK5EX14MBXC121.redmond.corp.microsoft.com> <4A9609D3.2020103@burkov.aha.ru> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Thu, 27 Aug 2009 08:21:39 +0400." <4A9609D3.2020103@burkov.aha.ru> Date: Thu, 27 Aug 2009 17:07:24 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A9609D3.2020103@burkov.aha.ru>, Dmitry Burkov writes: > > Dan Simon wrote: > > Basil, as far as I know, RSA/SHA is (1) not intellectual property rights-en > cumbered anywhere, and (2) not required--legally or otherwise--to be used wit > h DNSSEC in the US or anywhere else. (If I'm mistaken on either count, pleas > e let me know.) RSA used to be IPR-encumbered, and my impression is that the > IETF back then was very leery about incorporating it into Internet standards > , for precisely that reason. > > > Dan, > > just short comment, > seems you missed another side of the deployment problem. > > What's about > http://www.bis.doc.gov/encryption/default.htm ? > > Do you think that it will be possible to import/export HSMs(just, for > example) to/from any country and legally use it? > You simply can check current situation in your company Export Regulation > Office(or Department). > > regards, > Dmitry You don't need to use HSM's to do DNSSEC, 99.999% of RSA operations for DNSSEC will be done without using a HSM. All HSM's do is make it harder for the private part of the key pair to be seen by someone who shouldn't see it. HSM's often slow down the crypto so you really only want to use them for signing where keeping the private part of the key safe is more important than the time to sign is. Given how some HSM's I've seen implemented work any compentent computer geek could build one from a standard PC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Aug 27 00:43: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 D6AA13A6DEC; Thu, 27 Aug 2009 00:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, 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 v7UnIKLBUAPi; Thu, 27 Aug 2009 00:43:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BAE228C436; Thu, 27 Aug 2009 00:43:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZaJ-000O9F-3X for namedroppers-data0@psg.com; Thu, 27 Aug 2009 07:39:51 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZaF-000O8o-Dw for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 07:39:48 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 8C3DA1542060; Thu, 27 Aug 2009 08:39:44 +0100 (BST) Cc: "namedroppers@ops.ietf.org WG" Message-Id: <5AF84DA5-AB8D-4805-A15D-F45939238C7C@rfc1035.com> From: Jim Reid To: Paul Vixie In-Reply-To: <3004.1251350719@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Thu, 27 Aug 2009 08:39:44 +0100 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <3004.1251350719@nsa.vix.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 27 Aug 2009, at 06:25, Paul Vixie wrote: >> We can _not_ risk having non-interoperability of DNSSEC globally by >> having >> everyone picking their own crypto algorithm. >> >> Patrik > > how will we prevent this, other than with local policy in validators > that > says, treat unknown algos as indeterminate (which effectively means, > treat > them as unsigned data). if a national government decides to use > their own > crypto on their own names, the ietf's only recourse against such > (assuming > the ietf would act against such) is to refuse to allocate a code > point and > refuse to publish an rfc -- all of which seems terribly unlikely to > me. If a country decides to choose their own algorithm for DNSSEC, they're not going to care what the IETF says or does. And there's nothing the protocol police can do about that. Allocating a code point for such an algorithm is benign. If anything all it does is prevent collisions. IMO, the only focus should be on the algorithm(s) that are mandatory to implement (ie ensure interoperability). If/when something else is chosen, that would be analagous to using RFC1918 addressing: fine behind closed doors between consenting adults but useless for communicating with the rest of the world. From owner-namedroppers@ops.ietf.org Thu Aug 27 00:44: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 0953328C3DF; Thu, 27 Aug 2009 00:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.785 X-Spam-Level: X-Spam-Status: No, score=-5.785 tagged_above=-999 required=5 tests=[AWL=-1.590, 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 3vmnOE6xe4xp; Thu, 27 Aug 2009 00:44:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5667128C2D0; Thu, 27 Aug 2009 00:43:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZZZ-000O3g-Aj for namedroppers-data0@psg.com; Thu, 27 Aug 2009 07:39:05 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZZV-000O1o-3z for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 07:39:03 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGvVlUqrR7PE/2dsb2JhbAC/JYg5kAMFhBo X-IronPort-AV: E=Sophos;i="4.44,284,1249257600"; d="sig'?scan'208";a="91528010" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2009 07:39:00 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7R7d03m021966; Thu, 27 Aug 2009 00:39:00 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7R7cxf8017497; Thu, 27 Aug 2009 07:39:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 09:38:59 +0200 Received: from host-78-64-48-89.homerun.telia.com ([10.61.89.12]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 09:38:58 +0200 Cc: "namedroppers@ops.ietf.org WG" Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Vixie In-Reply-To: <3004.1251350719@nsa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-272-321115160" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Thu, 27 Aug 2009 09:38:58 +0200 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <3004.1251350719@nsa.vix.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Aug 2009 07:38:58.0850 (UTC) FILETIME=[7066C820:01CA26E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1811; t=1251358740; x=1252222740; c=relaxed/simple; s=sjdkim4002; 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]=20Cryptographic=20Algorithm=20 Identifier=20Allocation=20for=20DNSSEC=20 |Sender:=20; bh=C9+AEzA+XAxu0lF4pykMZeyaxNvhT0HrZtDMt33R3pU=; b=BcEXir3mOciFi8S8XXy2kf0OQu3dBEvAuHyixPPH5LgRmySBIZoGx88Mul zuSEke3EPuYwkypIKX+iys7liKSqXNST1949hfWU5dn+YCny3poL99gVrdAJ ehOksnoxxV; Authentication-Results: sj-dkim-4; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-272-321115160 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 aug 2009, at 07.25, Paul Vixie wrote: >> We can _not_ risk having non-interoperability of DNSSEC globally by >> having >> everyone picking their own crypto algorithm. > > how will we prevent this, other than with local policy in validators > that > says, treat unknown algos as indeterminate (which effectively means, > treat > them as unsigned data). if a national government decides to use > their own > crypto on their own names, the ietf's only recourse against such > (assuming > the ietf would act against such) is to refuse to allocate a code > point and > refuse to publish an rfc -- all of which seems terribly unlikely to > me. We can not prevent this, just like we can not prevent anything by "just" writing an RFC. But we can write the correct words on what the impact is, and that way help with some input to the decision making process people go though before they choose arguments to their key generation function of their choice. There are of course other input as well, but people seem (the ones that have contacted me) to want a description that contain a warning message. Patrik --Apple-Mail-272-321115160 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) iD8DBQFKljgSvHlR2X0luNwRAsCyAJ0YKVM8eyyujnz7cwSd56u7TPddFACZAdjy plSa4EZ6C3cHFigBAsp4UBE= =jjNW -----END PGP SIGNATURE----- --Apple-Mail-272-321115160-- From owner-namedroppers@ops.ietf.org Thu Aug 27 00: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 847A528C239; Thu, 27 Aug 2009 00:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.93 X-Spam-Level: *** X-Spam-Status: No, score=3.93 tagged_above=-999 required=5 tests=[AWL=-0.280, 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, 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 odAhdCqOq2JH; Thu, 27 Aug 2009 00:45:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C0603A6DAF; Thu, 27 Aug 2009 00:45:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZcn-000OWo-R5 for namedroppers-data0@psg.com; Thu, 27 Aug 2009 07:42:25 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZck-000OVp-3T for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 07:42:23 +0000 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MgZcY-0007cZ-Rt; Thu, 27 Aug 2009 08:42:10 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MgZcY-0008IP-9w; Thu, 27 Aug 2009 08:42:10 +0100 Message-ID: <4BBAE6196D9E4AA19A248A07DFBE11DE@localhost> From: "George Barwood" To: "Mark Andrews" Cc: "Nicholas Weaver" , References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <200908260040.n7Q0e7g2001921@drugs.dv.isc.org> <200908260427.n7Q4R4Eo004891@drugs.dv.isc.org> <200908260749.n7Q7nTPN008951@drugs.dv.isc.org> <97E179C03BD54602B49D84BD7FDFBBFA@localhost> <200908270253.n7R2rQii024055@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Thu, 27 Aug 2009 08:42:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiAiTmljaG9sYXMgV2VhdmVyIiA8bndlYXZlckBJQ1NJLkJlcmtlbGV5 LkVEVT47IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIEF1Z3Vz dCAyNywgMjAwOSAzOjUzIEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gV29ya2luZyBhcm91bmQg cHJveGllcyANCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDw5N0UxNzlDMDNCRDU0NjAyQjQ5RDg0QkQ3 RkRGQkJGQUBsb2NhbGhvc3Q+LCAiR2VvcmdlIEJhcndvb2QiIHdyaXRlDQo+IHM6DQo+PiANCj4+ IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PiBGcm9tOiAiTmljaG9sYXMgV2VhdmVy IiA8bndlYXZlckBJQ1NJLkJlcmtlbGV5LkVEVT4NCj4+IFRvOiAiTWFyayBBbmRyZXdzIiA8bWFy a2FAaXNjLm9yZz4NCj4+IENjOiAiTmljaG9sYXMgV2VhdmVyIiA8bndlYXZlckBJQ1NJLkJlcmtl bGV5LkVEVT47ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28u dWs+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NCj4+IFNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDI2LCAyMDA5IDE6MjEgUE0NCj4+IFN1YmplY3Q6IFJlOiBbZG5zZXh0XSBXb3JraW5nIGFy b3VuZCBwcm94aWVzIA0KPj4gDQo+PiANCj4+ID4gDQo+PiA+IE9uIEF1ZyAyNiwgMjAwOSwgYXQg MTI6NDkgQU0sIE1hcmsgQW5kcmV3cyB3cm90ZToNCj4+ID4+PiBUaGlzIGlzIG5vdCBhIHNjYWxh YmxlIHNvbHV0aW9uLiBUaGUgaWRlYSB0aGF0IGh1bmRyZWRzIG9mIG1pbGxpb25zDQo+PiA+Pj4g b2YgY29uc3VtZXJzIHdpbGwgdXBkYXRlL3VwZ3JhZGUgdGhlc2UgYm94ZXMgdG8gaW1wcm92ZSBE TlMgc2VjdXJpdHkNCj4+ID4+PiBpcyBub3QgZ29pbmcgdG8gd29yay4gSSBjb25zaWRlciB0aGlz IGNvbXBsZXRlbHkgdW5yZWFsaXN0aWMNCj4+ID4+PiBhbmQgYWxzbyB1bm5lY2Vzc2FyeS4gVGhl c2UgYm94ZXMgYXJlIHF1aXRlIGNhcGFibGUgb2Ygcm91dGluZw0KPj4gPj4+IGxhcmdlIEROUyBy ZXNwb25zZXMgb3ZlciBVRFAgYW5kIFRDUCwgYXMgUmF5IEJlbGxpcyBoYXMgc2hvd24uDQo+PiA+ Pg0KPj4gPj4gV2hhdCdzIG5vdCBzY2FsYWJsZT8gIExvb2tpbmcgYXQgdGhlIE5BVCdzIGRpYWdu b3N0aWNzIG9yIHJpbmdpbmcgIA0KPj4gPj4gdGhlIElTUD8NCj4+ID4+IEFzIGZhciBhcyBJIGNh biB0ZWxsIHRoZXkgYXJlIGJvdGggc2NhbGVhYmxlIG9yIHlvdSBuZWVkIGEgbmV3IElTUCBpZg0K Pj4gPj4gdGhleSBjYW4ndCBhbnN3ZXIgdGhlaXIgcGhvbmVzIDotKQ0KPj4gPiANCj4+ID4gRG8g eW91IHdpc2ggdG8gdHJ5IGV4cGxhaW5pbmcgdGhpcyB0byB5b3VyIG1vdGhlcj8NCj4+ID4gDQo+ PiA+IEV2ZXJ5dGhpbmcgd2UgZG8gd2hpY2ggdG91Y2hlcyBlbmQtdXNlcnMgc2hvdWxkIHBhc3Mg dGhlICJNb3RoZXIiICANCj4+ID4gdGVzdC4gIENhbiB5b3UgZXhwbGFpbiwgcXVpY2tseSBhbmQg ZWFzaWx5LCBob3cgeW91ciBtb3RoZXIgc2hvdWxkIGdvICANCj4+ID4gYWJvdXQgZml4aW5nL2lt cHJvdmluZyB0aGUgcHJvYmxlbT8NCj4+IA0KPj4gKzENCj4+IA0KPj4gQWZ0ZXIgZnVydGhlciBj b25zaWRlcmF0aW9uLCBJIHRoaW5rIHJhdGhlciB0aGFuIGEgVExELCBhbiBFRE5TDQo+PiBvcHRp b24gLCBxdWl0ZSBzaW1pbGFyIHRvIE5TSUQgKE5TSVA/KSB3b3VsZCBiZSBiZXR0ZXIuDQo+PiAN Cj4+IEl0IHdvdWxkIHJldHVybiBhIHR5cGUgKCBBIG9yIEFBQUEgKSBhbmQgdGhlIElQIGFkZHJl c3MgdGhlIHF1ZXJ5DQo+PiB3YXMgYWRkcmVzc2VkIHRvLg0KPiANCj4gV2hpY2ggd291bGQgdGhl biBvZnRlbiBiZSBhIE5BVCdkIGFkZHJlc3MgYmVjYXVzZSB0aGUgSVNQIGlzIHJ1bm5pbmcNCj4g YSBzZXJ2ZXIgZmFybSBmb3IgdGhlIGNhY2hlLiAgVGhpcyB3b3VsZCByZXF1aXJlIG1hbnVhbCBj b25maWd1cmF0aW9uDQo+IG9mIHRoZSBzZXJ2ZXJzIG9yIG1vcmUgRFBJIGluIHRoZSBOQVQgdG8g cmV2ZXJzZSB0aGlzLg0KDQpBZ3JlZWQuIEJ1dCBpdCdzIGVhc2llciB0byBoYXZlIGEgcmVsYXRp dmVseSBzbWFsbCBudW1iZXIgb2YgSVNQcyBkb2luZyBzb21lDQpjb25maWd1cmF0aW9uIHRoYW4g bWlsbGlvbnMgb2YgZ3Jhbm5pZXMuDQogDQo+IFRoaXMgaXMgd29yayB0aGF0IGRvZXMgbm90IG5l ZWQgdG8gYmUgZG9uZSBhbmQgYnkgdGhlIHRpbWUgdGhlDQo+IGNsaWVudCBzaWRlcyBnZXQgZGVw bG95ZWQgYW5kIHRoZSBzZXJ2ZXJzIGFyZSB1cGdyYWRlZCwgSVB2NiB3aWxsDQo+IGJlIGFwb24g dXMgYW5kIHRoZSBib3hlcyB3ZSBhcmUgd29ycmllZCBhYm91dCB3aWxsIGJlIGJlaW5nIHJlcGxh Y2VkLg0KDQpUaGF0IG1heSB3ZWxsIGJlIHRoZSBjYXNlLCBidXQgYSBOU0lQIG9wdGlvbiBhbGxv d3MgZWFybHkgYWRvcHRlciBJU1BzDQp0byBtb3ZlIGZvcndhcmQgd2l0aG91dCB3YWl0aW5nIGZv ciBJUHY2Lg0KDQpJdCBtYXkgYmUgMjAgLSAzMCB5ZWFycyBiZWZvcmUgYWxsIHRoZSBvbGQgYm94 ZXMgYXJlIHJldGlyZWQuDQoNCk5vYm9keSBrbm93cy4NCg0KSXQgc2hvcHVsZCBiZSB2aWV3ZWQg YXMgYSB3YXkgb2Ygd29ya2luZyBhcm91bmQgYSBwcm9ibGVtIHdpdGggZXhpc3RpbmcNCmVxdWlw bWVudC4gSVNQcyBhcmUgbm90IHJlcXVpcmVkIHRvIGRlcGxveSBpdCAoIGluIHRoZSBzYW1lIHdh eSB0aGF0IHRoZXkgYXJlDQpub3QgcmVxdWlyZWQgdG8gZGVwbG95IEROU1NFQyBjYWNoZXMgKS4N Cg0KR2VvcmdlDQoNCj4gTWFyaw0KPiANCj4+IEdlb3JnZQ0KPiANCj4gDQo+IA0KPiAtLSANCj4g TWFyayBBbmRyZXdzLCBJU0MNCj4gMSBTZXltb3VyIFN0LiwgRHVuZGFzIFZhbGxleSwgTlNXIDIx MTcsIEF1c3RyYWxpYQ0KPiBQSE9ORTogKzYxIDIgOTg3MSA0NzQyICAgICAgICAgICAgICAgICBJ TlRFUk5FVDogbWFya2FAaXNjLm9yZw0KPg== From owner-namedroppers@ops.ietf.org Thu Aug 27 00:49: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 F2FA93A6A0E; Thu, 27 Aug 2009 00:49:38 -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.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=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 QZRDq4OOEdIc; Thu, 27 Aug 2009 00:49:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 18A883A68D0; Thu, 27 Aug 2009 00:49:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZhC-000PEO-Hi for namedroppers-data0@psg.com; Thu, 27 Aug 2009 07:46:58 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZh8-000PDS-AH for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 07:46:56 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 6B1081542060; Thu, 27 Aug 2009 08:46:52 +0100 (BST) Cc: Dan Simon , Basil Dolmatov , 'Paul Hoffman' , "namedroppers@ops.ietf.org" Message-Id: From: Jim Reid To: Dmitry Burkov In-Reply-To: <4A9609D3.2020103@burkov.aha.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] political/legal aspects of DNSSEC deployment Date: Thu, 27 Aug 2009 08:46:52 +0100 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <4A950CE2.9080707@cryptocom.ru> <934623C28D56444CB073F90BC35244BB05BEB0@TK5EX14MBXC121.redmond.corp.microsoft.com> <4A9609D3.2020103@burkov.aha.ru> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 27 Aug 2009, at 05:21, Dmitry Burkov wrote: > Do you think that it will be possible to import/export HSMs(just, > for example) to/from any country and legally use it? Dima, it is not necessary to use HSMs to deploy DNSSEC. If someone chooses to use HSM, it's up to them to figure out how to do so in a way that complies with the prevailing law or regulation. [The same holds for DNSSEC deployment in general.] A discussion about that is probably out of scope for this WG. I doubt anyone where is a lawyer specialising in the import or export of crypto. From owner-namedroppers@ops.ietf.org Thu Aug 27 00: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 1F6983A697E; Thu, 27 Aug 2009 00:56:10 -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 3LpdAR1tWiY6; Thu, 27 Aug 2009 00:56:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C4173A695E; Thu, 27 Aug 2009 00:56:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgZnA-0000jw-7N for namedroppers-data0@psg.com; Thu, 27 Aug 2009 07:53:08 +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 1MgZn3-0000hR-H8 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 07:53:06 +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 n7R7qRat008016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 09:52:27 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A963B3B.3020605@nlnetlabs.nl> Date: Thu, 27 Aug 2009 09:52:27 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: Mark Andrews CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul Hoffman , Olafur Gudmundsson , Basil Dolmatov , Dan Simon , Gordon Lennox , "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> In-Reply-To: <200908270641.n7R6f78T026596@drugs.dv.isc.org> 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, 27 Aug 2009 09:52:27 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/2009 08:41 AM, Mark Andrews wrote: > before more mis-information is spread. > > If a validator doesn't understand any of the algorithms then the zone > is treated as insecure. +1 Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqWOzoACgkQkDLqNwOhpPiwsACdFhRt+T1Jw/94hGNZJn378u60 Ns8AmwWcT+Ut52aHWAzwPtAsp9l/m971 =ILxz -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 27 02: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 A0E9D3A69D8; Thu, 27 Aug 2009 02:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrUed4yMRhQ8; Thu, 27 Aug 2009 02:43:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E066F28C362; Thu, 27 Aug 2009 02:43:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgbRG-000G6L-4W for namedroppers-data0@psg.com; Thu, 27 Aug 2009 09:38: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 1MgbRB-000G5C-KO for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 09:38:36 +0000 Received: from [192.168.8.11] (vhe-520087.sshn.net [195.169.221.157]) (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 81480E601C; Thu, 27 Aug 2009 09:38:32 +0000 (UTC) (envelope-from jelte@isc.org) Message-ID: <4A965416.50206@isc.org> Date: Thu, 27 Aug 2009 11:38:30 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Hoffman CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Hoffman wrote: > Greetings again. At the WG meeting in Stockholm, I agreed to write this document to allow crypto algorithms in non-standards-track RFCs to get allocations from the IANA registry. I incorporated a variety of ideas from different folks, including a review of the new policy long before the registry gets full. The document also gives the motivations for the proposed change. > > Please consider adopting this short document as a WG work item. > >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-00.txt while i do have some problems with the current text (unrelated to the ongoing discussion btw, will post about it later), i do support that this be taken up as a wg work item, and i am willing to review. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqWVBYACgkQ4nZCKsdOncXObgCfZ/bWTXl+mowg3E98jNNxCMSp rVIAnAsZd49jW9RHT/j43OmJmuMX0R0y =uq0H -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 27 05:01: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 4FB893A684A; Thu, 27 Aug 2009 05:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.838 X-Spam-Level: X-Spam-Status: No, score=-105.838 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HZkqoHIcE92; Thu, 27 Aug 2009 05:01:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 465E83A672F; Thu, 27 Aug 2009 05:01:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgdaI-000ATs-8q for namedroppers-data0@psg.com; Thu, 27 Aug 2009 11:56:06 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgdaD-000AQv-QS for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 11:56:04 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 74F9B1C020D; Thu, 27 Aug 2009 13:56:00 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 3DAD51C01E4; Thu, 27 Aug 2009 13:56:00 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 3AE97A1D97F; Thu, 27 Aug 2009 13:56:00 +0200 (CEST) Date: Thu, 27 Aug 2009 13:56:00 +0200 From: Stephane Bortzmeyer To: Olafur Gudmundsson Cc: Basil Dolmatov , Paul Hoffman , Dan Simon , "namedroppers@ops.ietf.org" Subject: [dnsext] Re: Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090827115600.GC5936@nic.fr> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908262126.n7QLQDCl090000@stora.ogud.com> X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Aug 26, 2009 at 05:25:43PM -0400, Olafur Gudmundsson wrote a message of 32 lines which said: > All the protocols you mention are handshake protocols, DNSSEC is a > broadcast protocol. [...] In Broadcast protocols there is no > feedback mechanism for clients to advertise that alg X is supported. What if draft-crocker-dnssec-algo-signal were adopted? Do you think it would address your concerns? Abstract The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. Each digital signature added to a response increases the size of the response, which could result in the response message being truncated. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they prefer in a DNSSEC response by defining an EDNS option to list a client's preferred algorithms. From owner-namedroppers@ops.ietf.org Thu Aug 27 07:34: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 CA00428C510; Thu, 27 Aug 2009 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SjfOCbpgZP1; Thu, 27 Aug 2009 07:34:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 227A728C466; Thu, 27 Aug 2009 07:33:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgfxP-0004To-75 for namedroppers-data0@psg.com; Thu, 27 Aug 2009 14:28:07 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgfxC-0004HI-Mc for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 14:28: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 n7REQWOn014966; Thu, 27 Aug 2009 14:26:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7REQUxf014965; Thu, 27 Aug 2009 14:26:30 GMT Date: Thu, 27 Aug 2009 14:26:30 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed Message-ID: <20090827142630.GA14431@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090825224731.GJ4142@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Aug 25, 2009 at 06:47:31PM -0400, Andrew Sullivan wrote: > Dear colleagues, > > One of the milestones on the Charter that we've been waiting to send > to our AD is a document that clarifies that TCP transport is mandatory > for DNS. We need a volunteer to edit that draft. Does anyone want to > do this? > > Best regards, > > Andrew (for the Chairs) ok - so i -loath- the hoops that one must jump through to properly wrap six pages of boilerplate, disclaimers, table of contents, copywrite notices, references, attributions and whatnot around a couple of paragraphs of an idea. To borrow an analogy, the IETF used to be the seedbank for heirloom tomatoes. Lots of diversity in shape, color, flavor. Now... not so much. Its manufactured/square tomatoes. If the inputs arent all the same, its rejected. But enough of my rant. (and yes, I -will- get this into the system somehow) Here is an early proof of the draft for your consideration: ---- Intended Status: Standard Track B. Manning Network Working Group EP.NET Internet-Draft August 2009 Intended status: Informational Expires: Dec 2009 Transport Considerations for DNS draft-manning-dnsop-transport-for-dns-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract DNS queries and responses are available over a variety of transports (UDP/TCP) and may be ported to use other transports in the future. Current use profiles show that most user generated DNS traffic prefers one transport over another. This historical usage pattern has or may lead to the presumption that any DNS traffic, regardless of transport, should be considered on equal footing. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivating factors . . . . . . . . . . . . . . . . . . . . . . 4 2.1. UDP vs TCP for DNS messages . . . . . . . . . . . . . . . 4 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations: . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Familiarity with the DNS[RFC1034] [RFC1035], EDNS0[RFC2671] DNS Security Extensions[RFC4033], [RFC4034] [RFC4035] is assumed. DNS queries and responses are available over a variety of transports (UDP/TCP) and may be ported to use other transports in the future. Current use profiles show that most user generated DNS traffic prefers one transport over another. This historical usage pattern has or may lead to the presumption that any DNS traffic, regardless of transport, should be considered on equal footing. However, not all choices for transport share an equal cost to the DNS operator. This note is intended to inform and educate - that while all transport options MUST/need to be supported, because of the different cost and risk profiles of some transports, an operator may chose to apply different processing criteria to different transports, prefering some transport options over others. 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119] 2. Motivating factors 2.1. UDP vs TCP for DNS messages TCP requires more/longer-living state on both parties of a transaction. For high volume DNS servers even small states per each query that need to be kept for "long" time is a potential DoS vector. Number of DNS servers are answering 50-100 Kq/s thus any state will consume significant memory resources. UDP requires no state past the lifetime of the query. 3. Acknowledgments Number of people have provided usefull feeback on this document, Daniel Karrenberg, 5. Security Considerations Some transport options have different risk profiles and as their use increases, their use may be curtailed by the operator as a means of protecting their infrastructure. 6. IANA Considerations: This document does not have any IANA actions. 7. References 7.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [MATT] Larson, M. and D. Blacka, "Port and Message ID Analysis of Resolvers Querying .com/.net Name Servers", Sept 2008. Author's Address Bill Manning EP.NET PO 12317 Marina del Rey, CA 90295 From owner-namedroppers@ops.ietf.org Thu Aug 27 08:32:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223223A6E4D; Thu, 27 Aug 2009 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 ui2mLNYGIw5P; Thu, 27 Aug 2009 08:32:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4992C3A6D39; Thu, 27 Aug 2009 08:32:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MggsF-000DB0-9J for namedroppers-data0@psg.com; Thu, 27 Aug 2009 15:26:51 +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 1MggsB-000DAO-35 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 15:26:48 +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 D369F2FE8CDD for ; Thu, 27 Aug 2009 15:26:45 +0000 (UTC) Date: Thu, 27 Aug 2009 11:26:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090827152640.GA7821@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Sun, Aug 23, 2009 at 11:32:30AM -0700, Paul Hoffman wrote: > > Please consider adopting this short document as a WG work item. The draft has inspired some significant discussion, and that is good; but it is important to remember that what we are deciding is still primarily whether the draft is to be a work item for this WG. I imagine that the strenuous debate indicates a willingness to review the draft, but it would be helpful if you stated where you stand on that exact question as well. Thanks, Andrew (for the Chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 27 08:41: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 B57843A6B25; Thu, 27 Aug 2009 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.866 X-Spam-Level: X-Spam-Status: No, score=-105.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kolVHG-B8rlo; Thu, 27 Aug 2009 08:41:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A05C03A67C0; Thu, 27 Aug 2009 08:41:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgh3F-000EpR-JB for namedroppers-data0@psg.com; Thu, 27 Aug 2009 15:38:13 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgh3B-000Eoh-6v for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 15:38:10 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 85A831C0213; Thu, 27 Aug 2009 17:38:08 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 80A131C0207; Thu, 27 Aug 2009 17:38:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 7EAA2A1D97F; Thu, 27 Aug 2009 17:38:08 +0200 (CEST) Date: Thu, 27 Aug 2009 17:38:08 +0200 From: Stephane Bortzmeyer To: Paul Hoffman Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090827153808.GA5343@nic.fr> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 23, 2009 at 11:32:30AM -0700, Paul Hoffman wrote=20 a message of 20 lines which said: > Please consider adopting this short document as a WG work item. I believe it would be a good idea to have the WG work on this document. In the next years, there will certainly have non-futile demands for new algorithms (such as elliptic curve algorithms). I'm not yet stable about some ideas like the allocation of temporary identifiers for testing but it does not prevent us to start working. I volunteer for review, too. --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKlqhgQTZHl5fW0kYRAqMVAKC1uBegCV/24jlCWUN1smb6h6pUIgCgrKAN 8nulnMGB35IHi9vqYY54Jz0= =YHS9 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-namedroppers@ops.ietf.org Thu Aug 27 09:16: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 A63863A68EB; Thu, 27 Aug 2009 09:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.991 X-Spam-Level: X-Spam-Status: No, score=-3.991 tagged_above=-999 required=5 tests=[AWL=0.504, 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 7IK9ir+TRr+Q; Thu, 27 Aug 2009 09:16:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4AD53A68FF; Thu, 27 Aug 2009 09:16:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mghae-000Jm7-To for namedroppers-data0@psg.com; Thu, 27 Aug 2009 16:12:44 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mghab-000JlT-Rf for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 16:12:43 +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 n7RGCadL088347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 09:12:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200908270641.n7R6f78T026596@drugs.dv.isc.org> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> Date: Thu, 27 Aug 2009 09:12:35 -0700 To: Mark Andrews , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 4:41 PM +1000 8/27/09, Mark Andrews wrote: >If a validator doesn't understand any of the algorithms then the zone >is treated as insecure. My apologies for using the term "bogus" in my earlier responses. You are right, we are talking about zones being insecure. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Aug 27 10:04: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 C0BB328C212; Thu, 27 Aug 2009 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.005 X-Spam-Level: X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[AWL=0.490, 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 b2r36sxr6UR1; Thu, 27 Aug 2009 10:04:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17A453A69EC; Thu, 27 Aug 2009 10:04:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgiJW-0000js-CP for namedroppers-data0@psg.com; Thu, 27 Aug 2009 16:59:06 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgiJT-0000j9-1Y for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 16:59:04 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7RGx0Pj091481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Aug 2009 09:59:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> Date: Thu, 27 Aug 2009 09:58:58 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] Updated: Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have updated the draft to include clarifications from the recent thread. The new version is at: http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-01.txt The added text is: 3. Expectations For Implementations It is important to note that, according to RFC 4034, DNSSEC implementations are not expected to include all of the algorithms listed in the IANA registry; in fact, RFC 4034 and the IANA registry list an algorithm that implementations should not include. This document does nothing to change the expectation that there will be items listed in the IANA registry that need not be (and in some cases, should not be) included in all implementations. There are many reasons why a DNSSEC implementation might not include one or more of the algorithms listed, even those on Standards Track. In order to be compliant with the RFC 4034, an implementation only needs to implement the algorithms listed as mandatory to implement in the that standard, or updates to that standard. This document does nothing to change the list of mandatory to implement algorithms in RFC 4034. I hope this helps allay fears and repeat what is already in RFC 4034 that remains unchanged. I also hope it helps gain interest in this becoming a WG document. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Aug 27 10:54: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 D439B28C23B; Thu, 27 Aug 2009 10:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 t5XhVB8pjyDF; Thu, 27 Aug 2009 10:54:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F217528C152; Thu, 27 Aug 2009 10:54:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgj7y-000B7J-VS for namedroppers-data0@psg.com; Thu, 27 Aug 2009 17:51:14 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgj7v-000B6Y-7v for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 17:51:12 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Aug 2009 10:51:10 -0700 Received: from TK5EX14MBXC121.redmond.corp.microsoft.com ([169.254.1.194]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Thu, 27 Aug 2009 10:51:10 -0700 From: Dan Simon To: Paul Hoffman , Olafur Gudmundsson , Basil Dolmatov CC: "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJp+vjWQ+n6H+NECDFwRoOC3URZC5BdAQ Date: Thu, 27 Aug 2009 17:51:08 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05E98C@TK5EX14MBXC121.redmond.corp.microsoft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Paul Hoffman Sent: Wednesday, August 26, 2009 3:08 PM >The out-of-band feedback in DNSSEC ("why is your domain bogus?") will be i= nfinitely more effective than the out-of-band feedback for signature failur= es in TLS or S/MIME. Really: the market will truly count here. DNSSEC is supposed to secure DNS, and DNS is supposed to be a single, globa= l name resolution infrastructure service for the Internet--not an individua= l competitor in a broad free market for Internet name resolution services. = That's why there's so much political involvement in root administration, c= cTLD management, and DNSSEC--including by countries that want their preferr= ed algorithms used for DNS record signatures. Nobody's making a big deal a= bout what algorithms are used by the umpteenth CA to set itself up for busi= ness signing SSL/TLS certificates. But with DNSSEC it's different, because= there's only one DNS. Dan Simon Microsoft Corp. From owner-namedroppers@ops.ietf.org Thu Aug 27 10:56: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 5A70228C2A1; Thu, 27 Aug 2009 10:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 RvtVoOo304q5; Thu, 27 Aug 2009 10:56:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55E8928C23E; Thu, 27 Aug 2009 10:56:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgj7U-000B21-S3 for namedroppers-data0@psg.com; Thu, 27 Aug 2009 17:50:44 +0000 Received: from [131.107.115.212] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgj7R-000B0w-5E for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 17:50:42 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Aug 2009 10:50:39 -0700 Received: from TK5EX14MBXC121.redmond.corp.microsoft.com ([169.254.1.194]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Thu, 27 Aug 2009 10:50:39 -0700 From: Dan Simon To: Paul Hoffman , Andrew Sullivan , "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJmY1xokPxgQonU+NW9nS8wsNDpC4qaug Date: Thu, 27 Aug 2009 17:50:37 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.micros oft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Wednesday, August 26, 2009 8:59 AM [snip] >But, more importantly, the supposed government *does not need an RFC today= *. They could demand that their zones are signed with DNSSEC algorithm 254 = and an OID that is controlled by the government. We already allow that in t= he DNSSEC standard.=20 Great--so there's no need for your draft, then. Right? >>Again, what conceivable benefit does the DNSSEC community stand to get in= return for that heightened risk? >The benefit of better interoperability for algorithms that for whatever re= ason could not be on standards track. This is the same benefit that other I= ETF security protocols have been using for over a decade. How does your draft achieve "better interoperability" for such algorithms, = given the already-existing solution you described above? The only improvem= ent your draft offers, as far as I can tell, is precisely the one I describ= ed: the imprimatur of inclusion in the DNSSEC standard, along with an assi= gned IANA algorithm number, would encourage and facilitate wider deployment= of those "algorithms that for whatever reason could not be on standards tr= ack". And in your draft, you're quite specific about what "for whatever re= ason" means: government-promoted algorithms with insufficient expert evalu= ation, and IPR-encumbered algorithms. I don't see why anyone would want th= is WG to alter the DNSSEC standard for no other purpose than to make it a b= etter vehicle through which to promote the deployment of unevaluated and/or= IPR-encumbered algorithms. Dan Simon Microsoft Corp. =20 From owner-namedroppers@ops.ietf.org Thu Aug 27 11:08: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 B41E03A691A; Thu, 27 Aug 2009 11:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-0.896, 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 oW+l13J3J5H0; Thu, 27 Aug 2009 11:08:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0315928C11B; Thu, 27 Aug 2009 11:07:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjJZ-000DYT-49 for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:03:13 +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 1MgjJV-000DXk-4S for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:03: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 AE72A2FE8CDD for ; Thu, 27 Aug 2009 18:03:07 +0000 (UTC) Date: Thu, 27 Aug 2009 14:03:05 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090827180305.GK7821@shinkuro.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 27, 2009 at 05:50:37PM +0000, Dan Simon wrote: > Great--so there's no need for your draft, then. Right? I should note that the draft was the result of discussion at the Stockholm DNSEXT meeting; the Chairs asked for an inital draft, and Paul volunteered. We Chairs have heard several requests lately to alter the current rules about assigning algorithm identifiers. Note that the RSA/SHA2 effort has been somewhat frustrated by the difficulty of getting adequate WG review, our process rules, and so on. That state of affairs means (among other things) that discussion of using SHA-256 to sign the root from the beginning runs immediately into the simple problem that there are no interoperating implementations today, because the code point doesn't exist. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 27 11:31: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 E523E3A69B2; Thu, 27 Aug 2009 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=0.478, 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 9D8we3OacU39; Thu, 27 Aug 2009 11:31:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E34103A6C24; Thu, 27 Aug 2009 11:31:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjgy-000GhS-5c for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:27:24 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjgu-000Ggy-FO for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:27:22 +0000 Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7RIRGJ5096775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 11:27:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.micros oft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.micros oft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.micros oft.com> Date: Thu, 27 Aug 2009 11:27:12 -0700 To: Dan Simon , Andrew Sullivan , "namedroppers@ops.ietf.org" From: Paul Hoffman Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 5:50 PM +0000 8/27/09, Dan Simon wrote: >From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >Sent: Wednesday, August 26, 2009 8:59 AM > >[snip] > >>But, more importantly, the supposed government *does not need an RFC today*. They could demand that their zones are signed with DNSSEC algorithm 254 and an OID that is controlled by the government. We already allow that in the DNSSEC standard. > >Great--so there's no need for your draft, then. Right? If you don't care about interoperability, that correct. Many of us do care about it, however. That's why IANA exists. > >>Again, what conceivable benefit does the DNSSEC community stand to get in return for that heightened risk? > >>The benefit of better interoperability for algorithms that for whatever reason could not be on standards track. This is the same benefit that other IETF security protocols have been using for over a decade. > >How does your draft achieve "better interoperability" for such algorithms, given the already-existing solution you described above? The IANA registry would contain an accurate view of the algorithms that are documented in RFCs. > The only improvement your draft offers, as far as I can tell, is precisely the one I described: the imprimatur of inclusion in the DNSSEC standard, along with an assigned IANA algorithm number, would encourage and facilitate wider deployment of those "algorithms that for whatever reason could not be on standards track". As I stated before, we disagree on the "imprimatur" of being included in a registry. The imprimatur, if any, comes from the standards level of the algorithm and the amount of deployment. > And in your draft, you're quite specific about what "for whatever reason" means: government-promoted algorithms with insufficient expert evaluation, and IPR-encumbered algorithms. I don't see why anyone would want this WG to alter the DNSSEC standard for no other purpose than to make it a better vehicle through which to promote the deployment of unevaluated and/or IPR-encumbered algorithms. Nor do I: that's why the document doesn't say that. You made that up yourself. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Aug 27 11:36: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 AC0AA28C317; Thu, 27 Aug 2009 11:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 eUR499T8203z; Thu, 27 Aug 2009 11:36:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C206E28C2FD; Thu, 27 Aug 2009 11:36:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjmH-000HT8-4v for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:32:53 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjmD-000HS6-L8 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:32:51 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Aug 2009 11:32:49 -0700 Received: from TK5EX14MBXC121.redmond.corp.microsoft.com ([169.254.1.194]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Thu, 27 Aug 2009 11:32:48 -0700 From: Dan Simon To: Andrew Sullivan , "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJ0FvHd9LOb9CYkuEa7TlFVVmTJC6NNLQ Date: Thu, 27 Aug 2009 18:32:47 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05EA15@TK5EX14MBXC121.redmond.corp.microsoft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> In-Reply-To: <20090827180305.GK7821@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Thanks for the clarification, Andrew. I have no objection to a draft that = clarifies the WG's procedure for adding new algorithms to the DNSSEC algori= thm list, if its purpose is to address the problems facing efforts to add n= ew, well-vetted, widely deployable algorithms as the currently popular algo= rithms gradually become more suspect. I just don't see the need for a draf= t whose primary stated purpose is to ease the incorporation of unevaluated = and/or IPR-encumbered algorithms into DNSSEC. Dan Simon Microsoft Corp. -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Andrew Sullivan Sent: Thursday, August 27, 2009 11:03 AM To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNS= SEC On Thu, Aug 27, 2009 at 05:50:37PM +0000, Dan Simon wrote: > Great--so there's no need for your draft, then. Right? I should note that the draft was the result of discussion at the Stockholm DNSEXT meeting; the Chairs asked for an inital draft, and Paul volunteered. We Chairs have heard several requests lately to alter the current rules about assigning algorithm identifiers. =20 Note that the RSA/SHA2 effort has been somewhat frustrated by the difficulty of getting adequate WG review, our process rules, and so on. That state of affairs means (among other things) that discussion of using SHA-256 to sign the root from the beginning runs immediately into the simple problem that there are no interoperating implementations today, because the code point doesn't exist. Best regards, A --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 27 11:38: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 07F723A6D9A; Thu, 27 Aug 2009 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=0.064, 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 3HMW4cR5NQBP; Thu, 27 Aug 2009 11:38:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCD0C28C1EF; Thu, 27 Aug 2009 11:37:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjng-000HpZ-Ju for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:34:20 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjnc-000Hof-OK for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:34:18 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id B35571542837 for ; Thu, 27 Aug 2009 19:34:13 +0100 (BST) Message-Id: From: Jim Reid To: dnsext WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] draft-hoffman-dnssec-alg-allocation Date: Thu, 27 Aug 2009 19:34:13 +0100 X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have read the latest version of this draft and support it being adopted as a work item by the WG. From owner-namedroppers@ops.ietf.org Thu Aug 27 11:38: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 C85943A6D9A; Thu, 27 Aug 2009 11:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=0.061, 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 mko4oC0AyLK0; Thu, 27 Aug 2009 11:38:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D81AB3A6B93; Thu, 27 Aug 2009 11:38:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjo9-000Hue-6W for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:34:49 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjo3-000Ht6-Te for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:34:45 +0000 Received: from [192.168.1.10] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 8207AC2DB2; Thu, 27 Aug 2009 19:34:39 +0100 (BST) Date: Thu, 27 Aug 2009 19:34:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com, Andrew Sullivan cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Editor needed Message-ID: <49FE02E45D12846B1BE861E2@nimrod.home> In-Reply-To: <20090827142630.GA14431@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 27 August 2009 14:26:30 +0000 bmanning@vacation.karoshi.com wrote: > 1 Introduction. This seems to be the only use of the word "MUST". It says "all transport options MUST/need to be supported". "all transport options" could include more than TCP/UDP (see previous paragraph "may be ported to use other transports in the future"). Why not just say, as a stand alone paragraph: "DNS servers MUST support both UDP and TCP transports". > 2.1. UDP vs TCP for DNS messages As this section is already stating what is (at least to us) obvious, you might as well enumerate some other factors: TCP transport will in general result in more latency as more packets are exchanged prior to the party issuing the query receiving an answer. TCP transport may perform better when the answer expected is large, as UDP transport may require fragmentation to be supported, and poorly implemented or configured middleboxes may drop UDP fragments. It is harder for a third party to spoof answers where TCP is used when compared to UDP. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 27 11:45: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 927EB3A6927; Thu, 27 Aug 2009 11:45:29 -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=-0.105, 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 opcH2l1aI4tK; Thu, 27 Aug 2009 11:45:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACB1D3A68BC; Thu, 27 Aug 2009 11:45:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjvW-000J2L-GC for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:42:26 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjvR-000J1V-N3 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:42:24 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 58CF957097; Thu, 27 Aug 2009 14:42:20 -0400 (EDT) Date: Thu, 27 Aug 2009 14:42:19 -0400 (EDT) From: Paul Wouters To: Paul Hoffman cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Updated: Cryptographic Algorithm Identifier Allocation for DNSSEC In-Reply-To: Message-ID: References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 27 Aug 2009, Paul Hoffman wrote: > I have updated the draft to include clarifications from the recent thread. The new version is at: > > http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-01.txt Looks good to me. One minor point I was thinking about. Since we briefly saw a proposal that would suggest a crypto preference based on the order/number of the algorithm, and saw that most people did not like that implication, perhaps we can explicitely state that the order of algorithms in the registry does not signify or imply cryptographic strength or preference. Paul From owner-namedroppers@ops.ietf.org Thu Aug 27 12:46: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 E80473A6BFD; Thu, 27 Aug 2009 12:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.647 X-Spam-Level: ** X-Spam-Status: No, score=2.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzFokXBtcAqu; Thu, 27 Aug 2009 12:46:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F224E3A6A10; Thu, 27 Aug 2009 12:46:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgkrA-0005NB-Ap for namedroppers-data0@psg.com; Thu, 27 Aug 2009 19:42:00 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgkr5-0005Km-PC for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 19:41:57 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 207DC3EC4D; Thu, 27 Aug 2009 23:41:53 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CiYSPVt-pdSO; Thu, 27 Aug 2009 23:41:52 +0400 (MSD) Received: from [192.168.63.201] (ppp83-237-112-151.pppoe.mtu-net.ru [83.237.112.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 943B83EC48; Thu, 27 Aug 2009 23:41:47 +0400 (MSD) Message-ID: <4A96E17A.8060507@cryptocom.ru> Date: Thu, 27 Aug 2009 23:41:46 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Wouters CC: Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: [dnsext] Updated: Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Wouters пишет: > On Thu, 27 Aug 2009, Paul Hoffman wrote: > > > I have updated the draft to include clarifications from the recent > > thread. The new version is at: > > > > http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-01.txt > > > > Looks good to me. One minor point I was thinking about. Since we > briefly saw a proposal that would suggest a crypto preference based > on the order/number of the algorithm, and saw that most people did > not like that implication, perhaps we can explicitely state that the > order of algorithms in the registry does not signify or imply > cryptographic strength or preference. Seconded on that. dol@ > > Paul > From owner-namedroppers@ops.ietf.org Thu Aug 27 13:32: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 177FD3A6E91; Thu, 27 Aug 2009 13:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXN+T646kAXz; Thu, 27 Aug 2009 13:32:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D97ED3A68EB; Thu, 27 Aug 2009 13:32:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MglZk-000HBg-Hg for namedroppers-data0@psg.com; Thu, 27 Aug 2009 20:28:04 +0000 Received: from [209.86.89.67] (helo=elasmtp-scoter.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MglZf-000HAw-0u for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 20:28:02 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Mu4bOfdYNDknnMiH8sL9Tv0sKacAb5Ssh1A126Z/uxn5OfwTgK9IqcStO6xAUVem; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MglZB-0004EE-M1; Thu, 27 Aug 2009 16:27:29 -0400 Received: from 209.44.32.166 by webmail.earthlink.net with HTTP; Thu, 27 Aug 2009 16:27:29 -0400 Message-ID: <20344856.1251404849649.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Thu, 27 Aug 2009 16:27:29 -0400 (EDT) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Paul Hoffman Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Cc: Olafur Gudmundsson , Basil Dolmatov , Dan Simon , Gordon Lennox , "namedroppers@ops.ietf.org WG" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688e23c5bdd1b2d72c4885290b944848c1d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Patrik and all, I think th opposite is true. We cannot risk having non-interoperability because any entity prefers to use it's own crypto algorithm. There may be good reason for them to do so from their point of view. -----Original Message----- >From: Patrik F=C3=A4ltstr=C3=B6m >Sent: Aug 27, 2009 12:13 AM >To: Paul Hoffman >Cc: Olafur Gudmundsson , Basil Dolmatov ,= Dan Simon , Gordon Lennox , "namedroppers@ops.ietf.org WG" >Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for = DNSSEC > >On 27 aug 2009, at 00.08, Paul Hoffman wrote: > >> The out-of-band feedback in DNSSEC ("why is your domain bogus?") =20 >> will be infinitely more effective than the out-of-band feedback for =20 >> signature failures in TLS or S/MIME. Really: the market will truly =20 >> count here. > >The feedback will not be "why is your domain bogus". Your feedback, =20 >when you try to access a website, and you can not, is to call your own =20 >ISP and say "why is your DNS server broken". And the ISP then have two =20 >choices: Bite their tongue and calm the customer down, or stop =20 >verifying DNSSEC signed responses. > >We can _not_ risk having non-interoperability of DNSSEC globally by =20 >having everyone picking their own crypto algorithm. > > Patrik > Regards, =20 Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 294k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y 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] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.co= m Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Thu Aug 27 14:54: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 AE3673A6E52; Thu, 27 Aug 2009 14:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 3zKZaeUknSm8; Thu, 27 Aug 2009 14:54:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA1413A6DF9; Thu, 27 Aug 2009 14:54:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgmpj-000FDV-2Z for namedroppers-data0@psg.com; Thu, 27 Aug 2009 21:48:39 +0000 Received: from [206.190.36.79] (helo=smtp101.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgmpf-000FCE-Hx for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 21:48:37 +0000 Received: (qmail 70715 invoked from network); 27 Aug 2009 21:48:31 -0000 Received: from unknown (HELO ?192.168.1.239?) (thierry.moreau@209.148.165.15 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 27 Aug 2009 21:48:31 -0000 X-YMail-OSG: O5HbkWIVM1lJIHHfDSgKEsZ.J7Hud9tGx9H1RyX.79SIUXcL46eiHmgXScdyb64uYA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96C6BD.4080108@connotech.com> Date: Thu, 27 Aug 2009 13:47:41 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Paul Hoffman CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Hoffman wrote: > At 4:41 PM +1000 8/27/09, Mark Andrews wrote: > >> If a validator doesn't understand any of the algorithms then the zone >> is treated as insecure. >> > > My apologies for using the term "bogus" in my earlier responses. You are right, we are talking about zones being insecure. > > Thanks to Andrew and Paul for this clarification, which is indeed unambiguous from the DNSSEC protocol and security design. So, the question is whether the DNSSEC wg should work on a document that facilitates the allocation of algorithm identifiers which, once allocated, are potentially used, either by themselves (leading to the "insecure" validation status in the case of slow adoption, despite the zone being DNSSEC compliant) or in parallel with established algorithms (leading to larger DNS responses). My answer is no, i.e. the wg should indicate that algorithm homogeneity is important to DNSSEC overall security services and thus standards-track RFC is the appropriate IANA criteria. No need to add a wg work item for to reach this wg position. Going back to the "insecure" status reported by a DNSSEC validator not supporting a newcomer algorithm, this leads to an interesting hacker playground: once the users are trained to have greater confidence in DNSSEC compliant zones, here comes a new type of DNSSEC compliant zones, from which "insecure" status is returned from resolver "A" (say at home) while "secure" is observed from resolver "B" (at the office). Now try to explain the cause and subtle consequences to the user ... But be sure the hackers will see the gap in perceived vs actual DNS data integrity protection. (In essence, this is an instance or a variant of the very first failure root cause for digital signature applications: the relying party is ignoring the failure of a signature verification result.) Something in the security foundation of DNSSEC is shaken by this seemingly innocuous draft. - Thierry Morea From owner-namedroppers@ops.ietf.org Thu Aug 27 14: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 DFFF43A6E52; Thu, 27 Aug 2009 14:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-0.865, 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 D1Pl1YwcuF1B; Thu, 27 Aug 2009 14:58:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CE6B3A6DF9; Thu, 27 Aug 2009 14:58:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgmx4-000Iyb-LI for namedroppers-data0@psg.com; Thu, 27 Aug 2009 21:56:14 +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 1Mgmx0-000Iwa-Hw for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 21:56: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 3BAA32FE8CDD for ; Thu, 27 Aug 2009 21:56:09 +0000 (UTC) Date: Thu, 27 Aug 2009 17:56:07 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090827215607.GQ7821@shinkuro.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> <934623C28D56444CB073F90BC35244BB05EA15@TK5EX14MBXC121.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934623C28D56444CB073F90BC35244BB05EA15@TK5EX14MBXC121.redmond.corp.microsoft.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 27, 2009 at 06:32:47PM +0000, Dan Simon wrote: > Thanks for the clarification, Andrew. I have no objection to a > draft that clarifies the WG's procedure for adding new algorithms to > the DNSSEC algorithm list, if its purpose is to address the problems > facing efforts to add new, well-vetted, widely deployable algorithms > as the currently popular algorithms gradually become more suspect. So let's be even more clear: the proposal is to move the identifier assignment requirement from "standard required" to "RFC required". To expand on that, the current rule is that the WG come to an agreement to publish a standards-track RFC making the change. The new rule would allow any RFC published by any means to be enough to permit the assignment of an identifier. Now, the new identifier assignment regime would not require "well-vetted, widely deployable, &c." It is by no means plain to me, however, that the _current_ regime requires that either, since this WG is not full to the brim with cryptographers and therefore is not the WG one would ask about the suitability of a given algorithm for this or that purpose. I am neither claiming that the current procedure does or does not resulted in the well-vetted &c. algorithms. I am merely pointing out that there is no such formal requirement at the moment, since standards action by this WG does not entail such vetting &c. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 27 17:03: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 EE08F28C2EA; Thu, 27 Aug 2009 17:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 l4uq3+qapqLC; Thu, 27 Aug 2009 17:03:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 191C13A6E6B; Thu, 27 Aug 2009 17:03:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgors-0007GA-WB for namedroppers-data0@psg.com; Thu, 27 Aug 2009 23:59: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 1Mgoro-0007Cl-QK for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 23:58: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 0DB5AE6024; Thu, 27 Aug 2009 23:58:55 +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 n7RNwrvr038970; Fri, 28 Aug 2009 09:58:53 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908272358.n7RNwrvr038970@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Thu, 27 Aug 2009 14:03:05 -0400." <20090827180305.GK7821@shinkuro.com> Date: Fri, 28 Aug 2009 09:58:53 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20090827180305.GK7821@shinkuro.com>, Andrew Sullivan writes: > On Thu, Aug 27, 2009 at 05:50:37PM +0000, Dan Simon wrote: > > Great--so there's no need for your draft, then. Right? > > I should note that the draft was the result of discussion at the > Stockholm DNSEXT meeting; the Chairs asked for an inital draft, and > Paul volunteered. We Chairs have heard several requests lately to > alter the current rules about assigning algorithm identifiers. > > Note that the RSA/SHA2 effort has been somewhat frustrated by the > difficulty of getting adequate WG review, our process rules, and so > on. That state of affairs means (among other things) that discussion > of using SHA-256 to sign the root from the beginning runs immediately > into the simple problem that there are no interoperating > implementations today, because the code point doesn't exist. There is really nothing new in RSA/SHA2. It's just a code point. NSEC3 is already used in DNS. SHA2 is already used in DNS. RSA is already used in DNS. It was a bolt together exercise which took 1/2 a day, all it is waiting on is the code point. It would have taken less if we didn't cleanup some of the code at the same time to make adding new algorithms even easier. I really don't expect interoperability problems. This is like adding a new RR in terms of difficultly. If IANA wants to facilitate a interop test on a randomly choosen code point I'm sure that most of the vendors could supply test code relatitively easily with the usual sorts of caveats. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Aug 27 17:11: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 141083A6ABE; Thu, 27 Aug 2009 17:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=-4.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 Nj2r6FEWn9aF; Thu, 27 Aug 2009 17:11:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED47A3A68F7; Thu, 27 Aug 2009 17:11:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgozV-0008uY-OV for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:06:53 +0000 Received: from [192.52.233.69] (helo=mlbxsmtp3.harris.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgozR-0008tU-Vu for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:06:51 +0000 Received: from mail pickup service by mlbxsmtp3.harris.com with Microsoft SMTPSVC; Thu, 27 Aug 2009 19:59:09 -0400 Received: from mail pickup service by mlbxsmtp2.harris.com with Microsoft SMTPSVC; Thu, 27 Aug 2009 18:53:50 -0400 Received: from mlbefw2.harris.com ([192.52.233.80]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Aug 2009 14:37:23 -0400 Received: from psg.com (psg.com [147.28.0.62]) by mlbefw2.harris.com (BorderWare Security Platform) with ESMTP id 6544340A1910D1DA for ; Thu, 27 Aug 2009 14:37:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjmH-000HT8-4v for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:32:53 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgjmD-000HS6-L8 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:32:51 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Aug 2009 11:32:49 -0700 Received: from TK5EX14MBXC121.redmond.corp.microsoft.com ([169.254.1.194]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Thu, 27 Aug 2009 11:32:48 -0700 From: Dan Simon To: Andrew Sullivan , "namedroppers@ops.ietf.org" Subject: RE: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Topic: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Thread-Index: AQHKJ0FvHd9LOb9CYkuEa7TlFVVmTJC6NNLQ Date: Thu, 27 Aug 2009 18:32:47 +0000 Message-ID: <934623C28D56444CB073F90BC35244BB05EA15@TK5EX14MBXC121.redmond.corp.microsoft.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> In-Reply-To: <20090827180305.GK7821@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: X-STA-Metric: 0 (engine=029) X-STA-NotSpam: wrote: spec:mix:message wrote message----- -----original X-STA-Spam: chairs draft, draft 27, clarification, X-BTI-AntiSpam: score:0,sta:0/029,dcc:passed,dnsbl:passed,sw:passed,bsn:10/passed,spf:off,dk:off,pbmf:accept/36,ipr:1/10,trusted:no,ts:no,bs:no,ubl:passed X-OriginalArrivalTime: 27 Aug 2009 18:37:23.0973 (UTC) FILETIME=[6B4A2B50:01CA2745] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Thanks for the clarification, Andrew. I have no objection to a draft that = clarifies the WG's procedure for adding new algorithms to the DNSSEC algori= thm list, if its purpose is to address the problems facing efforts to add n= ew, well-vetted, widely deployable algorithms as the currently popular algo= rithms gradually become more suspect. I just don't see the need for a draf= t whose primary stated purpose is to ease the incorporation of unevaluated = and/or IPR-encumbered algorithms into DNSSEC. Dan Simon Microsoft Corp. -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Andrew Sullivan Sent: Thursday, August 27, 2009 11:03 AM To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNS= SEC On Thu, Aug 27, 2009 at 05:50:37PM +0000, Dan Simon wrote: > Great--so there's no need for your draft, then. Right? I should note that the draft was the result of discussion at the Stockholm DNSEXT meeting; the Chairs asked for an inital draft, and Paul volunteered. We Chairs have heard several requests lately to alter the current rules about assigning algorithm identifiers. =20 Note that the RSA/SHA2 effort has been somewhat frustrated by the difficulty of getting adequate WG review, our process rules, and so on. That state of affairs means (among other things) that discussion of using SHA-256 to sign the root from the beginning runs immediately into the simple problem that there are no interoperating implementations today, because the code point doesn't exist. Best regards, A --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From soapiestid3@ispcymru.com Thu Aug 27 17:32: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 975673A6974; Thu, 27 Aug 2009 17:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.773 X-Spam-Level: X-Spam-Status: No, score=-44.773 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, 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, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_22B61=3.651] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42DxTz3uSz6n; Thu, 27 Aug 2009 17:32:02 -0700 (PDT) Received: from adsl11-160.qualitynet.net (adsl11-160.qualitynet.net [195.226.241.160]) by core3.amsl.com (Postfix) with ESMTP id 291903A6822; Thu, 27 Aug 2009 17:32:01 -0700 (PDT) Received: from 195.226.241.160 by mx.murphx.net; Fri, 28 Aug 2009 03:32:06 +0300 Message-ID: <000d01ca2776$f8aa1240$6400a8c0@soapiestid3> From: Deane Guerra To: Subject: Why be the odd 1 out Date: Fri, 28 Aug 2009 03:32:06 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2776.F8AA1240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA2776.F8AA1240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Enhance your life with the worlds # 1 Miracle food.   Lose wieght without dieting , Acai Berry.=20 =20 Break in now =20 best regards =20 =20 ------=_NextPart_000_0007_01CA2776.F8AA1240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Enh= ance your life with the worlds # 1 Miracle food.
&n= bsp;
Lose wieght without dieting , Acai Berry.
<= A=20 href=3D"http://iodpwpie.cn">Break in now
best regards
------=_NextPart_000_0007_01CA2776.F8AA1240-- From owner-namedroppers@ops.ietf.org Thu Aug 27 17:33: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 8196D3A6974; Thu, 27 Aug 2009 17:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.338 X-Spam-Level: * X-Spam-Status: No, score=1.338 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_CPE=0.979, HOST_MISMATCH_COM=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv3mDhjI2FuZ; Thu, 27 Aug 2009 17:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1E203A688D; Thu, 27 Aug 2009 17:33:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpLS-000D8z-DS for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:29: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 1MgpLN-000D8O-Hu for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:29:31 +0000 Received: from [192.168.1.253] (cpe-071-070-169-094.nc.res.rr.com [71.70.169.94]) (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 0CE93E601C for ; Fri, 28 Aug 2009 00:29:28 +0000 (UTC) (envelope-from aclegg@isc.org) Message-ID: <4A9724E7.2070108@isc.org> Date: Thu, 27 Aug 2009 20:29:27 -0400 From: Alan Clegg Organization: Internet Systems Consortium User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] Presentation on DNSSEC that Google brought to my attention X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have a google alert set for "DNSSEC" and was rather interested by the document that it brought to my attention today. Good points brought up (one at my expense, I must say) on a number of things, but some minor errors (particularly page 64). Thought folks might be interested. http://cr.yp.to/talks/2009.08.10/slides.pdf AlanC From owner-namedroppers@ops.ietf.org Thu Aug 27 17:35: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 2A0653A6CFF; Thu, 27 Aug 2009 17:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-1.564, 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 i3Mgzdpp3R6z; Thu, 27 Aug 2009 17:35:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30F183A6974; Thu, 27 Aug 2009 17:35:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpNu-000DTs-R6 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:32:06 +0000 Received: from [192.52.233.70] (helo=mlbxsmtp1.harris.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpNq-000DSP-P6 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:32:05 +0000 Received: from mail pickup service by mlbxsmtp1.harris.com with Microsoft SMTPSVC; Thu, 27 Aug 2009 20:32:01 -0400 Received: from mlbefw2.harris.com ([192.52.233.80]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Aug 2009 13:06:15 -0400 Received: from psg.com (psg.com [147.28.0.62]) by mlbefw2.harris.com (BorderWare Security Platform) with ESMTP id 80C9352919228D33 for ; Thu, 27 Aug 2009 13:06:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgiJW-0000js-CP for namedroppers-data0@psg.com; Thu, 27 Aug 2009 16:59:06 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgiJT-0000j9-1Y for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 16:59:04 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7RGx0Pj091481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Aug 2009 09:59:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> Date: Thu, 27 Aug 2009 09:58:58 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] Updated: Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: X-STA-Metric: 3 (engine=029) X-STA-NotSpam: thread rfc algorithms url:txt implementations X-STA-Spam: helps spec:longlines hope cases expected X-BTI-AntiSpam: score:0,sta:3/029,dcc:passed,dnsbl:passed,sw:passed,bsn:10/passed,spf:off,dk:off,pbmf:none,ipr:1/10,trusted:no,ts:no,bs:no,ubl:passed X-OriginalArrivalTime: 27 Aug 2009 17:06:15.0109 (UTC) FILETIME=[AF97BF50:01CA2738] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have updated the draft to include clarifications from the recent thread. The new version is at: http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-01.txt The added text is: 3. Expectations For Implementations It is important to note that, according to RFC 4034, DNSSEC implementations are not expected to include all of the algorithms listed in the IANA registry; in fact, RFC 4034 and the IANA registry list an algorithm that implementations should not include. This document does nothing to change the expectation that there will be items listed in the IANA registry that need not be (and in some cases, should not be) included in all implementations. There are many reasons why a DNSSEC implementation might not include one or more of the algorithms listed, even those on Standards Track. In order to be compliant with the RFC 4034, an implementation only needs to implement the algorithms listed as mandatory to implement in the that standard, or updates to that standard. This document does nothing to change the list of mandatory to implement algorithms in RFC 4034. I hope this helps allay fears and repeat what is already in RFC 4034 that remains unchanged. I also hope it helps gain interest in this becoming a WG document. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Aug 27 17:49: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 8D6EA3A6B34; Thu, 27 Aug 2009 17:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.235 X-Spam-Level: X-Spam-Status: No, score=0.235 tagged_above=-999 required=5 tests=[AWL=0.108, 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 J4aY7d9hhJ18; Thu, 27 Aug 2009 17:49:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B35BA3A6E60; Thu, 27 Aug 2009 17:49:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpZV-000FvU-8R for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:44:05 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpZR-000FuN-G8 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:44:03 +0000 Received: by pxi8 with SMTP id 8so1471748pxi.9 for ; Thu, 27 Aug 2009 17:44:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.27.7 with SMTP id e7mr638979waj.10.1251420239560; Thu, 27 Aug 2009 17:43:59 -0700 (PDT) In-Reply-To: <4A9724E7.2070108@isc.org> References: <4A9724E7.2070108@isc.org> Date: Thu, 27 Aug 2009 17:43:59 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 27, 2009 at 5:29 PM, Alan Clegg wrote: > Good points brought up (one at my expense, I must say) on a number of > things, but some minor errors (particularly page 64). Out of curiosity, what's the error? E.g., if you run "dig +dnssec www.dempsky.org @a0.org.afilias-nst.info", how does a validating resolver reject forgeries? The .org name servers aren't currently signing the NS or A record sets, as far as I can tell. From owner-namedroppers@ops.ietf.org Thu Aug 27 17:49: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 C4F2B3A68E4; Thu, 27 Aug 2009 17:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-0.389, 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 N609P-TH11Wy; Thu, 27 Aug 2009 17:49:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C65143A69D7; Thu, 27 Aug 2009 17:49:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgpb0-000GES-JE for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:45:38 +0000 Received: from [192.52.233.69] (helo=mlbxsmtp3.harris.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgpav-000GDL-LY for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:45:35 +0000 Received: from mail pickup service by mlbxsmtp3.harris.com with Microsoft SMTPSVC; Thu, 27 Aug 2009 20:32:10 -0400 Received: from mlbefw2.harris.com ([192.52.233.80]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Aug 2009 11:33:13 -0400 Received: from psg.com (psg.com [147.28.0.62]) by mlbefw2.harris.com (BorderWare Security Platform) with ESMTP id CBFA36281D02EF4A for ; Thu, 27 Aug 2009 11:33:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MggsF-000DB0-9J for namedroppers-data0@psg.com; Thu, 27 Aug 2009 15:26:51 +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 1MggsB-000DAO-35 for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 15:26:48 +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 D369F2FE8CDD for ; Thu, 27 Aug 2009 15:26:45 +0000 (UTC) Date: Thu, 27 Aug 2009 11:26:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090827152640.GA7821@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) List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: X-STA-Metric: 3 (engine=029) X-STA-NotSpam: wrote: -0700, wrote deciding header:In-Reply-To:1 X-STA-Spam: draft, item dear 2009 draft X-BTI-AntiSpam: score:0,sta:3/029,dcc:passed,dnsbl:passed,sw:passed,bsn:10/passed,spf:off,dk:off,pbmf:none,ipr:1/10,trusted:no,ts:no,bs:no,ubl:passed X-OriginalArrivalTime: 27 Aug 2009 15:33:13.0984 (UTC) FILETIME=[B0FBA800:01CA272B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Sun, Aug 23, 2009 at 11:32:30AM -0700, Paul Hoffman wrote: > > Please consider adopting this short document as a WG work item. The draft has inspired some significant discussion, and that is good; but it is important to remember that what we are deciding is still primarily whether the draft is to be a work item for this WG. I imagine that the strenuous debate indicates a willingness to review the draft, but it would be helpful if you stated where you stand on that exact question as well. Thanks, Andrew (for the Chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 27 17:49: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 6B72B3A68E4; Thu, 27 Aug 2009 17:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 CEoYDOa3YExe; Thu, 27 Aug 2009 17:49:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 785403A69D7; Thu, 27 Aug 2009 17:49:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpaR-000G8B-4V for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:45:03 +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 1MgpaN-000G6M-A7 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:45: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 63D52E6023; Fri, 28 Aug 2009 00:44: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 n7S0iskn039782; Fri, 28 Aug 2009 10:44:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908280044.n7S0iskn039782@drugs.dv.isc.org> To: Stephane Bortzmeyer Cc: Paul Hoffman , namedroppers@ops.ietf.org From: Mark Andrews References: <20090827153808.GA5343@nic.fr> Subject: Re: [dnsext] Re: Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Thu, 27 Aug 2009 17:38:08 +0200." <20090827153808.GA5343@nic.fr> Date: Fri, 28 Aug 2009 10:44:54 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20090827153808.GA5343@nic.fr>, Stephane Bortzmeyer writes: > > On Sun, Aug 23, 2009 at 11:32:30AM -0700, > Paul Hoffman wrote=20 > a message of 20 lines which said: > > > Please consider adopting this short document as a WG work item. > > I believe it would be a good idea to have the WG work on this > document. In the next years, there will certainly have non-futile > demands for new algorithms (such as elliptic curve algorithms). I'm > not yet stable about some ideas like the allocation of temporary > identifiers for testing but it does not prevent us to start working. > > I volunteer for review, too. I don't think we need test algorithm id's. Interop testing can be done by the testers choosing a unallocated algorithm amongst themselves for the duration of the test. Testbed implementations should never be used in production systems, this is not to say the testbed can't be in the public namespace, just that the servers are only being used to participate in the test. There really isn't the need for this to do lots of testing for new cryptographic hashes or public key cryptographic algorithms. It either works or it doesn't and most of that can be determined with a single implementation. The worst that will happen is that answers from the old testbed zones won't validate but no one will be looking up things in those zones anyway. We arn't doing cryptographic research. We are testing if we can pass all the information required to validate a RRset from a authoritative server to a validating resolver. i.e. are all the inputs the validator requires in the DNSKEY/RRSIG pair. This is not hard to check at the paper stage. Changing the fundementals of how DNSSEC works, like adding NSEC3 was required more work. If we need a test algorithm for this sort of work then we can request one if we need one. Mind you we got way without needing one for the NSEC3 testbeds. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Aug 27 17: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 537F63A69D7; Thu, 27 Aug 2009 17:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-1.527, 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 dYZVmR0-5nBX; Thu, 27 Aug 2009 17:50:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B6B03A68E4; Thu, 27 Aug 2009 17:50:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpbZ-000GM5-77 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:46:13 +0000 Received: from [192.52.233.69] (helo=mlbxsmtp3.harris.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgpbV-000GL3-Od for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:46:11 +0000 Received: from mail pickup service by mlbxsmtp3.harris.com with Microsoft SMTPSVC; Thu, 27 Aug 2009 20:32:25 -0400 Received: from mlbefw2.harris.com ([192.52.233.80]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Aug 2009 12:17:10 -0400 Received: from psg.com (psg.com [147.28.0.62]) by mlbefw2.harris.com (BorderWare Security Platform) with ESMTP id 853E34081901CB40 for ; Thu, 27 Aug 2009 12:17:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mghae-000Jm7-To for namedroppers-data0@psg.com; Thu, 27 Aug 2009 16:12:44 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mghab-000JlT-Rf for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 16:12:43 +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 n7RGCadL088347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 09:12:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200908270641.n7R6f78T026596@drugs.dv.isc.org> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> Date: Thu, 27 Aug 2009 09:12:35 -0700 To: Mark Andrews , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Content-Type: text/plain; charset="us-ascii" List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: X-STA-Metric: 0 (engine=029) X-STA-NotSpam: wrote: >if wrote >is algorithms X-STA-Spam: spec:longlines responses you are director X-BTI-AntiSpam: score:0,sta:0/029,dcc:passed,dnsbl:passed,sw:passed,bsn:10/passed,spf:off,dk:off,pbmf:none,ipr:1/10,trusted:no,ts:no,bs:no,ubl:passed X-OriginalArrivalTime: 27 Aug 2009 16:17:10.0564 (UTC) FILETIME=[D481D640:01CA2731] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 4:41 PM +1000 8/27/09, Mark Andrews wrote: >If a validator doesn't understand any of the algorithms then the zone >is treated as insecure. My apologies for using the term "bogus" in my earlier responses. You are right, we are talking about zones being insecure. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Aug 27 17:52: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 F00AE3A69D7; Thu, 27 Aug 2009 17:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=0.059, 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 y6MlfnMieMaX; Thu, 27 Aug 2009 17:52:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28E663A68E4; Thu, 27 Aug 2009 17:52:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgpdu-000Gri-6t for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:48:38 +0000 Received: from [192.52.233.69] (helo=mlbxsmtp3.harris.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgpdq-000Gqz-TC for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:48:36 +0000 Received: from mail pickup service by mlbxsmtp3.harris.com with Microsoft SMTPSVC; Thu, 27 Aug 2009 20:34:15 -0400 Received: from mlbefw1.harris.com ([192.52.233.75]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Aug 2009 14:39:18 -0400 Received: from psg.com (psg.com [147.28.0.62]) by mlbefw1.harris.com (BorderWare Security Platform) with ESMTP id 02D33629182DF972 for ; Thu, 27 Aug 2009 14:38:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjo9-000Hue-6W for namedroppers-data0@psg.com; Thu, 27 Aug 2009 18:34:49 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgjo3-000Ht6-Te for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 18:34:45 +0000 Received: from [192.168.1.10] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 8207AC2DB2; Thu, 27 Aug 2009 19:34:39 +0100 (BST) Date: Thu, 27 Aug 2009 19:34:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com, Andrew Sullivan cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Editor needed Message-ID: <49FE02E45D12846B1BE861E2@nimrod.home> In-Reply-To: <20090827142630.GA14431@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@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 List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: X-STA-Metric: 0 (engine=029) X-STA-NotSpam: wrote: (at configured packets dns X-STA-Spam: spoof enumerate 2009 +0000 expected X-BTI-AntiSpam: score:0,sta:0/029,dcc:passed,dnsbl:passed,sw:passed,bsn:10/passed,spf:off,dk:off,pbmf:none,ipr:1/10,trusted:no,ts:no,bs:no,ubl:passed X-OriginalArrivalTime: 27 Aug 2009 18:39:19.0005 (UTC) FILETIME=[AFDAA8D0:01CA2745] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 27 August 2009 14:26:30 +0000 bmanning@vacation.karoshi.com wrote: > 1 Introduction. This seems to be the only use of the word "MUST". It says "all transport options MUST/need to be supported". "all transport options" could include more than TCP/UDP (see previous paragraph "may be ported to use other transports in the future"). Why not just say, as a stand alone paragraph: "DNS servers MUST support both UDP and TCP transports". > 2.1. UDP vs TCP for DNS messages As this section is already stating what is (at least to us) obvious, you might as well enumerate some other factors: TCP transport will in general result in more latency as more packets are exchanged prior to the party issuing the query receiving an answer. TCP transport may perform better when the answer expected is large, as UDP transport may require fragmentation to be supported, and poorly implemented or configured middleboxes may drop UDP fragments. It is harder for a third party to spoof answers where TCP is used when compared to UDP. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 27 18: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 336733A68FF; Thu, 27 Aug 2009 18:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.638 X-Spam-Level: * X-Spam-Status: No, score=1.638 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_CPE=0.979, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_21=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCJcgMePkJzd; Thu, 27 Aug 2009 18:05:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 436533A68F8; Thu, 27 Aug 2009 18:05:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgpo9-000Iz1-4j for namedroppers-data0@psg.com; Fri, 28 Aug 2009 00:59:13 +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 1Mgpo5-000Iy6-9K for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 00:59:11 +0000 Received: from [192.168.1.253] (cpe-071-070-169-094.nc.res.rr.com [71.70.169.94]) (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 8B4ADE6023; Fri, 28 Aug 2009 00:59:08 +0000 (UTC) (envelope-from aclegg@isc.org) Message-ID: <4A972BDB.4060900@isc.org> Date: Thu, 27 Aug 2009 20:59:07 -0400 From: Alan Clegg Organization: Internet Systems Consortium User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Matthew Dempsky CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention References: <4A9724E7.2070108@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Matthew Dempsky wrote: > On Thu, Aug 27, 2009 at 5:29 PM, Alan Clegg wrote: >> Good points brought up (one at my expense, I must say) on a number of >> things, but some minor errors (particularly page 64). > > Out of curiosity, what's the error? E.g., if you run "dig +dnssec > www.dempsky.org @a0.org.afilias-nst.info", how does a validating > resolver reject forgeries? The .org name servers aren't currently > signing the NS or A record sets, as far as I can tell. Parental NS and glue records are never signed as they truly "exist" in the child zone. However, if you forge them, a correctly validating resolver will note the DS record in the parent and expect the actual zone to include the appropriate KSK. From there you validate ZSK and related signatures. You can't just "sidestep" by forging NS+A in parent. AlanC From owner-namedroppers@ops.ietf.org Thu Aug 27 18: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 18B503A6A9E; Thu, 27 Aug 2009 18:19:14 -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.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=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 ar-gk7RYFAdz; Thu, 27 Aug 2009 18:19:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 069113A6D27; Thu, 27 Aug 2009 18:19:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgq2G-000LaW-7p for namedroppers-data0@psg.com; Fri, 28 Aug 2009 01:13:48 +0000 Received: from [209.85.146.180] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgq2B-000LZr-Vy for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 01:13:46 +0000 Received: by wa-out-1112.google.com with SMTP id j37so325089waf.9 for ; Thu, 27 Aug 2009 18:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.27.7 with SMTP id e7mr678465waj.10.1251422022718; Thu, 27 Aug 2009 18:13:42 -0700 (PDT) In-Reply-To: <4A972BDB.4060900@isc.org> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> Date: Thu, 27 Aug 2009 18:13:42 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 27, 2009 at 5:59 PM, Alan Clegg wrote: > Parental NS and glue records are never signed as they truly "exist" in > the child zone. > > However, if you forge them, a correctly validating resolver will note > the DS record in the parent and expect the actual zone to include the > appropriate KSK. =A0From there you validate ZSK and related signatures. So as a sniffing attacker, I can't trick you into accepting signed bogus DS records (and so no bogus records in the child zone), but I could forge a million responses, each with different bogus NS and A records. How does the client handle this? Just give up? > You can't just "sidestep" by forging NS+A in parent. You can until registrars allow you to add DS records. I notice isc.org has DS records, but I just checked GoDaddy, and I couldn't figure out how to add them for dempsky.org. (Maybe I'd have to transfer to another registrar?) From owner-namedroppers@ops.ietf.org Thu Aug 27 18:59: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 5D9503A67B4; Thu, 27 Aug 2009 18:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 M+Sz7vmqLT4d; Thu, 27 Aug 2009 18:59:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8617928C1EE; Thu, 27 Aug 2009 18:59:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgqfl-0005H6-Pf for namedroppers-data0@psg.com; Fri, 28 Aug 2009 01:54: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 1Mgqfi-0005GE-GQ for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 01:54: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 n7S1sX9i023894; Thu, 27 Aug 2009 18:54:33 -0700 (PDT) Cc: Nicholas Weaver , 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 v936) Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Date: Thu, 27 Aug 2009 18:54:32 -0700 References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 27, 2009, at 6:13 PM, Matthew Dempsky wrote: > On Thu, Aug 27, 2009 at 5:59 PM, Alan Clegg wrote: >> Parental NS and glue records are never signed as they truly "exist" >> in >> the child zone. >> >> However, if you forge them, a correctly validating resolver will note >> the DS record in the parent and expect the actual zone to include the >> appropriate KSK. From there you validate ZSK and related signatures. > > So as a sniffing attacker, I can't trick you into accepting signed > bogus DS records (and so no bogus records in the child zone), but I > could forge a million responses, each with different bogus NS and A > records. How does the client handle this? Just give up? As a sniffing attacker, frak-targeting DNS, just do direct TCP packet injection on the data protocol and be happy. From owner-namedroppers@ops.ietf.org Thu Aug 27 19:09: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 31ED43A6B7A; Thu, 27 Aug 2009 19:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.788 X-Spam-Level: * X-Spam-Status: No, score=1.788 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_CPE=0.979, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_21=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLuj0VUZxx1r; Thu, 27 Aug 2009 19:09:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C4F03A691A; Thu, 27 Aug 2009 19:09:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgqpZ-0008VJ-JL for namedroppers-data0@psg.com; Fri, 28 Aug 2009 02:04: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 1MgqpU-0008Sp-BD for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 02:04:43 +0000 Received: from [192.168.1.253] (cpe-071-070-169-094.nc.res.rr.com [71.70.169.94]) (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 8B21CE601E; Fri, 28 Aug 2009 02:04:39 +0000 (UTC) (envelope-from aclegg@isc.org) Message-ID: <4A973B36.8060708@isc.org> Date: Thu, 27 Aug 2009 22:04:38 -0400 From: Alan Clegg Organization: Internet Systems Consortium User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Matthew Dempsky CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Matthew Dempsky wrote: >> You can't just "sidestep" by forging NS+A in parent. > > You can until registrars allow you to add DS records. I notice > isc.org has DS records, but I just checked GoDaddy, and I couldn't > figure out how to add them for dempsky.org. (Maybe I'd have to > transfer to another registrar?) Correct. DNSSEC is not fully deployed yet. You won't find a registrar that can accept DS records for .ORG yet. AlanC From owner-namedroppers@ops.ietf.org Thu Aug 27 19: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 8C1BC28C1E6; Thu, 27 Aug 2009 19:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Hh-6zYaaeAnO; Thu, 27 Aug 2009 19:27:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEAD33A6B94; Thu, 27 Aug 2009 19:27:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgr6L-000CVd-Tl for namedroppers-data0@psg.com; Fri, 28 Aug 2009 02:22:05 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgr6I-000CUe-NE for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 02:22:04 +0000 Received: by pxi8 with SMTP id 8so1527111pxi.9 for ; Thu, 27 Aug 2009 19:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.103.27 with SMTP id f27mr694749wam.227.1251426121599; Thu, 27 Aug 2009 19:22:01 -0700 (PDT) In-Reply-To: References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> Date: Thu, 27 Aug 2009 19:22:01 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention From: Matthew Dempsky To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 27, 2009 at 6:54 PM, Nicholas Weaver wrote: > As a sniffing attacker, frak-targeting DNS, just do direct TCP packet > injection on the data protocol and be happy. Sure, higher-level protocols need to be made secure and available too. Making DNS secure and available is a first step towards that. From owner-namedroppers@ops.ietf.org Thu Aug 27 20:03: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 D9B683A6822; Thu, 27 Aug 2009 20:03: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=[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 YgteGcMz69ys; Thu, 27 Aug 2009 20:03:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDB7B3A6963; Thu, 27 Aug 2009 20:03:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgrg7-000Lus-Az for namedroppers-data0@psg.com; Fri, 28 Aug 2009 02:59: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 1Mgrfu-000Lt2-I9 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 02:58:53 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F0B41B447E for ; Fri, 28 Aug 2009 02:58:49 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention In-Reply-To: Your message of "Thu, 27 Aug 2009 22:04:38 -0400." <4A973B36.8060708@isc.org> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <4A973B36.8060708@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 28 Aug 2009 02:58:49 +0000 Message-ID: <54674.1251428329@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Thu, 27 Aug 2009 22:04:38 -0400 > From: Alan Clegg > > Correct. DNSSEC is not fully deployed yet. You won't find a registrar > that can accept DS records for .ORG yet. meanwhile, see for a workaround. From owner-namedroppers@ops.ietf.org Thu Aug 27 23:00: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 E9E5F3A6922; Thu, 27 Aug 2009 23:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.735 X-Spam-Level: X-Spam-Status: No, score=-7.735 tagged_above=-999 required=5 tests=[AWL=0.460, 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 APHfr4qCtYHQ; Thu, 27 Aug 2009 23:00:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C14C3A6890; Thu, 27 Aug 2009 23:00:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MguNV-000IMp-E8 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 05:52:01 +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 1MguNQ-000IMQ-7b for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 05:51:59 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAAKsMl0qQ/uCLe2dsb2JhbACbHAEBFiQGo3+IPgGQBAWEGQ X-IronPort-AV: E=Sophos;i="4.44,290,1249257600"; d="sig'?scan'208";a="48098840" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2009 05:51:54 +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 n7S5ps7t016845 for ; Fri, 28 Aug 2009 07:51:54 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7S5ps6i005064 for ; Fri, 28 Aug 2009 05:51:54 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:51:54 +0200 Received: from [192.168.1.64] ([10.61.84.186]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:51:53 +0200 Message-Id: <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "namedroppers@ops.ietf.org WG" In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-338-401089109" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Fri, 28 Aug 2009 07:51:52 +0200 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Aug 2009 05:51:53.0931 (UTC) FILETIME=[A543B1B0:01CA27A3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16852.004 X-TM-AS-Result: No--11.677100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2177; t=1251438714; x=1252302714; 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]=20Cryptographic=20Algorithm=20 Identifier=20Allocation=20for=20DNSSEC |Sender:=20; bh=oo8MLCrHthSJPrePBayrzt9bWzx0/uZgS9OvhZ0lErU=; b=ZXjtYquK/Z2JC50P5ydUrdVEq90Ml0CkjAC6rmYTYneE4NmGacNnfNp2BF poqY6x38NxJ/SuLfp5HnA2Dv6RbR0Ng4k4kHULYP0aSFMpHlZdDCrSANscd6 b90Qwp2TlE; 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-338-401089109 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 aug 2009, at 18.12, Paul Hoffman wrote: > At 4:41 PM +1000 8/27/09, Mark Andrews wrote: >> If a validator doesn't understand any of the algorithms then the zone >> is treated as insecure. > > My apologies for using the term "bogus" in my earlier responses. You > are right, we are talking about zones being insecure. I have rechecked the DNSSEC spec (thanks to some people on this list for offline help) and I see now the following four situations: 1. Query is for a signed domain, where the signature verifies correctly. Response is sent back to client with data. 2. Query is for a signed domain, where the algorithm is known, but the signature verification fails. Response is sent back, but the response has SERVFAIL status and no data. 3. Query is for a signed domain, where the algorithm is not known, and can because of that not be verified. A normal reply of the data, without the signatures and so on. Like it was an unsigned domain. 4. Query for signed domain, the algorithm not known. But the answer is forged. This forged answer is sent to the client without checking. Just like for an unsigned domain when the answer is forged. For me, this implies (specifically as I in this discussion screwed up and did not really understand at first) we need to write something about how important it is to agree on what crypto algorithms will be in use, or else we will get cases 3 and 4 "too often", when people believe case 1 or 2 are in use. Patrik --Apple-Mail-338-401089109 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) iD8DBQFKl3B4vHlR2X0luNwRAgSBAKCsHZrbP7xmEi56sjGnEwHe6S9TnACffFXN kUAoYXd9Ly17E0PAWdQpPxU= =k06v -----END PGP SIGNATURE----- --Apple-Mail-338-401089109-- From owner-namedroppers@ops.ietf.org Fri Aug 28 01:23: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 66B863A6859; Fri, 28 Aug 2009 01:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.414 X-Spam-Level: * X-Spam-Status: No, score=1.414 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, 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 b5j2qxo2zcNX; Fri, 28 Aug 2009 01:23:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D209A3A6EEE; Fri, 28 Aug 2009 01:22:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgwdg-000AGb-RM for namedroppers-data0@psg.com; Fri, 28 Aug 2009 08:16:52 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgwdb-000AFD-Tb for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 08:16:50 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 11D303EC55; Fri, 28 Aug 2009 12:16:45 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oXMDjHGKoRHH; Fri, 28 Aug 2009 12:16:44 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id D6E613EC50; Fri, 28 Aug 2009 12:16:44 +0400 (MSD) Message-ID: <4A97926C.3050103@cryptocom.ru> Date: Fri, 28 Aug 2009 12:16:44 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= CC: "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> In-Reply-To: <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Patrik Fältström пишет: > On 27 aug 2009, at 18.12, Paul Hoffman wrote: > >> At 4:41 PM +1000 8/27/09, Mark Andrews wrote: >>> If a validator doesn't understand any of the algorithms then the zone >>> is treated as insecure. >> >> My apologies for using the term "bogus" in my earlier responses. You >> are right, we are talking about zones being insecure. > > I have rechecked the DNSSEC spec (thanks to some people on this list for > offline help) and I see now the following four situations: > > 1. Query is for a signed domain, where the signature verifies correctly. > > Response is sent back to client with data. > > 2. Query is for a signed domain, where the algorithm is known, but the > signature verification fails. > > Response is sent back, but the response has SERVFAIL status and no data. > > 3. Query is for a signed domain, where the algorithm is not known, and > can because of that not be verified. > > A normal reply of the data, without the signatures and so on. Like it > was an unsigned domain. > > 4. Query for signed domain, the algorithm not known. But the answer is > forged. > > This forged answer is sent to the client without checking. Just like for > an unsigned domain when the answer is forged. > > For me, this implies (specifically as I in this discussion screwed up > and did not really understand at first) we need to write something about > how important it is to agree on what crypto algorithms will be in use, > or else we will get cases 3 and 4 "too often", when people believe case > 1 or 2 are in use. > The situation with algorithms is the same "opt-in" from the client side as with DNSSec as a whole. If one wants to be sure that the DNSSec-signed data are correct, he has _the_option_ to deploy DNSSec and start checking DNSSec info. If one wants to be sure that the data from specific domain (country) are correct, he has _the_option_ to install necessary algorithms and start checking this particular flavor of DNSSec info. And distribution of these _options_ will be driven by market demand, as Paul correctly said. If noone overseas will be interested in checking DNSSec info from the given country, then these specific algorithms will have only local meaning, and that is normal state of affairs. If, for example, you have no need to read Chinese, then you will have no Chinese drivers on your computer and Chinese text will be undecipherable for you, but that does not mean that does not mean that Chinese encoding should not be present in global list of possible encodings. dol@ > Patrik > From owner-namedroppers@ops.ietf.org Fri Aug 28 01:28: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 DEB643A6859; Fri, 28 Aug 2009 01:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.749 X-Spam-Level: X-Spam-Status: No, score=-7.749 tagged_above=-999 required=5 tests=[AWL=0.446, 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 5A4+J+H7BJEP; Fri, 28 Aug 2009 01:28:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB6243A6984; Fri, 28 Aug 2009 01:28:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgwm1-000CAk-B6 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 08:25:29 +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 1Mgwlw-000C5W-KB for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 08:25:26 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAAA8xl0qQ/uCKe2dsb2JhbACbHAEBFiQGo22IPgGQEgWCP4Fa X-IronPort-AV: E=Sophos;i="4.44,290,1249257600"; d="sig'?scan'208";a="48111182" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2009 08:25:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7S8PM8x011739; Fri, 28 Aug 2009 10:25:22 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7S8PMdE011534; Fri, 28 Aug 2009 08:25:22 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:25:05 +0200 Received: from [192.168.1.64] ([10.61.84.186]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:25:04 +0200 Cc: "namedroppers@ops.ietf.org WG" Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Basil Dolmatov In-Reply-To: <4A97926C.3050103@cryptocom.ru> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-347-410280379" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Fri, 28 Aug 2009 10:25:03 +0200 References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Aug 2009 08:25:04.0435 (UTC) FILETIME=[0B3B5030:01CA27B9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16852.005 X-TM-AS-Result: No--5.980400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1226; t=1251447922; x=1252311922; c=relaxed/simple; s=amsdkim1002; 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]=20Cryptographic=20Algorithm=20 Identifier=20Allocation=20for=20DNSSEC |Sender:=20; bh=n4eTPf61qnN+2Md6RIsAMA+hj117Iwzxk8CcC1Kh1yc=; b=EUUOA1K53GfQ24ex8/tY8lbP3nrC4k3l7O/6lHTd8WkMCOHnxsYXyrhgmK 9NbZd2UKd5sLW+wW6aTobxHcd9cEQW8PLS7thca8nXaZw0/NmI1E4JQ2GLh0 Y8Hiihp56F; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-347-410280379 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 28 aug 2009, at 10.16, Basil Dolmatov wrote: > If one wants to be sure that the DNSSec-signed data are correct, he > has _the_option_ to deploy DNSSec and start checking DNSSec info. > If one wants to be sure that the data from specific domain (country) > are correct, he has _the_option_ to install necessary algorithms and > start checking this particular flavor of DNSSec info. The problem is the reverse as well. If I sign my domain, I do not want people that verify dnssec signatures to get a response if the signature do not validate. Patrik --Apple-Mail-347-410280379 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) iD8DBQFKl5RfvHlR2X0luNwRAjd2AJ9FQdmr/C3F2DOE/cz6Z12HHPPBJQCgxY+j LRCgTqE77nSpBTh6SREDLwM= =yhYp -----END PGP SIGNATURE----- --Apple-Mail-347-410280379-- From owner-namedroppers@ops.ietf.org Fri Aug 28 02:06: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 5C93728C2EE; Fri, 28 Aug 2009 02:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 FxurP0og7uYU; Fri, 28 Aug 2009 02:06:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19FB828C2E7; Fri, 28 Aug 2009 02:06:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgxLY-000NtS-E4 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 09:02:12 +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 1MgxLU-000Nsg-GH for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 09:02: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 99562E601E; Fri, 28 Aug 2009 09:02: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 n7S925I0045526; Fri, 28 Aug 2009 19:02:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908280902.n7S925I0045526@drugs.dv.isc.org> To: Basil Dolmatov Cc: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "namedroppers@ops.ietf.org WG" From: Mark Andrews References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.micros oft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Fri, 28 Aug 2009 12:16:44 +0400." <4A97926C.3050103@cryptocom.ru> Date: Fri, 28 Aug 2009 19:02:04 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: What we will get is a situation like we have with TSIG. Microsoft went ahead and designed GSS-TSIG but failed to implement basic TSIG so there was no interoperability. This did and still does cause operational pain. I, at least, don't want to see similar issues with DNSSEC which is where this appears to be heading. I would like to be able to say you can only get a code point when it provides a significant improvement over what already exists and if there is consensus amongst the crypto geeks that this is the case you get the code point. Everyone else gets to use the domain name escape path if they feel they must use their own crypto. Vendors would be encoraged to implement algorithms with their own code points. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Fri Aug 28 04:18: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 CD5823A6B2E; Fri, 28 Aug 2009 04:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-eMDf1kOf0X; Fri, 28 Aug 2009 04:18:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 285FD3A6FAE; Fri, 28 Aug 2009 04:17:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgzMn-000Kka-Fh for namedroppers-data0@psg.com; Fri, 28 Aug 2009 11:11:37 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgzMh-000KZh-LI for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 11:11: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 n7SBA4IK005979; Fri, 28 Aug 2009 11:10:04 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7SBA4Ml005978; Fri, 28 Aug 2009 11:10:04 GMT Date: Fri, 28 Aug 2009 11:10:04 +0000 From: bmanning@vacation.karoshi.com To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: Basil Dolmatov , "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090828111004.GB5194@vacation.karoshi.com.> References: <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fdltstrvm wrote: > > On 28 aug 2009, at 10.16, Basil Dolmatov wrote: > > >If one wants to be sure that the DNSSec-signed data are correct, he > >has _the_option_ to deploy DNSSec and start checking DNSSec info. > >If one wants to be sure that the data from specific domain (country) > >are correct, he has _the_option_ to install necessary algorithms and > >start checking this particular flavor of DNSSec info. > > The problem is the reverse as well. If I sign my domain, I do not want > people that verify dnssec signatures to get a response if the > signature do not validate. > > Patrik > really? I'd thought you would want them to get a response that sez; "Cant validate". --bill From owner-namedroppers@ops.ietf.org Fri Aug 28 04: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 E493A3A6E26; Fri, 28 Aug 2009 04:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM2Gj7-NxvKQ; Fri, 28 Aug 2009 04:32:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 115513A6DDF; Fri, 28 Aug 2009 04:32:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mgzdf-000Mfb-2U for namedroppers-data0@psg.com; Fri, 28 Aug 2009 11:29:03 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MgzdZ-000MUv-RM for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 11:29:01 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n7SBRDIK006113; Fri, 28 Aug 2009 11:27:13 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7SBR6Bq006112; Fri, 28 Aug 2009 11:27:06 GMT Date: Fri, 28 Aug 2009 11:27:06 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh Cc: bmanning@vacation.karoshi.com, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed Message-ID: <20090828112706.GA6056@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49FE02E45D12846B1BE861E2@nimrod.home> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 27, 2009 at 07:34:36PM +0100, Alex Bligh wrote: > > > --On 27 August 2009 14:26:30 +0000 bmanning@vacation.karoshi.com wrote: > > >1 Introduction. > > This seems to be the only use of the word "MUST". It says > "all transport options MUST/need to be supported". "all transport options" > could include more than TCP/UDP (see previous paragraph "may be ported > to use other transports in the future"). Why not just say, as a stand > alone paragraph: > > "DNS servers MUST support both UDP and TCP transports". this wording change is not desirable. this document is not intended to specify which transports may or may not be supported. thats a function of the DNS core specs .. transports may change ... i don't want this docuement to be the place where they are defined (again). > > >2.1. UDP vs TCP for DNS messages > > As this section is already stating what is (at least to us) obvious, you > might as well enumerate some other factors: > > TCP transport will in general result in more latency as more packets > are exchanged prior to the party issuing the query receiving an > answer. > > TCP transport may perform better when the answer expected is large, as > UDP transport may require fragmentation to be supported, and poorly > implemented or configured middleboxes may drop UDP fragments. > > It is harder for a third party to spoof answers where TCP is used when > compared to UDP. all true. some of these are germaine to the primary motivation for this draft. thanks. > > -- > Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 28 05: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 15F2B28C332; Fri, 28 Aug 2009 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.898 X-Spam-Level: *** X-Spam-Status: No, score=3.898 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, 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 gq+8IcnuDKiR; Fri, 28 Aug 2009 05:03:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B41228C340; Fri, 28 Aug 2009 05:02:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh06J-0002tZ-6G for namedroppers-data0@psg.com; Fri, 28 Aug 2009 11:58:39 +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 1Mh06F-0002sp-MA for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 11:58:37 +0000 Received: (qmail 7683 invoked from network); 28 Aug 2009 12:07:47 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 28 Aug 2009 12:07:47 -0000 Message-ID: <4A97C63E.4080907@necom830.hpcl.titech.ac.jp> Date: Fri, 28 Aug 2009 20:57:50 +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: Alan Clegg CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention References: <4A9724E7.2070108@isc.org> In-Reply-To: <4A9724E7.2070108@isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alan Clegg wrote: > I have a google alert set for "DNSSEC" and was rather interested by the > document that it brought to my attention today. > > Good points brought up (one at my expense, I must say) on a number of > things, but some minor errors (particularly page 64). That's quite interesting. Though not very accurate. The truth is that, though the document says: 1994.02 Eastlake-Kaufman, after months of discussions on dns-security mailing list: "DNSSEC" protocol specification. Eastlake-Kaufman avoided the discussion in the mailing list only to produce a quite defective protocol subtly but fatally not compatible to the existing DNS specification in various ways, including, but not limited to, MTU and referral issues. So, I proposed, in 1994.08, a proper document draft-ohta-simple-dns-00.txt reflecting the discussion. And, though the document says: Continued DNSSEC efforts received millions of dollars of government grants: The result, after wasting many years, is essentially identical to draft-ohta-simple-dns-00.txt, which was admitted by the WG recently (about one or two years ago), though there may still be some defects remaining. Luckily enough, the wasted millions of dollars is not of my government. Even more luckily, as PKIs, including DNSSEC, are not end to end but weakly secure, that is, as secure as plain old DNS, it's a blessing that my complete proposal was not deployed in time only to make domain name registration unnecessarily complex and expensive. Masataka Ohta From owner-namedroppers@ops.ietf.org Fri Aug 28 05:47: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 D7F283A7144; Fri, 28 Aug 2009 05:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.833 X-Spam-Level: *** X-Spam-Status: No, score=3.833 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 EN4FzVXDPOhE; Fri, 28 Aug 2009 05:47:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9553A7147; Fri, 28 Aug 2009 05:47:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh0lL-000Ce7-R6 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 12:41:03 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh0lH-000Ccm-AP for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 12:41:01 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1Mh0l9-0006ck-Fw; Fri, 28 Aug 2009 13:40:51 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mh0l8-0005Iq-NS; Fri, 28 Aug 2009 13:40:50 +0100 Message-ID: From: "George Barwood" To: , "Alex Bligh" Cc: , "Andrew Sullivan" , References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> Subject: Re: [dnsext] Editor needed Date: Fri, 28 Aug 2009 13:40:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxibWFubmluZ0B2YWNhdGlvbi5r YXJvc2hpLmNvbT4NClRvOiAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpDYzogPGJt YW5uaW5nQHZhY2F0aW9uLmthcm9zaGkuY29tPjsgIkFuZHJldyBTdWxsaXZhbiIgPGFqc0BzaGlu a3Vyby5jb20+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgQXVn dXN0IDI4LCAyMDA5IDEyOjI3IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRWRpdG9yIG5lZWRl ZA0KDQoNCj4gT24gVGh1LCBBdWcgMjcsIDIwMDkgYXQgMDc6MzQ6MzZQTSArMDEwMCwgQWxleCBC bGlnaCB3cm90ZToNCj4+IA0KPj4gDQo+PiAtLU9uIDI3IEF1Z3VzdCAyMDA5IDE0OjI2OjMwICsw MDAwIGJtYW5uaW5nQHZhY2F0aW9uLmthcm9zaGkuY29tIHdyb3RlOg0KPj4gDQo+PiA+MSBJbnRy b2R1Y3Rpb24uDQo+PiANCj4+IFRoaXMgc2VlbXMgdG8gYmUgdGhlIG9ubHkgdXNlIG9mIHRoZSB3 b3JkICJNVVNUIi4gSXQgc2F5cw0KPj4gImFsbCB0cmFuc3BvcnQgb3B0aW9ucyBNVVNUL25lZWQg dG8gYmUgc3VwcG9ydGVkIi4gImFsbCB0cmFuc3BvcnQgb3B0aW9ucyINCj4+IGNvdWxkIGluY2x1 ZGUgbW9yZSB0aGFuIFRDUC9VRFAgKHNlZSBwcmV2aW91cyBwYXJhZ3JhcGggIm1heSBiZSBwb3J0 ZWQNCj4+IHRvIHVzZSBvdGhlciB0cmFuc3BvcnRzIGluIHRoZSBmdXR1cmUiKS4gV2h5IG5vdCBq dXN0IHNheSwgYXMgYSBzdGFuZA0KPj4gYWxvbmUgcGFyYWdyYXBoOg0KPj4gDQo+PiAiRE5TIHNl cnZlcnMgTVVTVCBzdXBwb3J0IGJvdGggVURQIGFuZCBUQ1AgdHJhbnNwb3J0cyIuDQo+IA0KPiB0 aGlzIHdvcmRpbmcgY2hhbmdlIGlzIG5vdCBkZXNpcmFibGUuICB0aGlzIGRvY3VtZW50IGlzDQo+ IG5vdCBpbnRlbmRlZCB0byBzcGVjaWZ5IHdoaWNoIHRyYW5zcG9ydHMgbWF5IG9yIG1heSBub3Qg YmUNCj4gc3VwcG9ydGVkLiAgdGhhdHMgYSBmdW5jdGlvbiBvZiB0aGUgRE5TIGNvcmUgc3BlY3Mg Li4NCg0KSSdtIGdldHRpbmcgY29uZnVzZWQgaGVyZS4uLg0KDQpBbmRyZXcgb3JpZ2luYWxseSBh c2tlZA0KDQoiT25lIG9mIHRoZSBtaWxlc3RvbmVzIG9uIHRoZSBDaGFydGVyIHRoYXQgd2UndmUg YmVlbiB3YWl0aW5nIHRvIHNlbmQNCnRvIG91ciBBRCBpcyBhIGRvY3VtZW50IHRoYXQgY2xhcmlm aWVzIHRoYXQgVENQIHRyYW5zcG9ydCBpcyBtYW5kYXRvcnkNCmZvciBETlMuICBXZSBuZWVkIGEg dm9sdW50ZWVyIHRvIGVkaXQgdGhhdCBkcmFmdC4gIERvZXMgYW55b25lIHdhbnQgdG8NCmRvIHRo aXM/Ig0KDQpBY3R1YWxseSBJIHRoaW5rIEFuZHJld3Mgc3VnZ2VzdGlvbiBpcyB0b28gc3Ryb25n Lg0KDQpJIHRoaW5rIFRDUCBzaG91bGQgYmUgbWFuZGF0b3J5IG9ubHkgZm9yIGF1dGhvcml0aWVz IHRoYXQgZ2VuZXJhdGUNCnJlc3BvbnNlcyBpbiBleGNlc3Mgb2YgNTEyIGJ5dGVzLg0KDQo+IHRy YW5zcG9ydHMgbWF5IGNoYW5nZSAuLi4gaSBkb24ndCB3YW50IHRoaXMgZG9jdWVtZW50IHRvIA0K PiBiZSB0aGUgcGxhY2Ugd2hlcmUgdGhleSBhcmUgZGVmaW5lZCAoYWdhaW4pLg0KPiANCj4+IA0K Pj4gPjIuMS4gIFVEUCB2cyBUQ1AgZm9yIEROUyBtZXNzYWdlcw0KPj4gDQo+PiBBcyB0aGlzIHNl Y3Rpb24gaXMgYWxyZWFkeSBzdGF0aW5nIHdoYXQgaXMgKGF0IGxlYXN0IHRvIHVzKSBvYnZpb3Vz LCB5b3UNCj4+IG1pZ2h0IGFzIHdlbGwgZW51bWVyYXRlIHNvbWUgb3RoZXIgZmFjdG9yczoNCj4+ IA0KPj4gVENQIHRyYW5zcG9ydCB3aWxsIGluIGdlbmVyYWwgcmVzdWx0IGluIG1vcmUgbGF0ZW5j eSBhcyBtb3JlIHBhY2tldHMNCj4+IGFyZSBleGNoYW5nZWQgcHJpb3IgdG8gdGhlIHBhcnR5IGlz c3VpbmcgdGhlIHF1ZXJ5IHJlY2VpdmluZyBhbg0KPj4gYW5zd2VyLg0KPj4gDQo+PiBUQ1AgdHJh bnNwb3J0IG1heSBwZXJmb3JtIGJldHRlciB3aGVuIHRoZSBhbnN3ZXIgZXhwZWN0ZWQgaXMgbGFy Z2UsIGFzDQo+PiBVRFAgdHJhbnNwb3J0IG1heSByZXF1aXJlIGZyYWdtZW50YXRpb24gdG8gYmUg c3VwcG9ydGVkLCBhbmQgcG9vcmx5DQo+PiBpbXBsZW1lbnRlZCBvciBjb25maWd1cmVkIG1pZGRs ZWJveGVzIG1heSBkcm9wIFVEUCBmcmFnbWVudHMuDQo+PiANCj4+IEl0IGlzIGhhcmRlciBmb3Ig YSB0aGlyZCBwYXJ0eSB0byBzcG9vZiBhbnN3ZXJzIHdoZXJlIFRDUCBpcyB1c2VkIHdoZW4NCj4+ IGNvbXBhcmVkIHRvIFVEUC4NCj4gDQo+IGFsbCB0cnVlLiAgc29tZSBvZiB0aGVzZSBhcmUgZ2Vy bWFpbmUgdG8gdGhlIHByaW1hcnkgbW90aXZhdGlvbg0KPiBmb3IgdGhpcyBkcmFmdC4gICB0aGFu a3MuDQo+IA0KPj4gDQo+PiAtLSANCj4+IEFsZXggQmxpZ2gNCj4gDQo+ From owner-namedroppers@ops.ietf.org Fri Aug 28 06:19: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 872493A6B7E; Fri, 28 Aug 2009 06:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=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 T9cOigCkT55z; Fri, 28 Aug 2009 06:19:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 505613A6C76; Fri, 28 Aug 2009 06:18:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh1Hy-000N6r-TJ for namedroppers-data0@psg.com; Fri, 28 Aug 2009 13:14:46 +0000 Received: from [194.176.119.229] (helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh1Hu-000N4x-JZ for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 13:14:45 +0000 Received: from core.c-l-i.net (core.c-l-i.net [204.62.249.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id 806891AB2FF; Fri, 28 Aug 2009 13:14:39 +0000 (UTC) Cc: Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: <179926BD-AE11-4905-8214-894792AC4EF8@bondis.org> From: =?ISO-8859-1?Q?Jo=E3o_Damas?= To: Alan Clegg In-Reply-To: <4A973B36.8060708@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Date: Fri, 28 Aug 2009 15:14:38 +0200 References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <4A973B36.8060708@isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 28 Aug 2009, at 04:04, Alan Clegg wrote: > Matthew Dempsky wrote: > >>> You can't just "sidestep" by forging NS+A in parent. >> >> You can until registrars allow you to add DS records. I notice >> isc.org has DS records, but I just checked GoDaddy, and I couldn't >> figure out how to add them for dempsky.org. (Maybe I'd have to >> transfer to another registrar?) > > Correct. DNSSEC is not fully deployed yet. You won't find a > registrar > that can accept DS records for .ORG yet. > yet, there are some ways of getting DS records during this limited entry time. I can count 25 DS records in the .org zone right now, including bondis.org, sanog.org and others. Not yet mainstream, OK, but one more step in the phased introduction of DS records in .org I am sure some registrars will allow DS records some time soon Joao From owner-namedroppers@ops.ietf.org Fri Aug 28 07:05: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 DB1913A712A; Fri, 28 Aug 2009 07:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.762 X-Spam-Level: X-Spam-Status: No, score=-7.762 tagged_above=-999 required=5 tests=[AWL=0.433, 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 pGW2OqqSQVha; Fri, 28 Aug 2009 07:05:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEEBF28C349; Fri, 28 Aug 2009 07:05:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh1yb-0006q3-Cq for namedroppers-data0@psg.com; Fri, 28 Aug 2009 13:58:49 +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 1Mh1yX-0006pQ-D7 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 13:58:47 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoAAIN/l0qQ/uCLe2dsb2JhbACbHQEBFiQGpG2IQAGQHQWCP4Fa X-IronPort-AV: E=Sophos;i="4.44,291,1249257600"; d="sig'?scan'208";a="48141532" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2009 13:58:43 +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 n7SDwhNO005110; Fri, 28 Aug 2009 15:58:43 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7SDwhVr008758; Fri, 28 Aug 2009 13:58:43 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 15:58:42 +0200 Received: from [192.168.1.64] ([10.61.84.186]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 15:58:43 +0200 Cc: Basil Dolmatov , "namedroppers@ops.ietf.org WG" Message-Id: <80942BDC-B9EB-4B5A-8F63-1559F2EB1D5F@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bmanning@vacation.karoshi.com In-Reply-To: <20090828111004.GB5194@vacation.karoshi.com.> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-430298128" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Fri, 28 Aug 2009 15:58:41 +0200 References: <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> <20090828111004.GB5194@vacation.karoshi.com.> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Aug 2009 13:58:43.0216 (UTC) FILETIME=[A75AE100:01CA27E7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1547; t=1251467923; x=1252331923; 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]=20Cryptographic=20Algorithm=20 Identifier=20Allocation=20for=20DNSSEC |Sender:=20; bh=snYoHimIlE9ahxHZTSEEX8hfMDbvUygc1TD4zw/e+rQ=; b=ECdDB8J34nRV8zMnZDEVl3wnrbRkYzDrm4xVRheTMU2k2J5v7NsaOf6FZ1 1uScUARjq5NPczHLbbf+r/yIpzxC0t8S80LW0+Qjp65ZOhm3hWJelSyNQN0A ReLuCnG2NN; 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5-430298128 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 28 aug 2009, at 13.10, bmanning@vacation.karoshi.com wrote: > On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fdltstrvm wrote: >> >> On 28 aug 2009, at 10.16, Basil Dolmatov wrote: >> >>> If one wants to be sure that the DNSSec-signed data are correct, he >>> has _the_option_ to deploy DNSSec and start checking DNSSec info. >>> If one wants to be sure that the data from specific domain (country) >>> are correct, he has _the_option_ to install necessary algorithms and >>> start checking this particular flavor of DNSSec info. >> >> The problem is the reverse as well. If I sign my domain, I do not >> want >> people that verify dnssec signatures to get a response if the >> signature do not validate. > > really? I'd thought you would want them to get a response that > sez; "Cant validate". Old clients can not understand new messages. You propose a new message. paf --Apple-Mail-5-430298128 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) iD8DBQFKl+KRvHlR2X0luNwRAg0XAKDGnITvFs0A7SGfmHyxRKOt/hz3AgCfU1iM 0IbvTTn/wpUs0iQ560kIE28= =7PyY -----END PGP SIGNATURE----- --Apple-Mail-5-430298128-- From owner-namedroppers@ops.ietf.org Fri Aug 28 07:16: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 0420428C377; Fri, 28 Aug 2009 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWvtqyO6HhYm; Fri, 28 Aug 2009 07:16:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C89A3A6953; Fri, 28 Aug 2009 07:16:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2BY-0009EI-M2 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 14:12:12 +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 1Mh2BV-0009Dg-9O for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 14:12: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 DBB1F2FE8CB8 for ; Fri, 28 Aug 2009 14:12:05 +0000 (UTC) Date: Fri, 28 Aug 2009 10:12:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090828141203.GR7821@shinkuro.com> References: <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fältström wrote: > > The problem is the reverse as well. If I sign my domain, I do not want > people that verify dnssec signatures to get a response if the signature > do not validate. Too bad. The protocol is not designed to give you that assurance, and never was. That one can introduce a new algorithm without the old algorithm being supported everywhere is supposed to be a feature. Now, if you want to be fairly confident that your zone will be validatable by the largest possible set of validators, then you will use algorithms that are widely supported. But you cannot be sure, even today, that if you are using sane algorithms someone who is validating is also using those algorithms. The IETF has a long history of saying, "X is bad for interoperability, so we won't 'permit' it." The result is inevitably that people go away and do things they were going to do anyway, only in a way even worse for interoperation because either (1) they're confined to the portion of the protocol intended for expermentation &c., or else (2) they choose to overload some part of the protocol that may in fact be used for something else. Elsewhere in this thread we had an implementer suggesting that it's ok to use unassigned code points for a little while, during the testing phase; the result of having actually done that recently is that we have deployed versions of software which disagree (today!) about what certain algorithm numbers mean. The DNS community has another example of the previous difficulty of getting code points and what it meant: RRTYPEs remain in practice hard to deploy; the unknown type is not universally supported; and other protocol writers, when looking to do something (particularly something tactical) in the DNS inevitably are thrown back on the "TXT with underscore label" strategy, because that is known to work widely. As a community, we sowed that wind, and now we are reaping: it was once very very hard to get a code point, and so people routed around the damage. We can say all we want that there are now easy mechanisms to do what people want, but we trained the rest of the world to think it would be hard, they built their systems accordingly, and now our easy mechanisms don't work as we would like. None of this is to say that we should or should not adopt the strategies in Paul's draft. It is rather to say that the "interoperation" argument cuts more than one way, and we don't get to ignore the part of the argument that entails that easier access to identifier numbers may help interoperation. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 07:29: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 E8CAF3A68FA; Fri, 28 Aug 2009 07:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.775 X-Spam-Level: X-Spam-Status: No, score=-7.775 tagged_above=-999 required=5 tests=[AWL=0.420, 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 Lzw2T9o0LR2c; Fri, 28 Aug 2009 07:29:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2A2D3A6B06; Fri, 28 Aug 2009 07:29:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2Oq-000Azm-52 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 14:25:56 +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 1Mh2Ol-000Ayl-6L for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 14:25:53 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoAAF6Fl0qQ/uCLe2dsb2JhbACbHQEBFiQGpSGIQAGQHgWEGQ X-IronPort-AV: E=Sophos;i="4.44,291,1249257600"; d="sig'?scan'208";a="48144357" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2009 14:25:49 +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 n7SEPniM012594; Fri, 28 Aug 2009 16:25:49 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7SEPnuZ016774; Fri, 28 Aug 2009 14:25:49 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 16:25:48 +0200 Received: from [192.168.1.64] ([10.61.84.186]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 16:25:48 +0200 Cc: namedroppers@ops.ietf.org Message-Id: <997EFD48-B7E1-4B72-95AF-11BD75D9A029@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Andrew Sullivan In-Reply-To: <20090828141203.GR7821@shinkuro.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10-431924325" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Fri, 28 Aug 2009 16:25:47 +0200 References: <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> <20090828141203.GR7821@shinkuro.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Aug 2009 14:25:48.0855 (UTC) FILETIME=[704FB470:01CA27EB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16852.007 X-TM-AS-Result: No--5.131500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1039; t=1251469549; x=1252333549; 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]=20Cryptographic=20Algorithm=20 Identifier=20Allocation=20for=20DNSSEC |Sender:=20; bh=y4B/xF9X9tyIW5IOOjtehMAlkoSS3FsAKpPtkcU3LeI=; b=UZ1JtJhaEyqSXojIz0AJpbDO0mA2vHsVIWf6BUk7VEpQM8xBVy14mL+/z1 MVCi/gTq+qiwFtSqxTkvgiDJ+5ttQjSVWOyvjmf6ZkAseZNQ5M16C1OzdpzC zBUCQ1Gn6f; 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10-431924325 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 28 aug 2009, at 16.12, Andrew Sullivan wrote: > None of this is to say that we should or should not adopt the > strategies in Paul's draft. It is rather to say that the > "interoperation" argument cuts more than one way, and we don't get to > ignore the part of the argument that entails that easier access to > identifier numbers may help interoperation. I agree with this. Patrik --Apple-Mail-10-431924325 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) iD8DBQFKl+jrvHlR2X0luNwRAhkqAKDK89wCqw7ErBPtNLA0dBkJAYyf7ACcDslM XRdZsRrtPHETJ7OQ5qM7szM= =iUT+ -----END PGP SIGNATURE----- --Apple-Mail-10-431924325-- From owner-namedroppers@ops.ietf.org Fri Aug 28 07:40: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 4D26A3A6A67; Fri, 28 Aug 2009 07:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[AWL=0.508, 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 L7UcNUZCu+MA; Fri, 28 Aug 2009 07:40:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F1643A6977; Fri, 28 Aug 2009 07:40:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2Z5-000EF4-O5 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 14:36:31 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2Z0-000E8F-DC for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 14:36:29 +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 n7SEa288065028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 07:36:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> Date: Fri, 28 Aug 2009 07:36:02 -0700 To: "George Barwood" , , "Alex Bligh" From: Paul Hoffman Subject: Re: [dnsext] Editor needed Cc: , "Andrew Sullivan" , Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 1:40 PM +0100 8/28/09, George Barwood wrote: >Actually I think Andrews suggestion is too strong. > >I think TCP should be mandatory only for authorities that generate >responses in excess of 512 bytes. Does this make sense from an operational standpoint? That is, assume that I am an authority who today doesn't emit responses in excess of 512 bytes, and I set up a system that will *only* do UDP, and a later improvement to DNS (like DNSSEC, but there could be others) would cause me to emit responses that are now longer. I will then have a broken system. I should now update the system to also, but I don't actually have to (the problems are for other people, not me), and so I now have an operationally broken system that looks OK to me. We may be better off telling people that they need to support UDP and TCP from the beginning. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Fri Aug 28 07:43: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 1250728C2F7; Fri, 28 Aug 2009 07:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=-0.798, 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 GzVZYQPX++sH; Fri, 28 Aug 2009 07:43:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECF463A6BB2; Fri, 28 Aug 2009 07:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2dI-000G0I-4A for namedroppers-data0@psg.com; Fri, 28 Aug 2009 14:40:52 +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 1Mh2dD-000Fxe-0x for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 14:40:49 +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 C5B022FE8CB8 for ; Fri, 28 Aug 2009 14:40:45 +0000 (UTC) Date: Fri, 28 Aug 2009 10:40:44 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090828144043.GS7821@shinkuro.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Fri, Aug 28, 2009 at 07:51:52AM +0200, Patrik Fältström wrote: > I have rechecked the DNSSEC spec (thanks to some people on this list for > offline help) and I see now the following four situations: I think there are more than these four. First, you are discounting the case where the end node does its own validation. In this case, it has more information on which to base decisions, which alone might be a useful state of affairs (I don't know: I'm conscious of the problems that, for instance, have resulted from self-signed certs and the way that's been dealt with historically in web browsers). Second, > 3. Query is for a signed domain, where the algorithm is not known, and > can because of that not be verified. > > A normal reply of the data, without the signatures and so on. Like it > was an unsigned domain. There are two policies available here, and it's important to remember what they are. If a security-aware, non-validating stub talks to a validating resolver via a secure path, then it can in fact use the AD bit to tell whether a response was signed. I know that many people think the AD bit under this circumstance is just a debugging aid, but at least one implementation has decided to use it as a basis for making decisions. One decision is, "Use this DNS answer," but the other one is, "Treat this answer as suspect." Today it would probably be insane to refuse to follow an answer were it not secured, but the same may not be true in the future, and it seems to me one could legitmately pick a policy, "I will not use unvalidated answers, period," especially in certain kinds of applications. Under such deployment conditions, of course, there is even greater pressure to pick one of a small number of well-supported algorithms for at least one of the signing algorithms for a zone. That, however, seems to me to be policy and not protocol, and therefore to be on topic in another WG. > 4. Query for signed domain, the algorithm not known. But the answer is > forged. > > This forged answer is sent to the client without checking. Just like for > an unsigned domain when the answer is forged. See above. And, as I noted in another message, you have this problem today. It could get worse when SHA-2 is deployed (assuming we ever manage to complete the standards action necessary for that), because people in a fit of panic about the strength of SHA-1 may disable the latter. Certainly worse foot-guns have been handed around by well meaning "security officers" in the past. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 07:48: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 59BD53A6903; Fri, 28 Aug 2009 07:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=-0.774, 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 cPNdI6rqJmST; Fri, 28 Aug 2009 07:48:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B7A53A6C81; Fri, 28 Aug 2009 07:48:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2hb-000I8k-EJ for namedroppers-data0@psg.com; Fri, 28 Aug 2009 14:45:19 +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 1Mh2hX-000I6F-8g for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 14:45:17 +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 2DFC72FE8CB8 for ; Fri, 28 Aug 2009 14:45:14 +0000 (UTC) Date: Fri, 28 Aug 2009 10:45:12 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090828144512.GT7821@shinkuro.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> <200908272358.n7RNwrvr038970@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908272358.n7RNwrvr038970@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Fri, Aug 28, 2009 at 09:58:53AM +1000, Mark Andrews wrote: > > There is really nothing new in RSA/SHA2. It's just a code point. Exactly. And yet draft-ietf-dnsext-dnssec-rsasha256-00 appeared in Feb of 2006 and we still don't have a code point, because getting a code point is a heavyweight operation involving a standards action. > I really don't expect interoperability problems. This is like > adding a new RR in terms of difficultly. I note that adding a new RR is even easier now: we do it with expert review. Are you arguing for that route instead of RFC required? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 07:50: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 415013A6B40; Fri, 28 Aug 2009 07:50:31 -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 m-rTjO3Mvp9I; Fri, 28 Aug 2009 07:50:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43D923A6AA1; Fri, 28 Aug 2009 07:50:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh2jM-000JCQ-8H for namedroppers-data0@psg.com; Fri, 28 Aug 2009 14:47: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 1Mh2jE-000J6M-7c for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 14:47: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 n7SEksmV004592; Fri, 28 Aug 2009 07:46:54 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org WG" , Basil Dolmatov Message-Id: From: Nicholas Weaver To: bmanning@vacation.karoshi.com In-Reply-To: <80942BDC-B9EB-4B5A-8F63-1559F2EB1D5F@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Date: Fri, 28 Aug 2009 07:46:54 -0700 References: <4A94EBF6.3030603@connotech.com> <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> <20090828111004.GB5194@vacation.karoshi.com.> <80942BDC-B9EB-4B5A-8F63-1559F2EB1D5F@cisco.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 28 aug 2009, at 13.10, bmanning@vacation.karoshi.com wrote: > On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fdltstrvm wrote: >> >> On 28 aug 2009, at 10.16, Basil Dolmatov wrote: >> >>> If one wants to be sure that the DNSSec-signed data are correct, he >>> has _the_option_ to deploy DNSSec and start checking DNSSec info. >>> If one wants to be sure that the data from specific domain (country) >>> are correct, he has _the_option_ to install necessary algorithms and >>> start checking this particular flavor of DNSSec info. >> >> The problem is the reverse as well. If I sign my domain, I do not >> want >> people that verify dnssec signatures to get a response if the >> signature do not validate. > > really? I'd thought you would want them to get a response that > sez; "Cant validate". What you want is for the client itself to go and generate its own recursive request... Seriously. There is no point in relying on the recursive resolver for validation. Validation at the recursive resolver level adds mostly illusionary security. The real point of someone deploying DNSSEC as an authority and on the end host is because they don't trust the recursive resolvers. And well they shouldn't: the recursive resolvers themselves have proven untrustworthy: between nxdomain wildcarding for ANYTHING.mydomain, to MitMing Google (yes, at least one ISP does this using DNS), etc etc etc... All this talk about recursive resolver validation strikes me as, frankly, silly: Your asking the most proven-untrustworthy component, and the major component thats not in-path for final data, to do your cryptography and just trust the results? WTF? Also, it really depends on WHAT is being validated, what the policy should be, and that policy can only be determined at the stub resolver. If its a name->IP mapping, who cares if the signature fails, if the stub resolver did its own iterative lookup rather than using an external recursive resolver? This means the attack path for DNS to be basically the attack path for the final protocol, so you become dependent on the security for the final protocol, rather than final protocol + recursive resolver. If its a name->keydata mapping (DNSSEC as an alternative PKI), the end application/library needs to do the signature validation and then perform some application-dependent behavior on failure. In neither case should the recursive resolver really do anything but pass data unchanged! From owner-namedroppers@ops.ietf.org Fri Aug 28 08:33: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 2ADA628C374; Fri, 28 Aug 2009 08:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=-0.751, 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 XavJ6s6ntTqg; Fri, 28 Aug 2009 08:33:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F91D28C3E4; Fri, 28 Aug 2009 08:32:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh3Mj-0004ss-6b for namedroppers-data0@psg.com; Fri, 28 Aug 2009 15:27: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 1Mh3Mf-0004qu-Nd for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 15:27:47 +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 835272FE8CB8 for ; Fri, 28 Aug 2009 15:27:44 +0000 (UTC) Date: Fri, 28 Aug 2009 11:27:42 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Message-ID: <20090828152742.GV7821@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Thu, Aug 27, 2009 at 06:13:42PM -0700, Matthew Dempsky wrote: > So as a sniffing attacker, I can't trick you into accepting signed > bogus DS records (and so no bogus records in the child zone), but I > could forge a million responses, each with different bogus NS and A > records. How does the client handle this? Just give up? By way of analogy, as a sniffing attacker you can't trick me into accepting bogus keys for the other end of my attempted SSH connection, but you can dump all kinds of fake bogus hanshake attempts on me. Yes, I give up. Your rhetorical question appears to be suggesting that's a bad idea. I think I disagree. You're right to observe (as is Dr Bernstein) that there is very little security added today for most zones under .org because .org is signed. I'm not sure I have seen a protocol that instantly helps everyone during the period it isn't finished being deployed, but perhaps you (or Dr B.) knows of one. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 08:33: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 4AE4A3A68E5; Fri, 28 Aug 2009 08:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.829 X-Spam-Level: X-Spam-Status: No, score=-103.829 tagged_above=-999 required=5 tests=[AWL=2.770, 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 vFtZiC3w1Mbx; Fri, 28 Aug 2009 08:33:42 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2DE6428C3E9; Fri, 28 Aug 2009 08:32:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh3OA-0005Ag-FA for namedroppers-data0@psg.com; Fri, 28 Aug 2009 15:29: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 1Mh3O7-00059x-8S for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 15:29:16 +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 57B2E2FE8CB8 for ; Fri, 28 Aug 2009 15:29:14 +0000 (UTC) Date: Fri, 28 Aug 2009 11:29:12 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090828152912.GW7821@shinkuro.com> References: <4A958C33.1010009@cryptocom.ru> <200908262126.n7QLQDCl090000@stora.ogud.com> <49DC2C18-6C47-4506-B5C1-C65FAA9E1C7A@cisco.com> <200908270641.n7R6f78T026596@drugs.dv.isc.org> <2EBC8643-0CC4-4C66-9AE8-C6A4006AFDBF@cisco.com> <4A97926C.3050103@cryptocom.ru> <20090828141203.GR7821@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090828141203.GR7821@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 10:12:04AM -0400, Andrew Sullivan wrote: > That one can introduce a new algorithm without the old algorithm being > supported everywhere is supposed to be a feature. That should read, of course, "…without the new algorithm…" Apologies for the confusion. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 09:20:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4461328C42B; Fri, 28 Aug 2009 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMmLwtCQYKcu; Fri, 28 Aug 2009 09:20:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BE1A28C3F8; Fri, 28 Aug 2009 09:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh46x-000L1o-FE for namedroppers-data0@psg.com; Fri, 28 Aug 2009 16:15:35 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh46n-000Js5-A6 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 16:15:33 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n7SGAlIK008192; Fri, 28 Aug 2009 16:10:47 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7SGAj5R008191; Fri, 28 Aug 2009 16:10:45 GMT Date: Fri, 28 Aug 2009 16:10:45 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: George Barwood , bmanning@vacation.karoshi.com, Alex Bligh , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed Message-ID: <20090828161045.GB8109@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 07:36:02AM -0700, Paul Hoffman wrote: > At 1:40 PM +0100 8/28/09, George Barwood wrote: > >Actually I think Andrews suggestion is too strong. > > > >I think TCP should be mandatory only for authorities that generate > >responses in excess of 512 bytes. > > Does this make sense from an operational standpoint? That is, assume that I am an authority who today doesn't emit responses in excess of 512 bytes, and I set up a system that will *only* do UDP, and a later improvement to DNS (like DNSSEC, but there could be others) would cause me to emit responses that are now longer. I will then have a broken system. I should now update the system to also, but I don't actually have to (the problems are for other people, not me), and so I now have an operationally broken system that looks OK to me. > > We may be better off telling people that they need to support UDP and TCP from the beginning. > i don't care what transports (multiple) are defined for use by the DNS. if its defined for use - then i posit in this document that it MUST be supported... be it avian carrier, STCP, UDP, TCP, NCP... I don't care. and this document should not be the place to define DNS transports. --bill From owner-namedroppers@ops.ietf.org Fri Aug 28 09:53: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 EF47D3A6A9F; Fri, 28 Aug 2009 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=0.056, 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 JFItwv2HUyLh; Fri, 28 Aug 2009 09:53:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B16F3A6B59; Fri, 28 Aug 2009 09:53:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4cL-0003G1-2P for namedroppers-data0@psg.com; Fri, 28 Aug 2009 16:48:01 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4cD-0003BM-EA for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 16:47:58 +0000 Received: from [192.168.1.10] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 010FCC2DAF; Fri, 28 Aug 2009 17:47:44 +0100 (BST) Date: Fri, 28 Aug 2009 17:47:39 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com cc: bmanning@vacation.karoshi.com, Andrew Sullivan , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Editor needed Message-ID: <50F285E5AB4C3B727FD6395E@nimrod.home> In-Reply-To: <20090828112706.GA6056@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Bill, --On 28 August 2009 11:27:06 +0000 bmanning@vacation.karoshi.com wrote: >> "DNS servers MUST support both UDP and TCP transports". > > this wording change is not desirable. this document is > not intended to specify which transports may or may not be > supported. thats a function of the DNS core specs .. > > transports may change ... i don't want this docuement to > be the place where they are defined (again). I can't disagree with your logic that the core specs are the place to define this, but Andrew Sullivan wrote: > One of the milestones on the Charter that we've been waiting to send > to our AD is a document that clarifies that TCP transport is mandatory > for DNS. We need a volunteer to edit that draft. Does anyone want to > do this? That implied to me that: a) the existing set of RFCs needs clarification (in respect of the fact that TCP is mandatory); and b) the new draft should clarify that TCP transport is mandatory. I read wording within the draft as "all transports are mandatory", which, either means all transports currently defined within the DNS specs, or (with reference to the preceding para in the draft) all transports that might in the future be defined). It cannot be the case that all future defined transports are mandatory to support, or someone could write an experimental draft of DNS over avian carrier or whatever. It presumably thus either means "all transports defined to date" which is a finite enumerable set (of 2, as far as I know, UDP and TCP, though who knows, there may be more deprecated ones), or "all current and future standards track transports defined as mandatory to support within the relevant RFC", which I'm not sure needs encoding as any future RFC would merely update this one. I'm thus genuinely puzzled as to what it does mean. If it is something like "DNS Servers MUST support all mandatory standards track transports, which at the date of publication of this RFC means both UDP and TCP, though this list may be added to (or subtracted from) in the future." then let's say that, else it is no more clear than it was before. -- Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 28 10:03: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 866E83A6AF9; Fri, 28 Aug 2009 10:03:36 -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 A2cp24+266PX; Fri, 28 Aug 2009 10:03:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 698463A6E39; Fri, 28 Aug 2009 10:03:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4n3-0008GS-C9 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 16:59: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 1Mh4my-0008Ez-7p for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 16:59:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E6884B4575 for ; Fri, 28 Aug 2009 16:58:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed In-Reply-To: Your message of "Fri, 28 Aug 2009 13:40:41 +0100." References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 28 Aug 2009 16:58:59 +0000 Message-ID: <87527.1251478739@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Fri, 28 Aug 2009 13:40:41 +0100 > ... > Actually I think Andrews suggestion is too strong. > > I think TCP should be mandatory only for authorities that generate > responses in excess of 512 bytes. +1. From owner-namedroppers@ops.ietf.org Fri Aug 28 10:03: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 3785928C342; Fri, 28 Aug 2009 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[AWL=0.107, 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 y09Jbie3s5uw; Fri, 28 Aug 2009 10:03:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83A253A7156; Fri, 28 Aug 2009 10:03:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4nf-0008Tj-1e for namedroppers-data0@psg.com; Fri, 28 Aug 2009 16:59:43 +0000 Received: from [209.85.222.189] (helo=mail-pz0-f189.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4nb-0008Sm-Rr for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 16:59:41 +0000 Received: by pzk27 with SMTP id 27so2120674pzk.9 for ; Fri, 28 Aug 2009 09:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.138.20 with SMTP id l20mr1904782wad.91.1251478779586; Fri, 28 Aug 2009 09:59:39 -0700 (PDT) In-Reply-To: <20090828152742.GV7821@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> Date: Fri, 28 Aug 2009 09:59:39 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 8:27 AM, Andrew Sullivan wrote: > By way of analogy, as a sniffing attacker you can't trick me into > accepting bogus keys for the other end of my attempted SSH connection, > but you can dump all kinds of fake bogus hanshake attempts on me. That's because SSH (as commonly used) doesn't have security guaranteeing availability yet. Two possible solutions available today are to use IPsec and TCP MD5 sigs. From owner-namedroppers@ops.ietf.org Fri Aug 28 10:18: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 7DA623A70AF; Fri, 28 Aug 2009 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.079 X-Spam-Level: X-Spam-Status: No, score=-5.079 tagged_above=-999 required=5 tests=[AWL=-0.584, 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 P8FWRBQVWVuN; Fri, 28 Aug 2009 10:18:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2DE928C12F; Fri, 28 Aug 2009 10:18:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh51m-000D9g-Gr for namedroppers-data0@psg.com; Fri, 28 Aug 2009 17:14:18 +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 1Mh51h-000D6f-Q0 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 17:14: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 n7SHC0IK008682; Fri, 28 Aug 2009 17:12:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7SHC0hF008681; Fri, 28 Aug 2009 17:12:00 GMT Date: Fri, 28 Aug 2009 17:12:00 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed Message-ID: <20090828171200.GA8361@vacation.karoshi.com.> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> <87527.1251478739@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87527.1251478739@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 04:58:59PM +0000, Paul Vixie wrote: > > From: "George Barwood" > > Date: Fri, 28 Aug 2009 13:40:41 +0100 > > ... > > Actually I think Andrews suggestion is too strong. > > > > I think TCP should be mandatory only for authorities that generate > > responses in excess of 512 bytes. > > +1. good - but that is not germaine to this proposal/draft. you write up a draft to change the core DNS specs to state that if you'd like. --bill From owner-namedroppers@ops.ietf.org Fri Aug 28 10: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 4BF1E3A6821; Fri, 28 Aug 2009 10:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=-0.806, 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 eMu-E-NLfqSo; Fri, 28 Aug 2009 10:26:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 811433A67A8; Fri, 28 Aug 2009 10:26:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5Ac-000GRi-53 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 17:23: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 1Mh5AY-000GQf-1J for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 17:23:23 +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 ACA682FE8CB8 for ; Fri, 28 Aug 2009 17:23:20 +0000 (UTC) Date: Fri, 28 Aug 2009 13:23:16 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Message-ID: <20090828172315.GA11294@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Fri, Aug 28, 2009 at 09:59:39AM -0700, Matthew Dempsky wrote: > That's because SSH (as commonly used) doesn't have security > guaranteeing availability yet. Two possible solutions available today > are to use IPsec and TCP MD5 sigs. At which point you move the problem up the stack: when I am setting up my IPsec connection … The basic problem here is that an on-path sniffing attacker can _always_ perform DoS. I cannot believe that's news to anyone, or even that anyone thinks it possible to completely prevent this without a fairly radical rethinking of the meaning of "path". Nothing wrong with that, of course, but it will make rather difficult _ad hoc_ networking between end points previously unacquainted with each other. I would be very happy to be shown wrong in my assumptions above. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 10:59: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 975023A69C0; Fri, 28 Aug 2009 10:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWYdlTrcZRf0; Fri, 28 Aug 2009 10:59:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA18C3A6A9F; Fri, 28 Aug 2009 10:59:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5ev-000OYq-IX for namedroppers-data0@psg.com; Fri, 28 Aug 2009 17:54:45 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5eq-000OXC-98 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 17:54:43 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 2CA0057098; Fri, 28 Aug 2009 13:54:39 -0400 (EDT) Date: Fri, 28 Aug 2009 13:54:39 -0400 (EDT) From: Paul Wouters To: Alan Clegg cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention In-Reply-To: <4A9724E7.2070108@isc.org> Message-ID: References: <4A9724E7.2070108@isc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 27 Aug 2009, Alan Clegg wrote: > http://cr.yp.to/talks/2009.08.10/slides.pdf > I have a google alert set for "DNSSEC" and was rather interested by the > document that it brought to my attention today. Here are my comments to the slides. Feel free to use it anywhere. Not sent to DJB himself because his email server requires some kind of non-RFC opt-in spam reply, and I'm refusing to be his mechanical Turk in combating his personal spam problem. Slide 1-13 is simply FUD. Using the same analogy, we can see that there are about 0 instances of "dnscurve", so it must be in a worse development state. (dnscurve.org nameservers are not using a dnscurve NS record) It also assumes that like with dnscurve, the entire path of trust must be present. With DNSSEC there is no such need, and Dr.B cannot see how well deployed DNSSEC is based on 1 DNSSEC key found somewhere. DNSSEC simply does not need that universal deployment that dnscurve depends on. Slide 14-24 is misrepresentation. DNSSEC is only enabled when you ask for it. This is to ensure full backwards compatibility. That same backwards compatibility was a design goal with dnssurve. Dr.B needs to make up his mind whether that is a good thing or not. He can't have to cake and eat it too. Slide 25-34 is more FUD about amplification attacks. He locates DNSSEC capable authoritative DNS servers and assumes he can query them as a recursive nameserver, and then jumping to many conclusions. This is the same as me writing a script that collects IP addresses from domains having an MX record, and sending a 10 MB email spoofed From to twitter.com. I have just caused a million-fold amplification attack.... Of course this is not true, since email servers don't just accept any email for forwarding, just as those DNSSEC capable servers don't just recurse for everyone. Slides 35-51 are about information leakage with DNSSEC, either with trivial NSEC or with easy NSEC3. However, in a non-DNSSEC zone, it is as easy to send discovering queries for names and check for NXDOMAIN. The fact is, DNSSEC with NSEC3 does not make things worse then non-DNSSEC. Dr.B complete ignores this point by throwing in some irrelevant math. And dnscurve in this case performs equally bad as non-dnssec. I can just query. In fact, it is worse, because with dnscurve, i cannot use caches, but have to query the NS records directly, so multiple people trying to do this would hit a dnscurve setup much harder then a non-dnssec or dnssec setup. Slides 52-59 deal with stripping DNSSEC information and re-using signatures using an vix.com example. It is very misleading. DNSSEC protects against this case easily. One could use short signature times during a move. One could do a KSK rollover at the time of IP change. One could change the nsec3parms and use a new salt. But what it really comes down to is that no one would give away that IP space before all records with that IP in it would be expired from caches to begin with. Or else you would be down for a number of hours/days depending on the TTL values. In other words, it is an imaginary problem Slides 60-61 talk about cryptanalysis. 1024 bit RSA signatures are used for about 30 days. That would cover according to Dr.B an investment of $120M to crack in 30 days, so it would need more to crack it and find the key still in use. If this was really feasible, people can instantly upgrade their crypto algorithm (unlike dnscurve I might add, which is still on 1 "trust djb" elliptic curve) or key size and rollover. If attacks becomes feasible, DNSSEC is a much more flexible candidate to move to a new crypto standard then dnscurve is. Furthermore, Dr.B is on purpose mixing up the use of RSA in long term encryption, versus its use in signatures. The RSA Inc and NIST recommendations are most important for encryption, since you need to prepare for the future. With DNSSEC signatures, you can change your key size safely in a few days. What's the crypto migration path for dnscurve? It is "trust djb breaks his own curve before anyone else does". There is no dnscurve specification, so there is no crypto migration path whatsoever. Page 62-64 talk about forging non-signed glue data. It is basically a DOS attack against the enduser by a MITM. whether you strip just the signatures or the entire DNS data does not matter. The result is the same. The enduser cannot get to where he wants to go. The failure is identical with dnscurve. After all, if the enduser does not get the data, he does not know where to go. Page 65 talks about NSEC3 hashes. Apparently it is a problem that the .org nameservers store millions of these. Somehow that affects DJB. The biggest difference between dnscurve and dnssec is that dnssec protects the authenticity of the data through insecure intermediate caches, where dnscurve has to abolish the dns cache to function. Shall we bring up the total amount of extra DNS queries that are DDOS'ing the internet at large when dnscurve is deployed? The amount of DNS traffic would multiply far more then a thousandfold. DSL routers with mini DNS implementations would not even be possible anymore, because they do not have the memory capacity for dnscurve (nor often the spare cpu cycles for crypto). With DNSSEC, they can just proxy the DNS requests from the ISP. > Good points brought up (one at my expense, I must say) on a number of > things, but some minor errors (particularly page 64). I don't see a single good point of criticism in the entire paper. In fact, I'm shocked that a CS professor would write such a "paper". I'd sincerely hope he holds his own students to a higher standard, or else a CS degree is not going to me amounting to much anymore these days. Paul From owner-namedroppers@ops.ietf.org Fri Aug 28 11:00: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 7210B3A6FA2; Fri, 28 Aug 2009 11:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 XBiER0x5u8RW; Fri, 28 Aug 2009 11:00:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DA913A6B59; Fri, 28 Aug 2009 11:00:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5i5-000Pfg-C1 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 17:58:01 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5i1-000Ped-Kz for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 17:57:59 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id B053F57098; Fri, 28 Aug 2009 13:57:56 -0400 (EDT) Date: Fri, 28 Aug 2009 13:57:56 -0400 (EDT) From: Paul Wouters To: Matthew Dempsky cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention In-Reply-To: Message-ID: References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, 28 Aug 2009, Matthew Dempsky wrote: > On Fri, Aug 28, 2009 at 8:27 AM, Andrew Sullivan wrote: >> By way of analogy, as a sniffing attacker you can't trick me into >> accepting bogus keys for the other end of my attempted SSH connection, >> but you can dump all kinds of fake bogus hanshake attempts on me. > > That's because SSH (as commonly used) doesn't have security > guaranteeing availability yet. Two possible solutions available today > are to use IPsec and TCP MD5 sigs. You forget SSHP DNS records secured by DNSSEC. ;; ANSWER SECTION: xelerance.com. 3592 IN SSHFP 1 1 023B462A48078FEDE5328D9BD9E7F1896CEF75A7 xelerance.com. 3592 IN SSHFP 2 1 176851637907BFFD41D7E161A06D8F2EE14EF35D xelerance.com. 3592 IN RRSIG SSHFP 5 2 3600 20090913135451 20090827133952 16187 xelerance.com. XcjubRLPtO4hG5gTrwVNw/yxM7rgC+FaVKayveftt/vtYKyMwRrNS+RP enDXsKEgPvEo/HAppORfssIlrb5JZNfH4XGEDq27fDnju/ytCjbrTWIY SIIqItbfFkWm1Et5rWaO8n9nkzXpxXqQ/fbHC1HPGE9ewEHxyOfnkiiX 6nU= Paul From owner-namedroppers@ops.ietf.org Fri Aug 28 11:03: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 6490928C27D; Fri, 28 Aug 2009 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[AWL=0.100, 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 AHZQt6oPA9bR; Fri, 28 Aug 2009 11:03:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2B4928C295; Fri, 28 Aug 2009 11:03:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5kU-0000g5-Lu for namedroppers-data0@psg.com; Fri, 28 Aug 2009 18:00:30 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh5kQ-0000fQ-JV for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 18:00:28 +0000 Received: by pxi8 with SMTP id 8so2048925pxi.9 for ; Fri, 28 Aug 2009 11:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.236.28 with SMTP id j28mr1970624wah.162.1251482426306; Fri, 28 Aug 2009 11:00:26 -0700 (PDT) In-Reply-To: References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> Date: Fri, 28 Aug 2009 11:00:26 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 10:57 AM, Paul Wouters wrote: > You forget SSHP DNS records secured by DNSSEC. Do those stop forged TCP FIN packets from a sniffing attacker? I thought they only encode the SSH public key, so the user doesn't have to be prompted by "does this key look right". From owner-namedroppers@ops.ietf.org Fri Aug 28 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 5BD3B3A6E18; Fri, 28 Aug 2009 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[AWL=0.094, 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 yewyjFToCed2; Fri, 28 Aug 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 8B1F83A682E; Fri, 28 Aug 2009 11:21:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh613-0004tH-Ou for namedroppers-data0@psg.com; Fri, 28 Aug 2009 18:17:37 +0000 Received: from [209.85.222.189] (helo=mail-pz0-f189.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh610-0004sW-TE for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 18:17:36 +0000 Received: by pzk27 with SMTP id 27so2166266pzk.9 for ; Fri, 28 Aug 2009 11:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.251.14 with SMTP id y14mr1984726wah.144.1251483453933; Fri, 28 Aug 2009 11:17:33 -0700 (PDT) In-Reply-To: <20090828172315.GA11294@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> Date: Fri, 28 Aug 2009 11:17:33 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 10:23 AM, Andrew Sullivan wrote: > At which point you move the problem up the stack: when I am setting up > my IPsec connection =85 I know there are mailing list participants with more IPsec experience, so I'll let them comment as to what availability guarantees IKE has when the client is able to securely discover the server's public key (e.g., through secured DNS). > The basic problem here is that an on-path sniffing attacker can > _always_ perform DoS. Are you assuming the attacker can force packets to not reach their destination? If so, then yes. Such an attacker can perform a DoS. But otherwise, DNSCurve at least is resistant to sniffing attacks that still permit legitimate packets through. From owner-namedroppers@ops.ietf.org Fri Aug 28 11:36: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 5D4EB3A682E; Fri, 28 Aug 2009 11:36:57 -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 E-woF6l8rUvX; Fri, 28 Aug 2009 11:36:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83BB53A6924; Fri, 28 Aug 2009 11:36:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6Gk-0008zj-SI for namedroppers-data0@psg.com; Fri, 28 Aug 2009 18:33: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 1Mh6Gg-0008yU-Ro for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 18:33:48 +0000 Received: from [192.168.20.130] (unknown [209.42.230.67]) (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 2774CE601C for ; Fri, 28 Aug 2009 18:33:46 +0000 (UTC) (envelope-from aclegg@isc.org) Message-ID: <4A982308.90909@isc.org> Date: Fri, 28 Aug 2009 14:33:44 -0400 From: Alan Clegg Organization: Internet Systems Consortium User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention References: <4A9724E7.2070108@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Paul Wouters wrote: >> Good points brought up (one at my expense, I must say) on a number of >> things, but some minor errors (particularly page 64). > > I don't see a single good point of criticism in the entire paper. [..] The things that I referred to as "good points" are issues that are already known: traffic amplification and disclosure of zone data by those unaware of how NSEC works. These are bad things that we are aware of and that those deploying DNSSEC should also be aware of. We can't deny that both of those issues do exist. I agree that all of this was presented as "OH NO, THE WORLD IS ENDING", and as such is poorly received by this community, but the points are valid... if we don't inform people of these issues and do our best to educate everyone as to "how things should be done" (BCP-38 comes to mind for the first, and "gee, isn't that why we implemented NSEC3" for the second), they will find out the hard way and turn around and blame DNSSEC and those that implement it. If it were not for the attacking manner of the paper (the FUD angle), and the fact that he didn't contact me before complaining about how my zone was configured incorrectly (it was, btw, but only in the fact that I had accidentally disabled zone transfers), then I would recommend this as a "the more you know, the better off you are" type of presentation. AlanC From owner-namedroppers@ops.ietf.org Fri Aug 28 11: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 61B2C3A6826; Fri, 28 Aug 2009 11:50:07 -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.089, 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 VIdNhNXl-qmA; Fri, 28 Aug 2009 11:50:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 143FF3A6802; Fri, 28 Aug 2009 11:50:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6Sy-000DTC-Gq for namedroppers-data0@psg.com; Fri, 28 Aug 2009 18:46:28 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6Sq-000DK8-Mu for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 18:46:23 +0000 Received: by pxi8 with SMTP id 8so2073230pxi.9 for ; Fri, 28 Aug 2009 11:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.9.16 with SMTP id 16mr2047912wai.114.1251485176928; Fri, 28 Aug 2009 11:46:16 -0700 (PDT) In-Reply-To: References: <4A9724E7.2070108@isc.org> Date: Fri, 28 Aug 2009 11:46:16 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 10:54 AM, Paul Wouters wrote: > DNSSEC simply does not need that universal deployment that dnscurve depen= ds on. DNSCurve doesn't depend on universal deployment either. You can setup DNSCurve trust anchors just like you can setup DNSSEC trust anchors. > Slide 25-34 is more FUD about amplification attacks. He locates DNSSEC > capable authoritative DNS servers and assumes he can query them as a > recursive nameserver, and then jumping to many conclusions. He's not querying them as recursive nameservers. He's asking them for large (authoritative) DNSSEC responses, and measuring how much query traffic vs. how much response traffic he saw. > Slides 35-51 are about information leakage with DNSSEC, either with > trivial NSEC or with easy NSEC3. However, in a non-DNSSEC zone, it is > as easy to send discovering queries for names and check for NXDOMAIN. > The fact is, DNSSEC with NSEC3 does not make things worse then non-DNSSEC= . http://www.dnscurve.org/espionage2.html discusses this in more detail. > In fact, it is worse, because with dnscurve, i cannot use caches, > but have to query the NS records directly, so multiple people trying to > do this would hit a dnscurve setup much harder then a non-dnssec or dnsse= c > setup. Paul Vixie has stated he's not concerned about this for the root servers at least. To quote: bring it on. we get way more queries from people who don't cache at al= l, or from people who firewall our answers even though they fail to firewall = their own questions, then we would ever see from a change wherein every host on the internet became its own caching recursive nameserver. bring it on. (really.) As for end zones, if you can't handle one DNS query per unique user, how can you handle X HTTP/HTTPS or SMTP or whatever requests per unique user? > Slides 60-61 =A0talk about cryptanalysis. > 1024 bit RSA signatures are used for about 30 days. That would cover > according to Dr.B an investment of $120M to crack in 30 days, so it would > need more to crack it and find the key still in use. I'll admit some DNSSEC ignorance here: I thought only DNSSEC signatures are regenerated every 30 days. Will the zone signing and key signing keys be rolled every 30 days too? > If this was really > feasible, people can instantly upgrade their crypto algorithm Really? From the conversations here, everyone seems terrified at the idea of upgrading crypto algorithms. > (unlike > dnscurve I might add, which is still on 1 "trust djb" elliptic curve) The "trust DJB" elliptic curve follows all of the NIST recommendations on public key cryptography. Additionally, NSA has withdrawn recommendations on using RSA. By today's cryptanalysis, breaking a 255-bit elliptic curve is comparable in effort to factoring a 3000-bit RSA key. > If attacks becomes feasible, DNSSEC is a much more > flexible candidate to move to a new crypto standard then dnscurve is. DNSCurve is flexible to new crypto standards the same way DNSSEC is. You add a way to encode a hypothetical DNSCurve2 public key, a client can then search for either DNSCurve or DNSCurve2 public keys, and then use whichever is available. Bonus benefit: authoritative servers can track which formats clients support, so they can drop DNSCurve support once everyone is using DNSCurve2 instead. My understanding is there's no way to tell how many DNSSEC clients support RSA-SHA2, so authorities won't know when they can drop support for RSA-SHA1. Please correct me if this is wrong. > There is no dnscurve specification, There's a web site, there's an Internet-Draft, and there are several interoperable implementations. What more do you want? > Page 62-64 talk about forging non-signed glue data. It is basically a DOS > attack against the enduser by a MITM. whether you strip just the signatur= es > or the entire DNS data does not matter. The result is the same. The endus= er > cannot get to where he wants to go. The failure is identical with dnscurv= e. False. DNSCurve authenticates the packet, so the cache rejects forged responses and continues waiting for the legitimate response. From owner-namedroppers@ops.ietf.org Fri Aug 28 12:01: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 8D9CC3A7181; Fri, 28 Aug 2009 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmOjR9H3Mzl5; Fri, 28 Aug 2009 12:01:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF6873A7185; Fri, 28 Aug 2009 12:01:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6dZ-000Haq-1R for namedroppers-data0@psg.com; Fri, 28 Aug 2009 18:57:25 +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 1Mh6dV-000HSh-Fh for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 18:57:23 +0000 Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CC6E02FE8CB8 for ; Fri, 28 Aug 2009 18:57:18 +0000 (UTC) Date: Fri, 28 Aug 2009 14:57:16 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Message-ID: <20090828185715.GD11294@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Fri, Aug 28, 2009 at 11:17:33AM -0700, Matthew Dempsky wrote: > Are you assuming the attacker can force packets to not reach their > destination? If so, then yes. Uh, well, yeah, since you were talking about an on-path sniffing attacker. But supposing they can't force lost packets … > But otherwise, DNSCurve at least is resistant to sniffing attacks that > still permit legitimate packets through. …I don't understand this claim anyway. Cryptographic signatures are there so that A can tell whether the signed data B sent A is legit. Your original point appeared to be that it was trivial for an in-path attacker to substitute forged data, and therefore deny service under DNSSEC because validators will detect it and not go to the proffered address. That's a DoS open to _any_ validation-of-source-data system, and I cannot begin to fathom how DNSCurve or, indeed, any other system purporting to assure the authenticity of data is not susceptible to this attack. If you or Dr B. have invented some way to prevent that style of attack, I would be _very very_ grateful for you to explain how it solves the fundamental problem, because it sounds to me very close to magic. I'd be happy -- really happy -- to be wrong about that, but anytime I hear someone claim, "No DoS here," I am tempted to set up an experiment. So far, I've been beaten to the punch every time by people already exploiting the hole in question. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 12:14: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 2417B3A69D3; Fri, 28 Aug 2009 12:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=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 EqtF-N-BfwTi; Fri, 28 Aug 2009 12:14:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D0403A6CCD; Fri, 28 Aug 2009 12:14:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6qZ-000MTl-3i for namedroppers-data0@psg.com; Fri, 28 Aug 2009 19:10:51 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6qU-000MSA-PG for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 19:10:48 +0000 Received: by pxi8 with SMTP id 8so2088471pxi.9 for ; Fri, 28 Aug 2009 12:10:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.236.28 with SMTP id j28mr2063982wah.162.1251486645184; Fri, 28 Aug 2009 12:10:45 -0700 (PDT) In-Reply-To: <20090828185715.GD11294@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> <20090828185715.GD11294@shinkuro.com> Date: Fri, 28 Aug 2009 12:10:45 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 11:57 AM, Andrew Sullivan wrote: >> But otherwise, DNSCurve at least is resistant to sniffing attacks that >> still permit legitimate packets through. > > =85I don't understand this claim anyway. Suppose a sniffing attacker that can inject malicious packets but cannot stop legitimate packets from reaching their destination. Using just DNSSEC: I send a query for www.ietf.org to the .org name servers. The sniffing attacker sees this query, and sends me a response with a valid DS record, but with bogus NS+A records. The client accepts this delegation, and then sends www.ietf.org queries to some other IP address where they're lost. The user can't reach www.ietf.org. Using DNSCurve: I send a query for www.ietf.org to the .org name servers. The sniffing attacker sees the packet, but any forged responses will be discarded because they don't contain a valid MAC. The client continues waiting until it receives a valid response packet or times out. Once receiving the valid ietf.org delegation, I can then contact the ietf.org servers. Does that help? If not, I'll try to clarify further. From oversupply@iqno.net Fri Aug 28 12:25: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 6F8F03A68A3; Fri, 28 Aug 2009 12:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.322 X-Spam-Level: X-Spam-Status: No, score=-20.322 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_IPADDR=2.426, 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, 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 U33FkZEq8t2W; Fri, 28 Aug 2009 12:25:34 -0700 (PDT) Received: from c-71-201-154-191.hsd1.il.comcast.net (c-71-201-154-191.hsd1.il.comcast.net [71.201.154.191]) by core3.amsl.com (Postfix) with ESMTP id 582033A6AFB; Fri, 28 Aug 2009 12:25:33 -0700 (PDT) Received: from 71.201.154.191 by iqno.net; Fri, 28 Aug 2009 14:25:28 -0600 Message-ID: <000d01ca2815$4cf52940$6400a8c0@oversupply> From: Chantell Chatman To: Subject: Make your fat disappear Date: Fri, 28 Aug 2009 14:25:28 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2815.4CF52940" 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_01CA2815.4CF52940 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Doctors and celebrities trust this miracle, click and try for f= ree.   =A0=A0=A0 Click To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, Ylcqdec 873 Systems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA2815.4CF52940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Doctors and celebrities trust this miracle, click and = try for free.
&nb= sp;
=A0=A0=A0 Click


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top
Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, Ylcqdec 873 Syst= ems, Inc.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA2815.4CF52940-- From owner-namedroppers@ops.ietf.org Fri Aug 28 12:44: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 0CD6B28C1AE; Fri, 28 Aug 2009 12:44:01 -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=-1.407, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZtA2ApB5AW2; Fri, 28 Aug 2009 12:44:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14E7F28C237; Fri, 28 Aug 2009 12:43:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh7Hr-0004Ta-7h for namedroppers-data0@psg.com; Fri, 28 Aug 2009 19:39:03 +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 1Mh7Hn-0004Sy-JM for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 19:39:01 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=dKSKLbaX4T7afdKM22Fs6CsGybHfaOOeixWqLpVmW1IDxobgJpBekqo1+V7yTQfT; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mh7Hm-0004Qk-Iz; Fri, 28 Aug 2009 15:38:58 -0400 Received: from 209.44.32.166 by webmail.earthlink.net with HTTP; Fri, 28 Aug 2009 15:38:58 -0400 Message-ID: <531938.1251488338505.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Fri, 28 Aug 2009 14:38:58 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606880b69f7ec6011124621963c2380098520350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew and all, Good points here IMO. As such it would seem logical to me that a decision has to be made as to whether or not interoperation is more important than supported algo's. I would say it is, for what that's worth. Some or perhaps many would disagree and for some good reasons as well. So this to me anyway leaves the question as to what algo's are going to be supported and by whom when? NIST isn't god almighty for sure, and neither is the IETF for that matter. But it would be my preference and I believe eventually mosts preference that as many algo's be supported as possible, documented fully or not. Otherwise multipul DNS'es will become prevalent and as such somewhat defeat the larger purpose of DNSSEC. -----Original Message----- >From: Andrew Sullivan >Sent: Aug 28, 2009 9:12 AM >To: namedroppers@ops.ietf.org >Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for=09= DNSSEC > >No hat. > >On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik F=C3=A4ltstr=C3=B6m wrote= : >> >> The problem is the reverse as well. If I sign my domain, I do not want = =20 >> people that verify dnssec signatures to get a response if the signature= =20 >> do not validate. > >Too bad. The protocol is not designed to give you that assurance, and >never was. =20 > >That one can introduce a new algorithm without the old algorithm being >supported everywhere is supposed to be a feature. Now, if you want >to be fairly confident that your zone will be validatable by the >largest possible set of validators, then you will use algorithms that >are widely supported. But you cannot be sure, even today, that if you >are using sane algorithms someone who is validating is also using >those algorithms. > >The IETF has a long history of saying, "X is bad for interoperability, >so we won't 'permit' it." The result is inevitably that people go >away and do things they were going to do anyway, only in a way even >worse for interoperation because either (1) they're confined to the >portion of the protocol intended for expermentation &c., or else (2) >they choose to overload some part of the protocol that may in fact be >used for something else. Elsewhere in this thread we had an >implementer suggesting that it's ok to use unassigned code points for >a little while, during the testing phase; the result of having >actually done that recently is that we have deployed versions of >software which disagree (today!) about what certain algorithm numbers >mean. > >The DNS community has another example of the previous difficulty of >getting code points and what it meant: RRTYPEs remain in practice hard >to deploy; the unknown type is not universally supported; and other >protocol writers, when looking to do something (particularly something >tactical) in the DNS inevitably are thrown back on the "TXT with >underscore label" strategy, because that is known to work widely. As >a community, we sowed that wind, and now we are reaping: it was once >very very hard to get a code point, and so people routed around the >damage. We can say all we want that there are now easy mechanisms to >do what people want, but we trained the rest of the world to think it >would be hard, they built their systems accordingly, and now our easy >mechanisms don't work as we would like. > >None of this is to say that we should or should not adopt the >strategies in Paul's draft. It is rather to say that the >"interoperation" argument cuts more than one way, and we don't get to >ignore the part of the argument that entails that easier access to >identifier numbers may help interoperation. > >Best, > >A > >--=20 >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. > Regards, =20 Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 294k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y 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] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.co= m Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Fri Aug 28 12:49: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 E6DAF3A6AFB; Fri, 28 Aug 2009 12:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_21=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 wg58866rPzC4; Fri, 28 Aug 2009 12:49:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B8943A6879; Fri, 28 Aug 2009 12:49:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh7Of-00066O-9T for namedroppers-data0@psg.com; Fri, 28 Aug 2009 19:46: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 1Mh7OZ-000652-96 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 19:46:03 +0000 Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 312472FE8CDD for ; Fri, 28 Aug 2009 19:45:57 +0000 (UTC) Date: Fri, 28 Aug 2009 15:45:54 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Message-ID: <20090828194551.GF11294@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> <20090828185715.GD11294@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 12:10:45PM -0700, Matthew Dempsky wrote: > Using just DNSSEC: I send a query for www.ietf.org to the .org name > servers. The sniffing attacker sees this query, and sends me a > response with a valid DS record, but with bogus NS+A records. How does the "valid DS record" get signed by the attacker? Actually, this is a subtle point and is missed by many, but RFC 4034 says clearly, "The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone." In other words, it is parent-sourced data, and therefore subject to authentication under the parent's key. If you can't do it, then the result is treated accordingly. > servers. The sniffing attacker sees the packet, but any forged > responses will be discarded because they don't contain a valid MAC. > The client continues waiting until it receives a valid response packet > or times out. In other words, if packet-fiddling is detected then either (1) non-fiddled responses win or (2) user can't get to target. At least, that's how I read this. Correct me if I'm missing something. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 28 12:53: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 365AF3A69AF; Fri, 28 Aug 2009 12:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3TI2CLpvPKH; Fri, 28 Aug 2009 12:53:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4E1528C18B; Fri, 28 Aug 2009 12:52:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh7Sb-00071L-FD for namedroppers-data0@psg.com; Fri, 28 Aug 2009 19:50:09 +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 1Mh7SX-00070R-Gq for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 19:50:07 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7SJo5PA017012 for ; Fri, 28 Aug 2009 15:50:05 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n7SJo5Aw017011 for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 15:50:05 -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 1Mh7Ep-0003c0-5S for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 19:35:58 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Mh7EY-0003h2-QK; Fri, 28 Aug 2009 21:35:38 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Mh7EY-0005zv-2X; Fri, 28 Aug 2009 21:35:38 +0200 From: Florian Weimer To: "George Barwood" Cc: , "Alex Bligh" , "Andrew Sullivan" , Subject: Re: [dnsext] Editor needed References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> Date: Fri, 28 Aug 2009 21:35:38 +0200 In-Reply-To: (George Barwood's message of "Fri, 28 Aug 2009 13:40:41 +0100") Message-ID: <87ocpz7mut.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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] * George Barwood: > I think TCP should be mandatory only for authorities that generate > responses in excess of 512 bytes. Uhm, isn't the technical criterion, "sets TC on an UDP response"? Do you still want to say "SHOULD support TCP"? Or do you want to make TCP completely optional? From owner-namedroppers@ops.ietf.org Fri Aug 28 13:50: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 F1D1B3A6C43; Fri, 28 Aug 2009 13:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXNC-u1-eC81; Fri, 28 Aug 2009 13:50:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC5E33A69F0; Fri, 28 Aug 2009 13:50:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh8Kl-000HBE-VX for namedroppers-data0@psg.com; Fri, 28 Aug 2009 20:46:07 +0000 Received: from [68.142.225.233] (helo=smtp117.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh8Ki-000HAD-2C for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 20:46:05 +0000 Received: (qmail 15534 invoked from network); 28 Aug 2009 20:46:02 -0000 Received: from unknown (HELO ?192.168.1.239?) (thierry.moreau@209.148.165.15 with plain) by smtp117.rog.mail.re2.yahoo.com with SMTP; 28 Aug 2009 20:46:02 -0000 X-YMail-OSG: bZKNAjYVM1lUvCx14zOhNwL9rkMF7NwW6scNnY8ViWETIZhNWmlh8JMz9XghCIUGrQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9841E3.4010209@connotech.com> Date: Fri, 28 Aug 2009 16:45:23 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: "Jeffrey A. Williams" CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC References: <531938.1251488338505.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> In-Reply-To: <531938.1251488338505.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Jeffrey A. Williams wrote: > Andrew and all, > > Good points here IMO. As such it would seem logical to me that a > decision has to be made as to whether or not interoperation is more > important than supported algo's. I would say it is, for what that's worth. > Some or perhaps many would disagree and for some good reasons as well. > > So this to me anyway leaves the question as to what algo's are going to > be supported and by whom when? NIST isn't god almighty for sure, and > neither is the IETF for that matter. But it would be my preference and I > believe eventually mosts preference that as many algo's be supported > as possible, documented fully or not. Otherwise multipul DNS'es will > become prevalent and as such somewhat defeat the larger purpose of > DNSSEC. > > Somehow, there are two control points: the IANA function for those algorithm identifiers and the DNS root zone management for support at the root. You infer from Andrew's interesting perspective that entry barriers at the IANA function would trigger alternate roots (i.e. bypass the DNS root zone management control point). My point is that if you lower the criteria at the IANA control point, you may get even more pressure at the DNS root zone management (algorithm XYZ is used in 15 TLDs and thus should be included in the root, otherwise we are legitimized to run a parallel DNS root). Why not just making it easier to get standards-track IETF RFCs for those digital signature schemes that deserve it? Are you IETF'ers so uncertain about the effectiveness potential of IETF processes that you run? The basic mission of the IETF is to come up with high quality specification documents. It should not be unrealistic to expect quality in the digital signature schemes adopted for use in portions of the DNS hierarchy, given that every resolver operators are interested in seamless operations. The unique centralized nature of the Internet DNS command this level of IETF dedication, as I understand it. - Thierry, i.e. just me! > -----Original Message----- > >> From: Andrew Sullivan >> Sent: Aug 28, 2009 9:12 AM >> To: namedroppers@ops.ietf.org >> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC >> >> No hat. >> >> On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fältström wrote: >> >>> The problem is the reverse as well. If I sign my domain, I do not want >>> people that verify dnssec signatures to get a response if the signature >>> do not validate. >>> >> Too bad. The protocol is not designed to give you that assurance, and >> never was. >> >> That one can introduce a new algorithm without the old algorithm being >> supported everywhere is supposed to be a feature. Now, if you want >> to be fairly confident that your zone will be validatable by the >> largest possible set of validators, then you will use algorithms that >> are widely supported. But you cannot be sure, even today, that if you >> are using sane algorithms someone who is validating is also using >> those algorithms. >> >> The IETF has a long history of saying, "X is bad for interoperability, >> so we won't 'permit' it." The result is inevitably that people go >> away and do things they were going to do anyway, only in a way even >> worse for interoperation because either (1) they're confined to the >> portion of the protocol intended for expermentation &c., or else (2) >> they choose to overload some part of the protocol that may in fact be >> used for something else. Elsewhere in this thread we had an >> implementer suggesting that it's ok to use unassigned code points for >> a little while, during the testing phase; the result of having >> actually done that recently is that we have deployed versions of >> software which disagree (today!) about what certain algorithm numbers >> mean. >> >> The DNS community has another example of the previous difficulty of >> getting code points and what it meant: RRTYPEs remain in practice hard >> to deploy; the unknown type is not universally supported; and other >> protocol writers, when looking to do something (particularly something >> tactical) in the DNS inevitably are thrown back on the "TXT with >> underscore label" strategy, because that is known to work widely. As >> a community, we sowed that wind, and now we are reaping: it was once >> very very hard to get a code point, and so people routed around the >> damage. We can say all we want that there are now easy mechanisms to >> do what people want, but we trained the rest of the world to think it >> would be hard, they built their systems accordingly, and now our easy >> mechanisms don't work as we would like. >> >> None of this is to say that we should or should not adopt the >> strategies in Paul's draft. It is rather to say that the >> "interoperation" argument cuts more than one way, and we don't get to >> ignore the part of the argument that entails that easier access to >> identifier numbers may help interoperation. >> >> Best, >> >> A >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> >> > Regards, > > > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 294k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com > Phone: 214-244-4827 > > > > From owner-namedroppers@ops.ietf.org Fri Aug 28 13:53: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 7477628C324; Fri, 28 Aug 2009 13:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=0.095, 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 R2NiMrZ7E9Ug; Fri, 28 Aug 2009 13:53:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82F0628C264; Fri, 28 Aug 2009 13:53:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh8Ox-000Hys-S8 for namedroppers-data0@psg.com; Fri, 28 Aug 2009 20:50:28 +0000 Received: from [209.85.216.178] (helo=mail-px0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh8Ou-000HyH-Gs for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 20:50:26 +0000 Received: by pxi8 with SMTP id 8so2141792pxi.9 for ; Fri, 28 Aug 2009 13:50:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.27.7 with SMTP id e7mr2237614waj.10.1251492621996; Fri, 28 Aug 2009 13:50:21 -0700 (PDT) In-Reply-To: <20090828194551.GF11294@shinkuro.com> References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> <20090828185715.GD11294@shinkuro.com> <20090828194551.GF11294@shinkuro.com> Date: Fri, 28 Aug 2009 13:50:21 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 12:45 PM, Andrew Sullivan wrote: > How does the "valid DS record" get signed by the attacker? By valid, I meant legitimate; i.e., copied from a legitimate response packet. An attacker can easily get this from sending a query to the authoritative server and extracting the DS record from the response. Because the NS and A records point to bogus IPs, it doesn't matter that the client got a legitimate DS key. The goal of this attack is to merely disrupt availability of the target domain name; it doesn't attempt to forge records for the target domain name at all. >> The client continues waiting until it receives a valid response packet >> or times out. > > In other words, if packet-fiddling is detected then either (1) > non-fiddled responses win or (2) user can't get to target. =A0At least, > that's how I read this. =A0Correct me if I'm missing something. I believe that's a correct interpretation. The point is that packet-fiddling is detectible, so fiddled-packets are simply ignored. From sillo@it-picture.com Fri Aug 28 15:31: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 D920C3A6BFF; Fri, 28 Aug 2009 15:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.01 X-Spam-Level: X-Spam-Status: No, score=-25.01 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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_XBL=3.033, 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 iUyM1QaZTJvq; Fri, 28 Aug 2009 15:31:27 -0700 (PDT) Received: from dlv63.neoplus.adsl.tpnet.pl (dlv63.neoplus.adsl.tpnet.pl [83.24.51.63]) by core3.amsl.com (Postfix) with ESMTP id E3BF83A6BFE; Fri, 28 Aug 2009 15:31:22 -0700 (PDT) Received: from 83.24.51.63 by it-picture.com; Sat, 29 Aug 2009 00:30:46 +0100 Message-ID: <000d01ca282f$2ffaf3f0$6400a8c0@sillo> From: Brad Reilly To: Subject: I know that you arent here, when you get back check this out Date: Sat, 29 Aug 2009 00:30:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA282F.2FFAF3F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA282F.2FFAF3F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Victims of obesity and unhealthy lifestyles are ready for a fre= e trail solution.   =A0=A0=A0 welcome To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, Ybuscn 193 Systems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA282F.2FFAF3F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Victims of obesity and unhealthy lifestyles are ready = for a free trail solution.
&nb= sp;
=A0=A0=A0 welcome


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top
Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, Ybuscn 193 Syste= ms, Inc.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA282F.2FFAF3F0-- From communistsv@ipsa.com.hk Fri Aug 28 15:34: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 1E85E3A6BFE; Fri, 28 Aug 2009 15:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.578 X-Spam-Level: X-Spam-Status: No, score=-25.578 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_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, 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 X+SmKmZKwyLD; Fri, 28 Aug 2009 15:34:43 -0700 (PDT) Received: from 20158146064.user.veloxzone.com.br (20158146064.user.veloxzone.com.br [201.58.146.64]) by core3.amsl.com (Postfix) with ESMTP id 0C6873A683A; Fri, 28 Aug 2009 15:34:41 -0700 (PDT) Received: from 201.58.146.64 by ipsa.com.hk; Fri, 28 Aug 2009 19:32:40 -0300 Message-ID: <000d01ca282f$73eb87f0$6400a8c0@communistsv> From: Carma Neff To: Subject: Try this out, I just signed up and am very excited Date: Fri, 28 Aug 2009 19:32:40 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA282F.73EB87F0" 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_01CA282F.73EB87F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Give it all you've got, you owe it to yourself to look and see,= try it free.   =A0=A0=A0 Click doubtless To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, Yfdfwm 0184 Systems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA282F.73EB87F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Give it all you've got, you owe it to yourself to look= and see, try it free.
&nb= sp;
=A0=A0=A0 Click doubtless


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top
Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, Yfdfwm 0184 Syst= ems, Inc.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA282F.73EB87F0-- From owner-namedroppers@ops.ietf.org Fri Aug 28 15:43: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 25F1E3A683A; Fri, 28 Aug 2009 15:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=0.054, 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 HsfsGZiGsxLB; Fri, 28 Aug 2009 15:43:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 509473A6963; Fri, 28 Aug 2009 15:43:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhA5o-0002HP-Ku for namedroppers-data0@psg.com; Fri, 28 Aug 2009 22:38:48 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhA5l-0002Gk-0S; Fri, 28 Aug 2009 22:38:46 +0000 Received: from [192.168.1.10] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B1539C2DA5; Fri, 28 Aug 2009 22:43:33 +0100 (BST) Date: Fri, 28 Aug 2009 22:43:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ray.Bellis@nominet.org.uk cc: Andrew Sullivan , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Editor needed Message-ID: In-Reply-To: References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> <50F285E5AB4C3B727FD6395E@nimrod.home> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 28 August 2009 23:29:01 +0200 Ray.Bellis@nominet.org.uk wrote: > TCP support is NOT currently mandatory. I'm thus confused by Andrew's statement that we should clarify that support is mandatory. -- Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 28 15: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 AB9663A6C0F; Fri, 28 Aug 2009 15:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-0.845, 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 QKdAJ2bxrEQk; Fri, 28 Aug 2009 15:43:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72B243A683A; Fri, 28 Aug 2009 15:43:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhA3N-0001zY-Np for namedroppers-data0@psg.com; Fri, 28 Aug 2009 22:36: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 1MhA3J-0001ys-4b; Fri, 28 Aug 2009 22:36:15 +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=ZAA8eSDGfkPeFh++s065w4uLUGfFwL812Yu4PVoi+Vuk2P2kg18QFtTO ibWlVlHh8TeWj/uksR346SNTgvyGHQ68DzuaZ/Z63pRCtCZGPLK1ocm20 7ZP0JYkhfRXdP0g; 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=1251498973; x=1283034973; 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]=20Editor=20needed|Date:=20Fri,=2028=20Aug=202009=2023 :29:01=20+0200|Message-ID:=20|To:=20Alex =20Bligh=20|Cc:=20Andrew=20Sullivan=20< ajs@shinkuro.com>,=0D=0A=09Alex=20Bligh=20,=0D=0A=09bmanning@vacation.karoshi.com,=0D=0A=09named roppers@ops.ietf.org,=0D=0A=09owner-namedroppers@ops.ietf .org|MIME-Version:=201.0|In-Reply-To:=20<50F285E5AB4C3B72 7FD6395E@nimrod.home>|References:=20<20090825224731.GJ414 2@shinkuro.com>=20<20090827142630.GA14431@vacation.karosh i.com.>=20<49FE02E45D12846B1BE861E2@nimrod.home>=20<20090 828112706.GA6056@vacation.karoshi.com.>=20<50F285E5AB4C3B 727FD6395E@nimrod.home>; bh=i2sjRQXjMWY71+ao0aU+fWcdiatS1wzRWmiX18d7VpI=; b=RAKYZ8WjgXIoNylWd54pi7qJy8uVIADK1WTjqeyoignyrzERxbSG3YZB hglBorlzeo9QhZWPmWNwSJJVjB+VThWhDezgOEy5bhZXvxNiajZ4TXQYT AlSHs44lOfylbfL; X-IronPort-AV: E=Sophos;i="4.44,292,1249254000"; d="scan'208";a="17147095" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 28 Aug 2009 22:29:04 +0100 In-Reply-To: <50F285E5AB4C3B727FD6395E@nimrod.home> References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> <50F285E5AB4C3B727FD6395E@nimrod.home> To: Alex Bligh Cc: Andrew Sullivan , Alex Bligh , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] Editor needed MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 28 Aug 2009 23:29:01 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/08/2009 10:29:09 PM, Serialize complete at 28/08/2009 10:29:09 PM Content-Type: multipart/alternative; boundary="=_alternative 00760392C1257620_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 00760392C1257620_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > "DNS Servers MUST support all mandatory standards track transports, > which at the date of publication of this RFC means both UDP and > TCP, though this list may be added to (or subtracted from) in the > future." >=20 > then let's say that, else it is no more clear than it was before. TCP support is NOT currently mandatory. See =A76.1.3.2 of RFC 1123: "DNS resolvers and recursive servers MUST support UDP, and SHOULD=20 support TCP" We had significant discussion with the IESG when RFC 5625 was in last call = over this question.=20 Ultimately 5625 says "MUST support TCP" for proxies, on the basis that if=20 your client supports TCP, and the recursor supports TCP, it's damned rude=20 of the middle-box sat in the path to sit their refusing to talk to either. Ray --=_alternative 00760392C1257620_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
>   "DNS Servers MUST support all mandatory standards track transports,
>    which at the date of publication of this RFC means both UDP and
>    TCP, though this list may be added to (or subtracted from) in the
>    future."
>
> then let's say that, else it is no more clear than it was before.
TCP support is NOT currently mandatory.

See =A76.1.3.2 of RFC 1123:

  "DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP"

We had significant discussion with the IESG when RFC 5625 was in last call over this question.

Ultimately 5625 says "MUST support TCP" for proxies, on the basis that if your client supports TCP, and the recursor supports TCP, it's damned rude of the middle-box sat in the path to sit their refusing to talk to either.

Ray
--=_alternative 00760392C1257620_=-- From owner-namedroppers@ops.ietf.org Fri Aug 28 15:51: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 F08DE3A6C95; Fri, 28 Aug 2009 15:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Z+HY1HIWoLe8; Fri, 28 Aug 2009 15:51:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A5D93A6A15; Fri, 28 Aug 2009 15:51:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhAEx-0003Zb-NR for namedroppers-data0@psg.com; Fri, 28 Aug 2009 22:48:15 +0000 Received: from [209.85.222.189] (helo=mail-pz0-f189.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhAEu-0003Z5-Eb for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 22:48:13 +0000 Received: by pzk27 with SMTP id 27so2313146pzk.9 for ; Fri, 28 Aug 2009 15:48:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.49.18 with SMTP id w18mr2264749waw.89.1251494404578; Fri, 28 Aug 2009 14:20:04 -0700 (PDT) In-Reply-To: References: <4A9724E7.2070108@isc.org> Date: Fri, 28 Aug 2009 14:20:04 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Aug 28, 2009 at 11:46 AM, Matthew Dempsky wrot= e: > The "trust DJB" elliptic curve follows all of the NIST recommendations > on public key cryptography. =A0Additionally, NSA has withdrawn > recommendations on using RSA. Apologies, Paul Hoffman pointed out to me off list that these statements are inaccurate. It's actually the IEEE that gave recommendations (in P1363) on how to select secure elliptic curves, and it's these recommendations that the standard NIST curves followed in selected the P-256, etc. curves. Curve25519 also follows the recommendations of P1363, but it is not a standard NIST curve. NSA's Suite B standard withdraws their former recommendation for RSA in favor of two of the NIST curves, but it does not recommend Curve25519 either. The intended take away from this is that Curve25519 follows the same recommendations that were used in selecting the elliptic curves that NSA recommends, but I never meant to imply NIST or NSA actually specifically recommend Curve25519. Just that if anyone is comfortable with still using RSA, they should be comfortable with Curve25519. From owner-namedroppers@ops.ietf.org Fri Aug 28 16:08: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 EBF5C3A6F5D; Fri, 28 Aug 2009 16:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 ASkINszMFdfK; Fri, 28 Aug 2009 16:08:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 355833A6CCD; Fri, 28 Aug 2009 16:08:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhAUq-0006FZ-Aq for namedroppers-data0@psg.com; Fri, 28 Aug 2009 23:04: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 1MhAUm-0006El-JG for namedroppers@ops.ietf.org; Fri, 28 Aug 2009 23:04: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 2177CE601E; Fri, 28 Aug 2009 22:07: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 n7SM73bf056581; Sat, 29 Aug 2009 08:07:03 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908282207.n7SM73bf056581@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> <200908272358.n7RNwrvr038970@drugs.dv.isc.org> <20090828144512.GT7821@shinkuro.com> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Fri, 28 Aug 2009 10:45:12 -0400." <20090828144512.GT7821@shinkuro.com> Date: Sat, 29 Aug 2009 08:07:03 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20090828144512.GT7821@shinkuro.com>, Andrew Sullivan writes: > No hat. > > On Fri, Aug 28, 2009 at 09:58:53AM +1000, Mark Andrews wrote: > > > > There is really nothing new in RSA/SHA2. It's just a code point. > > Exactly. And yet draft-ietf-dnsext-dnssec-rsasha256-00 appeared in > Feb of 2006 and we still don't have a code point, because getting a > code point is a heavyweight operation involving a standards action. > > > I really don't expect interoperability problems. This is like > > adding a new RR in terms of difficultly. > > I note that adding a new RR is even easier now: we do it with expert > review. Are you arguing for that route instead of RFC required? No. You were complaining about the lack of interop testing due to there being no code point. I believe none of the vendors are particularly worried about this because there is nothing *new* with rsasha256. We don't have vendors interop test new rdata at the DNS level before deploying. This is all the interop testing of rsasha256 would be. Mark > Best, > > A -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Fri Aug 28 17: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 357DC3A6FB6; Fri, 28 Aug 2009 17:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 P3ElzB8UfD6F; Fri, 28 Aug 2009 17:41:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08A2E3A68B3; Fri, 28 Aug 2009 17:41:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhBv6-000Jt7-Aw for namedroppers-data0@psg.com; Sat, 29 Aug 2009 00:35:52 +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 1MhBv0-000Js0-P8 for namedroppers@ops.ietf.org; Sat, 29 Aug 2009 00:35:49 +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 909A0E601C; Sat, 29 Aug 2009 00:35:45 +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 n7T0ZZdS059327; Sat, 29 Aug 2009 10:35:36 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908290035.n7T0ZZdS059327@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Alex Bligh , Andrew Sullivan , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org From: Mark Andrews References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> <50F285E5AB4C3B727FD6395E@nimrod.home> Subject: Re: [dnsext] Editor needed In-reply-to: Your message of "Fri, 28 Aug 2009 23:29:01 +0200." Date: Sat, 29 Aug 2009 10:35:35 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Ray.Bellis@nominet.org.uk writes: > > > "DNS Servers MUST support all mandatory standards track transports, > > which at the date of publication of this RFC means both UDP and > > TCP, though this list may be added to (or subtracted from) in the > > future." > > > > then let's say that, else it is no more clear than it was before. > > TCP support is NOT currently mandatory. > > See 6.1.3.2 of RFC 1123: > > "DNS resolvers and recursive servers MUST support UDP, and SHOULD > support TCP" And if you read all the discussion in that section it is clear that for any product designed to operate on the Internet the SHOULD becomes a MUST support TCP. I can't see how any vendor could even start to think that TCP could be optional but clearly they did. This leads us to saying that TCP needs to become a MUST as vendors can't be trusted to do the right thing. DISCUSSION: UDP is preferred over TCP for queries because UDP queries have much lower overhead, both in packet count and in connection state. The use of UDP is essential for heavily-loaded servers, especially the root servers. UDP also offers additional robustness, since a resolver can attempt several UDP queries to different servers for the cost of a single TCP query. It is possible for a DNS response to be truncated, although this is a very rare occurrence in the present Internet DNS. Practically speaking, truncation cannot be predicted, since it is data-dependent. The dependencies include the number of RRs in the answer, the size of each RR, and the savings in space realized by the name compression algorithm. As a rule of thumb, truncation in NS and MX lists should not occur for answers containing 15 or fewer RRs. Whether it is possible to use a truncated answer depends on the application. A mailer must not use a truncated MX response, since this could lead to mail loops. Responsible practices can make UDP suffice in the vast majority of cases. Name servers must use compression in responses. Resolvers must differentiate truncation of the Additional section of a response (which only loses extra information) from truncation of the Answer section (which for MX records renders the response unusable by mailers). Database administrators should list only a reasonable number of primary names in lists of name servers, MX alternatives, etc. However, it is also clear that some new DNS record types defined in the future will contain information exceeding the 512 byte limit that applies to UDP, and hence will require TCP. Thus, resolvers and name servers should implement TCP services as a backup to UDP today, with the knowledge that they will require the TCP service in the future. > We had significant discussion with the IESG when RFC 5625 was in last call > over this question. > > Ultimately 5625 says "MUST support TCP" for proxies, on the basis that if > your client supports TCP, and the recursor supports TCP, it's damned rude > of the middle-box sat in the path to sit their refusing to talk to either. > > Ray > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From conjoinlwci87@piazzapropmgt.com Fri Aug 28 18:52: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 43E4B3A68C5; Fri, 28 Aug 2009 18:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.231 X-Spam-Level: X-Spam-Status: No, score=-33.231 tagged_above=-999 required=5 tests=[AWL=-5.185, BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, 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_NJABL_PROXY=1.643, 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, URIBL_BLACK=20, URIBL_JP_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 2mg2k+CG20qY; Fri, 28 Aug 2009 18:52:08 -0700 (PDT) Received: from 201-43-92-225.dsl.telesp.net.br (201-43-92-225.dsl.telesp.net.br [201.43.92.225]) by core3.amsl.com (Postfix) with ESMTP id DD7A73A6863; Fri, 28 Aug 2009 18:52:07 -0700 (PDT) Received: from 201.43.92.225 by mail.piazzapropmgt.com; Fri, 28 Aug 2009 22:50:25 -0300 Date: Fri, 28 Aug 2009 22:50:25 -0300 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: produce a proper body with healthy solution acai its free Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
In the end I need to tell you that I have been using this for 3 weeks, its great
 
The ACAl is one of the world's most interesting and unique foods. It may also be one of its healthiest. Chock-full of antioxidants, amino acids, AND essential fatty acids, the tiny little ACAl Berry packs a nutritional wallop rarely seen in the natural world. In fact, some experts consider it to be the world's most "complete" natural food.


From conjoinlwci87@piazzapropmgt.com Fri Aug 28 18:52: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 43E4B3A68C5; Fri, 28 Aug 2009 18:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.231 X-Spam-Level: X-Spam-Status: No, score=-33.231 tagged_above=-999 required=5 tests=[AWL=-5.185, BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, 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_NJABL_PROXY=1.643, 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, URIBL_BLACK=20, URIBL_JP_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 2mg2k+CG20qY; Fri, 28 Aug 2009 18:52:08 -0700 (PDT) Received: from 201-43-92-225.dsl.telesp.net.br (201-43-92-225.dsl.telesp.net.br [201.43.92.225]) by core3.amsl.com (Postfix) with ESMTP id DD7A73A6863; Fri, 28 Aug 2009 18:52:07 -0700 (PDT) Received: from 201.43.92.225 by mail.piazzapropmgt.com; Fri, 28 Aug 2009 22:50:25 -0300 Date: Fri, 28 Aug 2009 22:50:25 -0300 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: produce a proper body with healthy solution acai its free Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
In the end I need to tell you that I have been using this for 3 weeks, its great
 
The ACAl is one of the world's most interesting and unique foods. It may also be one of its healthiest. Chock-full of antioxidants, amino acids, AND essential fatty acids, the tiny little ACAl Berry packs a nutritional wallop rarely seen in the natural world. In fact, some experts consider it to be the world's most "complete" natural food.


From owner-namedroppers@ops.ietf.org Sat Aug 29 00:00: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 CFEC13A691D; Sat, 29 Aug 2009 00:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.796 X-Spam-Level: **** X-Spam-Status: No, score=4.796 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_20=-0.74, 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 GjiOKM4cCjBr; Sat, 29 Aug 2009 00:00:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0D853A6BED; Sat, 29 Aug 2009 00:00:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhHiC-000Gbs-Hy for namedroppers-data0@psg.com; Sat, 29 Aug 2009 06:46:56 +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 1MhHi7-000GEa-PT for namedroppers@ops.ietf.org; Sat, 29 Aug 2009 06:46:54 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MhHhw-0001kB-7H; Sat, 29 Aug 2009 07:46:40 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MhHhv-0005Jr-Jo; Sat, 29 Aug 2009 07:46:39 +0100 Message-ID: <03A45FD04A184E818272F46E1831086C@localhost> From: "George Barwood" To: , "Mark Andrews" Cc: "Alex Bligh" , "Andrew Sullivan" , , References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> <50F285E5AB4C3B727FD6395E@nimrod.home> <200908290035.n7T0ZZdS059327@drugs.dv.isc.org> Subject: Re: [dnsext] Editor needed Date: Sat, 29 Aug 2009 07:46:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: VWx0aW1hdGVseSBETlMgcHJveHkgc2VydmVycyBhcmUgImV2aWwiIGJlY2F1c2UgdGhleSBoYXZl IHRvIGJlIHVwZGF0ZWQgaWYgDQp0aGUgRE5TIHRyYW5zcG9ydCBwcm90b2NvbCBjaGFuZ2VzIGlu IGFueSB3YXkuDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGVzZSBwcm94aWVzIGhhdmUg Y29tZSBhYm91dCBkdWUgdG8gREhDUCB0aW1pbmcgaXNzdWVzLg0KDQpUaGF0IGlzLCB0aGUgbGlz dCBvZiBETlMgc2VydmVycyBpcyBzZW50IG92ZXIgREhDUCBhdCBhIHRpbWUgd2hlbiB0aGUgbWlk ZGxlIGJveA0KbWF5IG5vdCBoYXZlIHJlY2VpdmVkIHRoZSBsaXN0IG9mIEROUyBzZXJ2ZXJzIGZy b20gdGhlIFdBTi4NCg0KVW5mb3J0dW5hdGVseSBJJ20gbm90IHRvbyBmYW1pbGlhciB3aXRoIHRo ZSBkZXRhaWxzIG9mIERIQ1AsIGJ1dCB0aGUgZml4IHdvdWxkIHNlZW0gdG8gYmUgc29tZXRoaW5n IHJvdWdobHkgYXMgZm9sbG93czoNCg0KSWYgdGhlIGJveCBpcyBjb25uZWN0ZWQgdG8gdGhlIFdB TiwgaXQgbXVzdCByZXR1cm4gdGhlIFdBTiBETlMgc2VydmVycywgYW5kIG5vdCBhIHByb3h5Lg0K DQpDbGllbnRzIHRoYXQgcGVyZm9ybSBESENQIGJlZm9yZSB0aGUgV0FOIGlzIGF2YWlsYWJsZSwg c2hvdWxkIHJldHJ5IHRoZSBESENQIHByb2Nlc3MgYWZ0ZXIgZGlzY292ZXJpbmcgYSBwcm94eSB3 aXRoIGxpbWl0ZWQgY2FwYWJpbGl0aWVzLCBhbmQgc2hvdWxkIGJlIGd1YXJ1bnRlZWQgdG8gb2J0 YWluIGEgZnVsbHkgZnVuY3Rpb25hbCBETlMgc2VydmVyIHByb3ZpZGVkIHRoYXQgdGhlIFdBTiBp cyBub3cgZnVuY3Rpb25hbC4NCg0KSW4gb3RoZXIgd29yZHMgaXQncyBhIGNsYXJpZmljYXRpb24g b2YgREhDUCBpbXBsZW1lbnRpb24gdGhhdCBpcyByZXF1aXJlZCAoIG9yIGFuIHVwZGF0ZSB0byBE SENQIGlmIHdoYXQgSSBoYXZlIGp1c3QgZGVzY3JpYmVkIGlzIGluIGZhY3Qgbm90IGNvbXBhdGli bGUgd2l0aCB0aGUgREhDUCBzdGFuZGFyZCApLg0KDQpUaGlzIHdvdWxkIGJlIGEgcGVybWFuZW50 IGZpeCwgd2hlcmVhcyBtYW5kYXRpbmcgc3VwcG9ydCBmb3Igc3BlY2lmaWMgcHJvdG9jb2xzIGlz IGEgdGVtcG9yYXJ5IHBhdGNoLiBBbnkgSVB2NiBpc3N1ZXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBh dCB0aGUgc2FtZSB0aW1lLg0KDQpHZW9yZ2U= From edge@goldrush.com Sat Aug 29 11:48: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 541B93A6C0D; Sat, 29 Aug 2009 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hceBQXU+BQ+y; Sat, 29 Aug 2009 11:48:32 -0700 (PDT) Received: from goldrush.com (HSI-KBW-078-043-161-216.hsi4.kabel-badenwuerttemberg.de [78.43.161.216]) by core3.amsl.com (Postfix) with SMTP id DF1FD3A6979; Sat, 29 Aug 2009 11:47:33 -0700 (PDT) Message-ID: Date: Sat, 29 Aug 2009 15:32:32 -0400 Reply-To: "faas " From: "faas " User-Agent: Mozilla 3.04 (Macintosh; I; 68K) MIME-Version: 1.0 To: Subject: Tired of the shop make twice as much Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ldap-dir@ietf.org outstanding and proven track record You Must See it To Believe It GET the Answers phone 8882063060 Jqun Sat, 29 Aug 2009 15:32:32 -0400 From owner-namedroppers@ops.ietf.org Sat Aug 29 13:13: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 236803A68E0; Sat, 29 Aug 2009 13:13:34 -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=-0.198, 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 pfzQqUHZ0Kt4; Sat, 29 Aug 2009 13:13:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FD503A6801; Sat, 29 Aug 2009 13:12:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhUBQ-0001Ml-Er for namedroppers-data0@psg.com; Sat, 29 Aug 2009 20:05:56 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhUBM-0001LW-0G for namedroppers@ops.ietf.org; Sat, 29 Aug 2009 20:05:54 +0000 Received: (qmail 7917 invoked by uid 399); 29 Aug 2009 20:05:47 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Aug 2009 20:05:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A998A15.6050602@dougbarton.us> Date: Sat, 29 Aug 2009 13:05:41 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> In-Reply-To: <4CB0582F89044745BF1D1EBF09E549B6@localhost> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: George Barwood wrote: > I very tentatively suggest a new tld, say For my money, anything involving a new TLD is a non-starter, but read on. > localservers > > could be defined. A query from a stub resolver to the proxy of > > localservers A > > would return the IP address of a fully functional local cache. This sounds like an ideal use case for multicast DNS. Doug From owner-namedroppers@ops.ietf.org Sat Aug 29 21:20: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 73BAA3A686A; Sat, 29 Aug 2009 21:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_20=-0.74, 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 zRvSaYPQM5vM; Sat, 29 Aug 2009 21:20:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 685BE3A67E5; Sat, 29 Aug 2009 21:20:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mhbln-000DsB-A5 for namedroppers-data0@psg.com; Sun, 30 Aug 2009 04:11:59 +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 1Mhblj-000DrT-AI for namedroppers@ops.ietf.org; Sun, 30 Aug 2009 04:11:57 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MhblQ-0006Xl-5W; Sun, 30 Aug 2009 05:11:36 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MhblL-0000SN-LG; Sun, 30 Aug 2009 05:11:31 +0100 Message-ID: <32C8D3E06F9246C0852306A8EF412641@localhost> From: "George Barwood" To: "George Barwood" , , "Mark Andrews" Cc: "Alex Bligh" , "Andrew Sullivan" , , References: <20090825224731.GJ4142@shinkuro.com> <20090827142630.GA14431@vacation.karoshi.com.> <49FE02E45D12846B1BE861E2@nimrod.home> <20090828112706.GA6056@vacation.karoshi.com.> <50F285E5AB4C3B727FD6395E@nimrod.home> <200908290035.n7T0ZZdS059327@drugs.dv.isc.org> <03A45FD04A184E818272F46E1831086C@localhost> Subject: Re: [dnsext] Editor needed Date: Sun, 30 Aug 2009 05:11:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: V2VsbCwgSSBzaG91bGQgaGF2ZSBjb25zdWx0ZWQgdGhlIHJlY2VudGx5IHB1Ymxpc2hlZCBSRkM1 NjI1DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU2MjUjc2VjdGlvbi01DQoNCndo aWNoIGRlc2NyaWJlcyBob3cgaXQgY2FuIHdvcmsgdXNpbmcgREhDUCBsZWFzZSBleHBpcnksDQph bHRob3VnaCBtYXliZSB0aGUgbGVhc2UgZXhwaXJ5IG1lY2hhbmlzbSBpcyBub3QgcXVpdGUgaWRl YWwsDQpzbyBtYXliZSByZXNvbHZlcnMgc2hvdWxkIHRha2UgYWN0aXZlIHN0ZXBzICh2aWEgREhD UCkgd2hlbg0KdGhleSBkaXNjb3ZlciBhbiB1bnNhdGlzZmFjdG9yeSBwcm94eS4NCg0KUkZDNTYy NSBjb3VsZCBwZXJoYXBzIGhhdmUgYmVlbiBtb3JlIHN0cm9uZ2x5IHdvcmRlZCB3aXRoIA0KcmVn YXJkcyB0byBwcm94aWVzIC0gdGhhdCBpcyBpdCBkb2VzIGV4cGxhaW4gdGhleSBhcmUgYmFkLCBi dXQgdGhlbg0KZGVzY3JpYmVzIGhvdyB0aGV5IHNob3VsZCBiZWhhdmUsIHJhdGhlciB0aGFuIGNv bmRlbW5pbmcgdGhlbQ0Kb3V0cmlnaHQsIHNvIGEgY2FzdWFsIHJlYWRpbmcgKGFuZCB0aGUgYWJz dHJhY3Qgb24gaXQncyBvd24pIG1pZ2h0DQpsZWFkIHRvIHRoZSB3cm9uZyBpbXByZXNzaW9uLg0K DQpSZWdhcmRsZXNzLCBJIHRoaW5rIGFuIEVETlMgb3B0aW9uIHRvIGJvb3RzdHJhcCBhIGdvb2Qg bGlzdA0Kb2YgRE5TIHNlcnZlcnMgdGhyb3VnaCB0aGUgY3VycmVudGx5IGRlcGxveWVkIG1pZGRs ZWJveGVzIGNvdWxkIGJlDQp2ZXJ5IHVzZWZ1bCBpbiBwcmFjdGljZSwgYW5kIGdpdmUgYSBoaWdo IHJldHVybiBvbiBpbnZlc3RtZW50Lg0KDQpHZW9yZ2UNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25k ZXIuY28udWs+DQpUbzogPFJheS5CZWxsaXNAbm9taW5ldC5vcmcudWs+OyAiTWFyayBBbmRyZXdz IiA8bWFya2FAaXNjLm9yZz4NCkNjOiAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+OyAi QW5kcmV3IFN1bGxpdmFuIiA8YWpzQHNoaW5rdXJvLmNvbT47IDxibWFubmluZ0B2YWNhdGlvbi5r YXJvc2hpLmNvbT47IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogU2F0dXJkYXks IEF1Z3VzdCAyOSwgMjAwOSA3OjQ2IEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRWRpdG9yIG5l ZWRlZCANCg0KDQo+IFVsdGltYXRlbHkgRE5TIHByb3h5IHNlcnZlcnMgYXJlICJldmlsIiBiZWNh dXNlIHRoZXkgaGF2ZSB0byBiZSB1cGRhdGVkIGlmIA0KPiB0aGUgRE5TIHRyYW5zcG9ydCBwcm90 b2NvbCBjaGFuZ2VzIGluIGFueSB3YXkuDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg dGhlc2UgcHJveGllcyBoYXZlIGNvbWUgYWJvdXQgZHVlIHRvIERIQ1AgdGltaW5nIGlzc3Vlcy4N Cj4gDQo+IFRoYXQgaXMsIHRoZSBsaXN0IG9mIEROUyBzZXJ2ZXJzIGlzIHNlbnQgb3ZlciBESENQ IGF0IGEgdGltZSB3aGVuIHRoZSBtaWRkbGUgYm94DQo+IG1heSBub3QgaGF2ZSByZWNlaXZlZCB0 aGUgbGlzdCBvZiBETlMgc2VydmVycyBmcm9tIHRoZSBXQU4uDQo+IA0KPiBVbmZvcnR1bmF0ZWx5 IEknbSBub3QgdG9vIGZhbWlsaWFyIHdpdGggdGhlIGRldGFpbHMgb2YgREhDUCwgYnV0IHRoZSBm aXggd291bGQgc2VlbSB0byBiZSBzb21ldGhpbmcgcm91Z2hseSBhcyBmb2xsb3dzOg0KPiANCj4g SWYgdGhlIGJveCBpcyBjb25uZWN0ZWQgdG8gdGhlIFdBTiwgaXQgbXVzdCByZXR1cm4gdGhlIFdB TiBETlMgc2VydmVycywgYW5kIG5vdCBhIHByb3h5Lg0KPiANCj4gQ2xpZW50cyB0aGF0IHBlcmZv cm0gREhDUCBiZWZvcmUgdGhlIFdBTiBpcyBhdmFpbGFibGUsIHNob3VsZCByZXRyeSB0aGUgREhD UCBwcm9jZXNzIGFmdGVyIGRpc2NvdmVyaW5nIGEgcHJveHkgd2l0aCBsaW1pdGVkIGNhcGFiaWxp dGllcywgYW5kIHNob3VsZCBiZSBndWFydW50ZWVkIHRvIG9idGFpbiBhIGZ1bGx5IGZ1bmN0aW9u YWwgRE5TIHNlcnZlciBwcm92aWRlZCB0aGF0IHRoZSBXQU4gaXMgbm93IGZ1bmN0aW9uYWwuDQo+ IA0KPiBJbiBvdGhlciB3b3JkcyBpdCdzIGEgY2xhcmlmaWNhdGlvbiBvZiBESENQIGltcGxlbWVu dGlvbiB0aGF0IGlzIHJlcXVpcmVkICggb3IgYW4gdXBkYXRlIHRvIERIQ1AgaWYgd2hhdCBJIGhh dmUganVzdCBkZXNjcmliZWQgaXMgaW4gZmFjdCBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBESENQ IHN0YW5kYXJkICkuDQo+IA0KPiBUaGlzIHdvdWxkIGJlIGEgcGVybWFuZW50IGZpeCwgd2hlcmVh cyBtYW5kYXRpbmcgc3VwcG9ydCBmb3Igc3BlY2lmaWMgcHJvdG9jb2xzIGlzIGEgdGVtcG9yYXJ5 IHBhdGNoLiBBbnkgSVB2NiBpc3N1ZXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBhdCB0aGUgc2FtZSB0 aW1lLg0KPiANCj4gR2Vvcmdl From owner-namedroppers@ops.ietf.org Sat Aug 29 21:20: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 1897A3A67E5; Sat, 29 Aug 2009 21:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.349 X-Spam-Level: **** X-Spam-Status: No, score=4.349 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZJjfMrtc9q9; Sat, 29 Aug 2009 21:20:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E1863A686A; Sat, 29 Aug 2009 21:20:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhbqS-000EVc-O8 for namedroppers-data0@psg.com; Sun, 30 Aug 2009 04:16:48 +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 1MhbqO-000EUk-Pe for namedroppers@ops.ietf.org; Sun, 30 Aug 2009 04:16:46 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MhbqN-0007j1-Lo; Sun, 30 Aug 2009 05:16:43 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MhbqN-0006ze-65; Sun, 30 Aug 2009 05:16:43 +0100 Message-ID: From: "George Barwood" To: "Doug Barton" Cc: References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> Subject: Re: [dnsext] Working around proxies Date: Sun, 30 Aug 2009 05:16:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRvdWcgQmFydG9uIiA8ZG91 Z2JAZG91Z2JhcnRvbi51cz4NClRvOiAiR2VvcmdlIEJhcndvb2QiIDxnZW9yZ2UuYmFyd29vZEBi bHVleW9uZGVyLmNvLnVrPg0KQ2M6IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDog U2F0dXJkYXksIEF1Z3VzdCAyOSwgMjAwOSA5OjA1IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0g V29ya2luZyBhcm91bmQgcHJveGllcw0KDQoNCj4gR2VvcmdlIEJhcndvb2Qgd3JvdGU6DQo+IA0K Pj4gSSB2ZXJ5IHRlbnRhdGl2ZWx5IHN1Z2dlc3QgYSBuZXcgdGxkLCBzYXkNCj4gDQo+IEZvciBt eSBtb25leSwgYW55dGhpbmcgaW52b2x2aW5nIGEgbmV3IFRMRCBpcyBhIG5vbi1zdGFydGVyLCBi dXQgcmVhZCBvbi4NCg0KSSdkIGJlIGludGVyZXN0ZWQgaW4gcmVhc29ucyB3aHkgeW91IHRoaW5r IGEgbmV3IFRMRCBpcyBhIG5vbi1zdGFydGVyLA0KYWx0aG91Z2ggSSBub3cgdGhpbmsgYW4gRURO UyBvcHRpb24gaXMgcHJvYmFibHkgYSBtb3JlIHN1aXRhYmxlIHNvbHV0aW9uLg0KIA0KPj4gbG9j YWxzZXJ2ZXJzDQo+PiANCj4+IGNvdWxkIGJlIGRlZmluZWQuIEEgcXVlcnkgZnJvbSBhIHN0dWIg cmVzb2x2ZXIgdG8gdGhlIHByb3h5IG9mDQo+PiANCj4+IGxvY2Fsc2VydmVycyBBDQo+PiANCj4+ IHdvdWxkIHJldHVybiB0aGUgSVAgYWRkcmVzcyBvZiBhIGZ1bGx5IGZ1bmN0aW9uYWwgbG9jYWwg Y2FjaGUuDQo+IA0KPiBUaGlzIHNvdW5kcyBsaWtlIGFuIGlkZWFsIHVzZSBjYXNlIGZvciBtdWx0 aWNhc3QgRE5TLg0KDQpQbGVhc2UgZXhwbGFpbiA6IEkgZG9uJ3Qgc2VlIGhvdyBtdWx0aWNhc3Qg RE5TIGNhbiBoZWxwIGhlcmUsDQpidXQgbWF5YmUgSSdtIG1pc3Npbmcgc29tZXRoaW5nLg0KDQpH ZW9yZ2UNCiANCj4gRG91Zw0KPg== From owner-namedroppers@ops.ietf.org Sun Aug 30 11:31: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 434143A6ACA; Sun, 30 Aug 2009 11:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.532 X-Spam-Level: X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJKYpJdRkY-j; Sun, 30 Aug 2009 11:31:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A6F63A68B6; Sun, 30 Aug 2009 11:31:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mhp4n-000I6M-Jp for namedroppers-data0@psg.com; Sun, 30 Aug 2009 18:24:29 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mhp4i-000I58-Pi for namedroppers@ops.ietf.org; Sun, 30 Aug 2009 18:24:27 +0000 Received: (qmail 3254 invoked by uid 399); 30 Aug 2009 18:24:21 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Aug 2009 18:24:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A9AC3CF.4000106@dougbarton.us> Date: Sun, 30 Aug 2009 11:24:15 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: George Barwood wrote: > ----- Original Message ----- > From: "Doug Barton" > To: "George Barwood" > Cc: > Sent: Saturday, August 29, 2009 9:05 PM > Subject: Re: [dnsext] Working around proxies > > >> George Barwood wrote: >> >>> I very tentatively suggest a new tld, say >> For my money, anything involving a new TLD is a non-starter, but read on. > > I'd be interested in reasons why you think a new TLD is a non-starter, There are only 2 ways to "get" a new TLD for this purpose. The first is to go through the ICANN new TLD process. The complexity of this, even if we could get ICANN to waive the fees associated, are daunting to say the least, would take a very long time to complete, and it's not likely to be approved in any case. The other way is for "us" to appropriate one, either by starting to use it (ala .lan or .local) which would be very bad manners; or by attempting some sort of IETF process to "justify" it's use, which would lead to a turf war with ICANN that there is no reason for. Of course, I also think that your suggestion is a truly horrible idea, so my opinion on all of the above may be biased, but I doubt it. >> This sounds like an ideal use case for multicast DNS. > > Please explain : I don't see how multicast DNS can help here, > but maybe I'm missing something. Well then I guess my next question is, "How much do you know about mDNS and how it operates?" A simple response to your question would be that the end-user/client box that needs to know the addresses for its local resolvers broadcasts the query, and the mDNS process(es) running on the local resolver(s) sends out a response that says "Here I am!" There is no need to create new functionality that would actually be much more limited than the existing solution that mDNS already provides. And to save you a response, yes, I realize that my solution to the problem you're describing involves admins setting up something new. But that's still a lot less person-hours than trying to redefine the protocol in the way you describe, even if I thought you had a valid problem statement which I don't think you do. Additionally, you seem to be proposing a world in which there are none of the other usual mechanisms for this like DHCP, although for the life of me I can't figure out why. Doug From owner-namedroppers@ops.ietf.org Sun Aug 30 15:05: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 167933A6CD5; Sun, 30 Aug 2009 15:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.168 X-Spam-Level: **** X-Spam-Status: No, score=4.168 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_50=0.001, 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 yQkPHHD0W+RB; Sun, 30 Aug 2009 15:05:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6971128C16D; Sun, 30 Aug 2009 15:05:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhsR3-00063B-Gx for namedroppers-data0@psg.com; Sun, 30 Aug 2009 21:59:41 +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 1MhsQy-00060t-Pd for namedroppers@ops.ietf.org; Sun, 30 Aug 2009 21:59:39 +0000 Received: (qmail 21205 invoked from network); 30 Aug 2009 22:09:28 -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 Aug 2009 22:09:28 -0000 Message-ID: <4A9AF619.3020905@necom830.hpcl.titech.ac.jp> Date: Mon, 31 Aug 2009 06:58:49 +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: Doug Barton CC: George Barwood , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> In-Reply-To: <4A9AC3CF.4000106@dougbarton.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Doug Barton wrote: >>>This sounds like an ideal use case for multicast DNS. >>Please explain : I don't see how multicast DNS can help here, >>but maybe I'm missing something. > Well then I guess my next question is, "How much do you know about > mDNS and how it operates?" A simple response to your question would be > that the end-user/client box that needs to know the addresses for its > local resolvers broadcasts the query, and the mDNS process(es) running > on the local resolver(s) sends out a response that says "Here I am!" If you are not talking about link local multicast (you should not, because local resolvers are often located somewhere beyond local routers), multicast routing requires a lot of configuration, which is a lot more complex than DNS configuration, that mDNS is no solution. For example, if you use PIM-SM, you have to configure information on an unicast address of rendez-vous point corresponding to a multicast address. In general it is a broken idea to use multicast for autoconfiguration. Having a globally unique anycast addresses for default local resolvers is a better solution. Masataka Ohta From owner-namedroppers@ops.ietf.org Sun Aug 30 16:05: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 776343A6D5A; Sun, 30 Aug 2009 16:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PklhjPxZzjad; Sun, 30 Aug 2009 16:05:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41D103A6C0D; Sun, 30 Aug 2009 16:05:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhtNs-000Imv-63 for namedroppers-data0@psg.com; Sun, 30 Aug 2009 23:00:28 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MhtNn-000ImT-Vl for namedroppers@ops.ietf.org; Sun, 30 Aug 2009 23:00:25 +0000 Received: from [192.168.100.85] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 6E1EEC2DA5; Mon, 31 Aug 2009 00:00:21 +0100 (BST) Date: Mon, 31 Aug 2009 00:00:22 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Doug Barton , George Barwood cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Working around proxies Message-ID: In-Reply-To: <4A9AC3CF.4000106@dougbarton.us> References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 30 August 2009 11:24:15 -0700 Doug Barton wrote: > There are only 2 ways to "get" a new TLD for this purpose. The first > is to go through the ICANN new TLD process. The complexity of this, > even if we could get ICANN to waive the fees associated, are daunting > to say the least, would take a very long time to complete, and it's > not likely to be approved in any case. The other way is for "us" to > appropriate one, either by starting to use it (ala .lan or .local) > which would be very bad manners; or by attempting some sort of IETF > process to "justify" it's use, which would lead to a turf war with > ICANN that there is no reason for. Technically speaking, a 3rd way to do an equivalent thing would be a subdomain of .arpa. I am not suggesting this is necessarily a good idea. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sun Aug 30 18:59: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 4BA073A69E5; Sun, 30 Aug 2009 18:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 gJWd7VXY-bio; Sun, 30 Aug 2009 18:59:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34A5E3A683F; Sun, 30 Aug 2009 18:59:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mhw5W-000HFU-16 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 01:53: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 1Mhw5R-000HDr-UX for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 01:53:39 +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 AEBE5E601C; Mon, 31 Aug 2009 01: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 n7V1rUhR088199; Mon, 31 Aug 2009 11:53:32 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908310153.n7V1rUhR088199@drugs.dv.isc.org> To: Alex Bligh Cc: Doug Barton , George Barwood , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Mon, 31 Aug 2009 00:00:22 +0100." Date: Mon, 31 Aug 2009 11:53:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Alex Bligh writes: > > There are only 2 ways to "get" a new TLD for this purpose. The first > > is to go through the ICANN new TLD process. The complexity of this, > > even if we could get ICANN to waive the fees associated, are daunting > > to say the least, would take a very long time to complete, and it's > > not likely to be approved in any case. The other way is for "us" to > > appropriate one, either by starting to use it (ala .lan or .local) > > which would be very bad manners; or by attempting some sort of IETF > > process to "justify" it's use, which would lead to a turf war with > > ICANN that there is no reason for. > > Technically speaking, a 3rd way to do an equivalent thing would be > a subdomain of .arpa. I am not suggesting this is necessarily > a good idea. > > -- > Alex Bligh The whole idea is bad. You don't design protocol extension to work around devices which are breaking the protocol. You fix/replace the broken devices. If the working group wants to be productive the members should look at the devices they have access to and publish which ones work correctly and to what extent and which ones don't. This will allow consumers to buy boxes which work. The report should include hardware and firmware revision numbers so that manufactures can reproduce the reported problems if desired. Working should include those that will work after a firmware upgrade along with the firmware revision required. We should encourage manufactures to report products that they believe work correctly. Ray's report would be a useful starting point, if that is allowable. Ray do you have the necessary details on the boxes you tested? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Sun Aug 30 23:28: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 A8B473A6A10; Sun, 30 Aug 2009 23:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.866 X-Spam-Level: **** X-Spam-Status: No, score=4.866 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_20=-0.74, 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 6sgclaKhIK3D; Sun, 30 Aug 2009 23:28:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9848C3A68BA; Sun, 30 Aug 2009 23:28:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi0Gy-000279-A3 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 06:21:48 +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 1Mi0Gu-00026a-Lx for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 06:21:46 +0000 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Mi0Gf-0002I0-Us; Mon, 31 Aug 2009 07:21:29 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mi0Gf-0003WK-9Q; Mon, 31 Aug 2009 07:21:29 +0100 Message-ID: <1009805BA49B4D22BAD2E408B06FA87B@localhost> From: "George Barwood" To: "Alex Bligh" , "Mark Andrews" Cc: "Doug Barton" , References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Mon, 31 Aug 2009 07:21:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkFsZXggQmxpZ2giIDxhbGV4QGFsZXgub3JnLnVrPg0KQ2M6ICJE b3VnIEJhcnRvbiIgPGRvdWdiQGRvdWdiYXJ0b24udXM+OyAiR2VvcmdlIEJhcndvb2QiIDxnZW9y Z2UuYmFyd29vZEBibHVleW9uZGVyLmNvLnVrPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+ DQpTZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAwOSAyOjUzIEFNDQpTdWJqZWN0OiBSZTogW2Ru c2V4dF0gV29ya2luZyBhcm91bmQgcHJveGllcyANCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDxCM0FG NEI1MDlDN0ExMkUzQzBGRjMyNzlAbmltcm9kLmxvY2FsPiwgQWxleCBCbGlnaCB3cml0ZXM6DQo+ PiA+IFRoZXJlIGFyZSBvbmx5IDIgd2F5cyB0byAiZ2V0IiBhIG5ldyBUTEQgZm9yIHRoaXMgcHVy cG9zZS4gVGhlIGZpcnN0DQo+PiA+IGlzIHRvIGdvIHRocm91Z2ggdGhlIElDQU5OIG5ldyBUTEQg cHJvY2Vzcy4gVGhlIGNvbXBsZXhpdHkgb2YgdGhpcywNCj4+ID4gZXZlbiBpZiB3ZSBjb3VsZCBn ZXQgSUNBTk4gdG8gd2FpdmUgdGhlIGZlZXMgYXNzb2NpYXRlZCwgYXJlIGRhdW50aW5nDQo+PiA+ IHRvIHNheSB0aGUgbGVhc3QsIHdvdWxkIHRha2UgYSB2ZXJ5IGxvbmcgdGltZSB0byBjb21wbGV0 ZSwgYW5kIGl0J3MNCj4+ID4gbm90IGxpa2VseSB0byBiZSBhcHByb3ZlZCBpbiBhbnkgY2FzZS4g VGhlIG90aGVyIHdheSBpcyBmb3IgInVzIiB0bw0KPj4gPiBhcHByb3ByaWF0ZSBvbmUsIGVpdGhl ciBieSBzdGFydGluZyB0byB1c2UgaXQgKGFsYSAubGFuIG9yIC5sb2NhbCkNCj4+ID4gd2hpY2gg d291bGQgYmUgdmVyeSBiYWQgbWFubmVyczsgb3IgYnkgYXR0ZW1wdGluZyBzb21lIHNvcnQgb2Yg SUVURg0KPj4gPiBwcm9jZXNzIHRvICJqdXN0aWZ5IiBpdCdzIHVzZSwgd2hpY2ggd291bGQgbGVh ZCB0byBhIHR1cmYgd2FyIHdpdGgNCj4+ID4gSUNBTk4gdGhhdCB0aGVyZSBpcyBubyByZWFzb24g Zm9yLg0KPj4gDQo+PiBUZWNobmljYWxseSBzcGVha2luZywgYSAzcmQgd2F5IHRvIGRvIGFuIGVx dWl2YWxlbnQgdGhpbmcgd291bGQgYmUNCj4+IGEgc3ViZG9tYWluIG9mIC5hcnBhLiBJIGFtIG5v dCBzdWdnZXN0aW5nIHRoaXMgaXMgbmVjZXNzYXJpbHkNCj4+IGEgZ29vZCBpZGVhLg0KPj4gDQo+ PiAtLSANCj4+IEFsZXggQmxpZ2gNCj4gDQo+IFRoZSB3aG9sZSBpZGVhIGlzIGJhZC4gIFlvdSBk b24ndCBkZXNpZ24gcHJvdG9jb2wgZXh0ZW5zaW9uIHRvIHdvcmsNCj4gYXJvdW5kIGRldmljZXMg d2hpY2ggYXJlIGJyZWFraW5nIHRoZSBwcm90b2NvbC4gIFlvdSBmaXgvcmVwbGFjZQ0KPiB0aGUg YnJva2VuIGRldmljZXMuDQoNClRoZSBkZXZpY2VzIGFyZSBOT1QgYnJva2VuLiBUaGUgcHJvdG9j b2wgc2hvdWxkIGhhdmUgYmVlbiBkZXNpZ25lZA0KdG8gYmUgY29tcGF0aWJsZSB3aXRoIHRoZSBl eGlzdGluZyBpbnN0YWxsZWQgYmFzZS4gSSdtIHNpbXBseSBwcm9wb3NpbmcNCnRvIGZpeCB0aGUg cHJvdG9jb2wsIHdoaWNoIGlzIHdoYXQgaXMgcmVhbGx5IGJyb2tlbi4NCiANCj4gSWYgdGhlIHdv cmtpbmcgZ3JvdXAgd2FudHMgdG8gYmUgcHJvZHVjdGl2ZSB0aGUgbWVtYmVycyBzaG91bGQgbG9v aw0KPiBhdCB0aGUgZGV2aWNlcyB0aGV5IGhhdmUgYWNjZXNzIHRvIGFuZCBwdWJsaXNoIHdoaWNo IG9uZXMgd29yaw0KPiBjb3JyZWN0bHkgYW5kIHRvIHdoYXQgZXh0ZW50IGFuZCB3aGljaCBvbmVz IGRvbid0LiAgVGhpcyB3aWxsIGFsbG93DQo+IGNvbnN1bWVycyB0byBidXkgYm94ZXMgd2hpY2gg d29yay4gIFRoZSByZXBvcnQgc2hvdWxkIGluY2x1ZGUNCj4gaGFyZHdhcmUgYW5kIGZpcm13YXJl IHJldmlzaW9uIG51bWJlcnMgc28gdGhhdCBtYW51ZmFjdHVyZXMgY2FuDQo+IHJlcHJvZHVjZSB0 aGUgcmVwb3J0ZWQgcHJvYmxlbXMgaWYgZGVzaXJlZC4NCj4gDQo+IFdvcmtpbmcgc2hvdWxkIGlu Y2x1ZGUgdGhvc2UgdGhhdCB3aWxsIHdvcmsgYWZ0ZXIgYSBmaXJtd2FyZSB1cGdyYWRlDQo+IGFs b25nIHdpdGggdGhlIGZpcm13YXJlIHJldmlzaW9uIHJlcXVpcmVkLg0KPiANCj4gV2Ugc2hvdWxk IGVuY291cmFnZSBtYW51ZmFjdHVyZXMgdG8gcmVwb3J0IHByb2R1Y3RzIHRoYXQgdGhleSBiZWxp ZXZlDQo+IHdvcmsgY29ycmVjdGx5Lg0KPiANCj4gUmF5J3MgcmVwb3J0IHdvdWxkIGJlIGEgdXNl ZnVsIHN0YXJ0aW5nIHBvaW50LCBpZiB0aGF0IGlzIGFsbG93YWJsZS4NCj4gUmF5IGRvIHlvdSBo YXZlIHRoZSBuZWNlc3NhcnkgZGV0YWlscyBvbiB0aGUgYm94ZXMgeW91IHRlc3RlZD8NCg0KVGhp cyBpcyB3cm9uZyBpbiBwcmluY2lwbGUuIEkgYW0gdG90YWxseSBvcHBvc2VkIHRvIHRoaXMgYXBw cm9hY2guDQpJdCB3aWxsIGFsc28gSSBwcmVkaWN0IGJlIHdob2xseSBmdXRpbGUuDQpZb3UgY29u Y2VwdCBvZiB0aGUgdHlwaWNhbCBpbnRlcm5ldCB1c2VyIGlzIHdob2xseSBhdCB2YXJpYW5jZSB3 aXRoIHJlYWxpdHkuDQpUaGV5IHdpbGwgbmV2ZXIgYmUgYWJsZSB0byBjb25maWd1cmUgdGhlc2Ug Ym94ZXMsIG9yIGluc3RhbGwgdXBkYXRlcy4NCk5vciBzaG91bGQgdGhleSBoYXZlIHRvLCBzaW1w bHkgZHVlIHRvIGEgYmFkbHkgZGVzaWduZWQgcHJvdG9jb2wuDQoNCkdlb3JnZQ0KIA0KPiBNYXJr DQo+IC0tIA0KPiBNYXJrIEFuZHJld3MsIElTQw0KPiAxIFNleW1vdXIgU3QuLCBEdW5kYXMgVmFs bGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+IFBIT05FOiArNjEgMiA5ODcxIDQ3NDIgICAgICAg ICAgICAgICAgIElOVEVSTkVUOiBtYXJrYUBpc2Mub3JnDQo+ From owner-namedroppers@ops.ietf.org Mon Aug 31 00:57: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 36ABD28C1F7; Mon, 31 Aug 2009 00:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFhI6heg8Kvs; Mon, 31 Aug 2009 00:57:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 908E83A6BBD; Mon, 31 Aug 2009 00:56:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi1eX-000Fss-Fy for namedroppers-data0@psg.com; Mon, 31 Aug 2009 07:50:13 +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 1Mi1e9-000FjW-6S for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 07:50:01 +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 n7V7nemi008518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2009 09:49:42 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A9B8094.3020809@nlnetlabs.nl> Date: Mon, 31 Aug 2009 09:49:40 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: Matthew Dempsky CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention References: <4A9724E7.2070108@isc.org> <4A972BDB.4060900@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> <20090828185715.GD11294@shinkuro.com> <20090828194551.GF11294@shinkuro.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 31 Aug 2009 09:49:42 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2009 10:50 PM, Matthew Dempsky wrote: >> In other words, if packet-fiddling is detected then either (1) >> non-fiddled responses win or (2) user can't get to target. At least, >> that's how I read this. Correct me if I'm missing something. > > I believe that's a correct interpretation. The point is that > packet-fiddling is detectible, so fiddled-packets are simply ignored. So, couldn't the NS record with the public key in it be spoofed? The query is sniffed that would result in the NS record getting returned. And a fake reply is injected. With fake NS (with fake keys and fake A records): so that the victim goes there; receives valid dnscurve stuff, but bad data. Or the real NS but with fake A records: the victim goes there but won't receive any valid data: DoS. Fake NS and A records can be blindly spoofed too. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqbgJMACgkQkDLqNwOhpPiBzgCePhQWsMI+eXf5ci2fKIirtU+a 90MAni3qR40LC0DGF8cnt+chirIfU8Q0 =Jhuz -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Aug 31 00:59: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 31C1028C1CE; Mon, 31 Aug 2009 00:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.086, 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 V2qZxsLyGvJG; Mon, 31 Aug 2009 00:59:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67D4D3A6D94; Mon, 31 Aug 2009 00:59:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi1k4-000HB4-Ll for namedroppers-data0@psg.com; Mon, 31 Aug 2009 07:55:56 +0000 Received: from [209.85.211.204] (helo=mail-yw0-f204.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi1jz-000H9z-W2 for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 07:55:54 +0000 Received: by ywh42 with SMTP id 42so7782154ywh.30 for ; Mon, 31 Aug 2009 00:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.2.2 with SMTP id 2mr8653472ybb.16.1251705350591; Mon, 31 Aug 2009 00:55:50 -0700 (PDT) In-Reply-To: <4A9B8094.3020809@nlnetlabs.nl> References: <4A9724E7.2070108@isc.org> <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> <20090828185715.GD11294@shinkuro.com> <20090828194551.GF11294@shinkuro.com> <4A9B8094.3020809@nlnetlabs.nl> Date: Mon, 31 Aug 2009 00:55:50 -0700 Message-ID: Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention 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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 31, 2009 at 12:49 AM, W.C.A. Wijngaards wr= ote: > So, couldn't the NS record with the public key in it be spoofed? > The query is sniffed that would result in the NS record getting > returned. =A0And a fake reply is injected. Assuming the query to the parent name server uses standard DNS, then yes. However, that's no different from DNSSEC and its DS records. The same way caches can be configured with DNSSEC trust anchors, they can be configured with DNSCurve trust anchors. From owner-namedroppers@ops.ietf.org Mon Aug 31 01:02: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 DA5963A6D9B; Mon, 31 Aug 2009 01:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.095, 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 CxXhYsxmIMD2; Mon, 31 Aug 2009 01:02:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22AF93A6D98; Mon, 31 Aug 2009 01:02:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi1m4-000HXJ-Uo for namedroppers-data0@psg.com; Mon, 31 Aug 2009 07:58:00 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi1m1-000HWO-CJ for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 07:57:59 +0000 Received: from [192.168.100.85] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 13CFDC2DA5; Mon, 31 Aug 2009 08:57:55 +0100 (BST) Date: Mon, 31 Aug 2009 08:57:58 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , Mark Andrews cc: Doug Barton , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Working around proxies Message-ID: In-Reply-To: <1009805BA49B4D22BAD2E408B06FA87B@localhost> References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 August 2009 07:21:26 +0100 George Barwood wrote: > The devices are NOT broken Sorry? Please explain how, for instance, a device that truncates and then passes on an answer is not broken. Or a device that advertises a large EDNS0 reply size but can't reassemble the UDP fragments necessary to transmit it. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 01:30: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 E27DB3A6974; Mon, 31 Aug 2009 01:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.926 X-Spam-Level: **** X-Spam-Status: No, score=4.926 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_20=-0.74, 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 sqY6PpMFDqKd; Mon, 31 Aug 2009 01:30:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F0F03A688D; Mon, 31 Aug 2009 01:30:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi2DK-000LTL-84 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 08:26:10 +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 1Mi2DG-000LSp-Hc for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 08:26:08 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Mi2D9-0004MW-35; Mon, 31 Aug 2009 09:25:59 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mi2D8-0007N6-H2; Mon, 31 Aug 2009 09:25:58 +0100 Message-ID: From: "George Barwood" To: "Alex Bligh" , "Mark Andrews" Cc: "Doug Barton" , , "Alex Bligh" References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> Subject: Re: [dnsext] Working around proxies Date: Mon, 31 Aug 2009 09:25:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5 b25kZXIuY28udWs+OyAiTWFyayBBbmRyZXdzIiA8bWFya2FAaXNjLm9yZz4NCkNjOiAiRG91ZyBC YXJ0b24iIDxkb3VnYkBkb3VnYmFydG9uLnVzPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+ OyAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBNb25kYXksIEF1Z3VzdCAz MSwgMjAwOSA4OjU3IEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gV29ya2luZyBhcm91bmQgcHJv eGllcyANCg0KDQo+IA0KPiANCj4gLS1PbiAzMSBBdWd1c3QgMjAwOSAwNzoyMToyNiArMDEwMCBH ZW9yZ2UgQmFyd29vZCANCj4gPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+IHdyb3Rl Og0KPiANCj4+IFRoZSBkZXZpY2VzIGFyZSBOT1QgYnJva2VuDQo+IA0KPiBTb3JyeT8gUGxlYXNl IGV4cGxhaW4gaG93LCBmb3IgaW5zdGFuY2UsIGEgZGV2aWNlIHRoYXQgdHJ1bmNhdGVzIGFuZCB0 aGVuDQo+IHBhc3NlcyBvbiBhbiBhbnN3ZXIgaXMgbm90IGJyb2tlbi4gT3IgYSBkZXZpY2UgdGhh dCBhZHZlcnRpc2VzIGEgbGFyZ2UNCj4gRUROUzAgcmVwbHkgc2l6ZSBidXQgY2FuJ3QgcmVhc3Nl bWJsZSB0aGUgVURQIGZyYWdtZW50cyBuZWNlc3NhcnkgdG8NCj4gdHJhbnNtaXQgaXQuDQoNClRo ZSBkZXZpY2VzIGFyZSBmdWxseSBjb21wYXRpYmxlIHdpdGggdGhlIGV4aXN0aW5nIEROUyBzdGFu ZGFyZCwgYnkgd2hpY2gNCkkgbWVhbiB0aGUgd2lkZWx5IGRlcGxveWVkIHN0YW5kYXJkIGRlZmlu ZWQgYnkgUkZDIDEwMzQgLyBSRkMgMTAzNS4NCg0KUHJvdG9jb2wgZXh0ZW5zaW9ucyAoIHN1Y2gg YXMgRE5TU0VDL0VETlMgKSBtdXN0IGJlIGRlc2lnbmVkIHRvIGJlIGZ1bGx5DQpjb21wYXRpYmxl IHdpdGggdGhlIGVhcmxpZXIgc3RhbmRhcmQgc28gdGhhdCB0aGV5IG1heSBiZSBlYXNpbHkgZGVw bG95ZWQuDQoNCkROU1NFQy9FRE5TIGlzIGJyb2tlbiBpbiB0aGlzIHJlcGVjdC4gRUROUyBpcyBh bHNvIGFudGktc29jaWFsIGluIHRoYXQgaXQNCmVuYWJsZXMgZGVuaWFsIG9mIHNlcnZpY2UgYXR0 YWNrcyBvbiB0aGlyZCBwYXJ0aWVzICggdGhpcyBpcyBhIHNlcGVyYXRlIGlzc3VlLA0KdGhhdCBz aG91bGQgSU1PIGFsc28gYmUgZml4ZWQgKS4NCg0KR2VvcmdlDQoNCj4gLS0gDQo+IEFsZXggQmxp Z2gNCj4= From owner-namedroppers@ops.ietf.org Mon Aug 31 02:31: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 A343A3A6958; Mon, 31 Aug 2009 02:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.063 X-Spam-Level: * X-Spam-Status: No, score=1.063 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mr7zvsAbD7w; Mon, 31 Aug 2009 02:31:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83D433A68EA; Mon, 31 Aug 2009 02:31:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi39L-00040V-IC for namedroppers-data0@psg.com; Mon, 31 Aug 2009 09:26:07 +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 1Mi38x-0003vg-1W for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 09:25:45 +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 1Mi38t-00014m-J4; Mon, 31 Aug 2009 11:25:39 +0200 Received: by bfk.de with local id 1Mi38t-0005oH-F7; Mon, 31 Aug 2009 09:25:39 +0000 To: "George Barwood" Cc: Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> From: Florian Weimer Date: Mon, 31 Aug 2009 09:25:39 +0000 In-Reply-To: <4CB0582F89044745BF1D1EBF09E549B6@localhost> (George Barwood's message of "Tue\, 25 Aug 2009 15\:21\:19 +0100") Message-ID: <82k50kfi7g.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * George Barwood: > The idea being that it's not necessary to update the middlebox for > this to work. You should use a different UDP if you want to bypass protocol-aware middleboxes. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 31 05:29: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 3204028C200; Mon, 31 Aug 2009 05:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 8zumIirFM8Vc; Mon, 31 Aug 2009 05:29:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3048228C24E; Mon, 31 Aug 2009 05:29:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi5uK-0001PV-AV for namedroppers-data0@psg.com; Mon, 31 Aug 2009 12:22: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 1Mi5uF-0001Oz-S9 for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 12:22: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 8F0F9E6023; Mon, 31 Aug 2009 12:22: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 n7VCMX8j000197; Mon, 31 Aug 2009 22:22:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908311222.n7VCMX8j000197@drugs.dv.isc.org> To: "George Barwood" Cc: "Alex Bligh" , "Doug Barton" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Mon, 31 Aug 2009 07:21:26 +0100." <1009805BA49B4D22BAD2E408B06FA87B@localhost> Date: Mon, 31 Aug 2009 22:22:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <1009805BA49B4D22BAD2E408B06FA87B@localhost>, "George Barwood" write s: > > In message , Alex Bligh writes: > >> > There are only 2 ways to "get" a new TLD for this purpose. The first > >> > is to go through the ICANN new TLD process. The complexity of this, > >> > even if we could get ICANN to waive the fees associated, are daunting > >> > to say the least, would take a very long time to complete, and it's > >> > not likely to be approved in any case. The other way is for "us" to > >> > appropriate one, either by starting to use it (ala .lan or .local) > >> > which would be very bad manners; or by attempting some sort of IETF > >> > process to "justify" it's use, which would lead to a turf war with > >> > ICANN that there is no reason for. > >> > >> Technically speaking, a 3rd way to do an equivalent thing would be > >> a subdomain of .arpa. I am not suggesting this is necessarily > >> a good idea. > >> > >> -- > >> Alex Bligh > > > > The whole idea is bad. You don't design protocol extension to work > > around devices which are breaking the protocol. You fix/replace > > the broken devices. > > The devices are NOT broken. The protocol should have been designed > to be compatible with the existing installed base. I'm simply proposing > to fix the protocol, which is what is really broken. What installed base? Consumer ADSL, wireless and cable data were fledgling/non existant markets when EDNS was designed. The world was still mainly dialup to a single home PC. A lot has happened in the last decade. Almost all, if not all, of the products that are causing us problems now were designed after EDNS0 was published. Please tell me which products we where supposed to have designed for that had DNS proxies (just copied the QUERY) in them in the 1998/1999 time frame? A recursive server was defined to be a piece of software that generated its own iterative queries then put together a answer based on what it had received. There were recursive servers that made made recursive queries to other recursive servers but they still constructed their own queries. We had forwarding of UPDATE packets defined. TSIG in 2000 took the changed qid into account. UPDATE packets are also sent direct to authoritative servers for the zone. > > If the working group wants to be productive the members should look > > at the devices they have access to and publish which ones work > > correctly and to what extent and which ones don't. This will allow > > consumers to buy boxes which work. The report should include > > hardware and firmware revision numbers so that manufactures can > > reproduce the reported problems if desired. > > > > Working should include those that will work after a firmware upgrade > > along with the firmware revision required. > > > > We should encourage manufactures to report products that they believe > > work correctly. > > > > Ray's report would be a useful starting point, if that is allowable. > > Ray do you have the necessary details on the boxes you tested? > > This is wrong in principle. I am totally opposed to this approach. > It will also I predict be wholly futile. > You concept of the typical internet user is wholly at variance with reality. > They will never be able to configure these boxes, or install updates. > Nor should they have to, simply due to a badly designed protocol. > > George > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 05: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 01E6728C259; Mon, 31 Aug 2009 05: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=[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 bh3q6hFv482V; Mon, 31 Aug 2009 05:41:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EE1A28C253; Mon, 31 Aug 2009 05:41:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi67Y-0003RX-3z for namedroppers-data0@psg.com; Mon, 31 Aug 2009 12:36: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 1Mi67U-0003QG-Ib for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 12:36:26 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1EA58B4AFC for ; Mon, 31 Aug 2009 12:36:24 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies In-Reply-To: Your message of "Mon, 31 Aug 2009 07:21:26 +0100." <1009805BA49B4D22BAD2E408B06FA87B@localhost> References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 31 Aug 2009 12:36:24 +0000 Message-ID: <62581.1251722184@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Mon, 31 Aug 2009 07:21:26 +0100 > > [Mark Andrews] > > The whole idea is bad. You don't design protocol extension to work > > around devices which are breaking the protocol. You fix/replace the > > broken devices. > > The devices are NOT broken. The protocol should have been designed to be > compatible with the existing installed base. I'm simply proposing to fix > the protocol, which is what is really broken. by that reasoning, which is wrong, microsoft should not have implemented AXFR with more than one answer per message, since BIND did not tolerate it. fortunately, everyone knew that BIND was being stupid, so we fixed the installed base and apologized to microsoft. i agree with mark that the installed base is wrong. i don't know if it can be fixed, mind you. the reason EDNS should probably not have depended upon ip fragmentation is that mogul and kent explained why ip fragmentation was a bad idea (google for WRL-87-3 to see the tech report) not because of the installed base. From owner-namedroppers@ops.ietf.org Mon Aug 31 05:53: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 9D4AE3A6991; Mon, 31 Aug 2009 05:53: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=[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 ThJ4ey8zKNzf; Mon, 31 Aug 2009 05:53:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC5163A6B28; Mon, 31 Aug 2009 05:53:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi6Kp-0005aN-Pk for namedroppers-data0@psg.com; Mon, 31 Aug 2009 12:50:11 +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 1Mi6Km-0005Zd-1f for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 12:50:09 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id ABB14B4AC3 for ; Mon, 31 Aug 2009 12:50:07 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies In-Reply-To: Your message of "Mon, 31 Aug 2009 09:25:55 +0100." References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 31 Aug 2009 12:50:07 +0000 Message-ID: <63220.1251723007@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Mon, 31 Aug 2009 09:25:55 +0100 > > > ... Please explain how, for instance, a device that truncates and then > > passes on an answer is not broken. Or a device that advertises a large > > EDNS0 reply size but can't reassemble the UDP fragments necessary to > > transmit it. > > The devices are fully compatible with the existing DNS standard, by which > I mean the widely deployed standard defined by RFC 1034 / RFC 1035. middleboxes have a higher standard than "do no harm". the robustness principle as applied to middleboxes would be expressed as "be liberal in what you pass through and be conservative in what you interfere with." to be compatible with the philosophy which underlaid RFC 1034 / RFC 1035, middleboxes would have had to pass through any UDP/53 or TCP/53 which appeared to them to be a format error. that's clearly not happening. > Protocol extensions ( such as DNSSEC/EDNS ) must be designed to be fully > compatible with the earlier standard so that they may be easily deployed. this is wrong. by this reasoning, which is wrong, an IP router would be free to drop all packets whose protocol type wasn't either ICMP, UDP or TCP, if those were the only protocol types that showed up in the test lab. the design-level conservatism you are asking for here might be appropriate for product design, but not open systems protocol design. here, we imagine a sort of virtual installed base, existing only in our minds / the future. From owner-namedroppers@ops.ietf.org Mon Aug 31 06:09:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39E428C231; Mon, 31 Aug 2009 06:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.019 X-Spam-Level: **** X-Spam-Status: No, score=4.019 tagged_above=-999 required=5 tests=[AWL=0.124, 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 xXxZQoKBhKnb; Mon, 31 Aug 2009 06:09:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C7C128C25F; Mon, 31 Aug 2009 06:09:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi6aS-0008Gg-5Q for namedroppers-data0@psg.com; Mon, 31 Aug 2009 13:06:20 +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 1Mi6aN-0008G0-Gq for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 13:06:17 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Mi6aD-0001Vu-BK; Mon, 31 Aug 2009 14:06:05 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Mi6aC-0002pP-IW; Mon, 31 Aug 2009 14:06:04 +0100 Message-ID: <339C5564ABB948BAB7F9591DF3325140@localhost> From: "George Barwood" To: "Mark Andrews" Cc: "Alex Bligh" , "Doug Barton" , References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> Subject: Re: [dnsext] Working around proxies Date: Mon, 31 Aug 2009 14:06:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+OyAiRG91ZyBC YXJ0b24iIDxkb3VnYkBkb3VnYmFydG9uLnVzPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+ DQpTZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAwOSAxOjIyIFBNDQpTdWJqZWN0OiBSZTogW2Ru c2V4dF0gV29ya2luZyBhcm91bmQgcHJveGllcyANCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDwxMDA5 ODA1QkE0OUI0RDIyQkFEMkU0MDhCMDZGQTg3QkBsb2NhbGhvc3Q+LCAiR2VvcmdlIEJhcndvb2Qi IHdyaXRlDQo+IHM6DQo+PiA+IEluIG1lc3NhZ2UgPEIzQUY0QjUwOUM3QTEyRTNDMEZGMzI3OUBu aW1yb2QubG9jYWw+LCBBbGV4IEJsaWdoIHdyaXRlczoNCj4+ID4+ID4gVGhlcmUgYXJlIG9ubHkg MiB3YXlzIHRvICJnZXQiIGEgbmV3IFRMRCBmb3IgdGhpcyBwdXJwb3NlLiBUaGUgZmlyc3QNCj4+ ID4+ID4gaXMgdG8gZ28gdGhyb3VnaCB0aGUgSUNBTk4gbmV3IFRMRCBwcm9jZXNzLiBUaGUgY29t cGxleGl0eSBvZiB0aGlzLA0KPj4gPj4gPiBldmVuIGlmIHdlIGNvdWxkIGdldCBJQ0FOTiB0byB3 YWl2ZSB0aGUgZmVlcyBhc3NvY2lhdGVkLCBhcmUgZGF1bnRpbmcNCj4+ID4+ID4gdG8gc2F5IHRo ZSBsZWFzdCwgd291bGQgdGFrZSBhIHZlcnkgbG9uZyB0aW1lIHRvIGNvbXBsZXRlLCBhbmQgaXQn cw0KPj4gPj4gPiBub3QgbGlrZWx5IHRvIGJlIGFwcHJvdmVkIGluIGFueSBjYXNlLiBUaGUgb3Ro ZXIgd2F5IGlzIGZvciAidXMiIHRvDQo+PiA+PiA+IGFwcHJvcHJpYXRlIG9uZSwgZWl0aGVyIGJ5 IHN0YXJ0aW5nIHRvIHVzZSBpdCAoYWxhIC5sYW4gb3IgLmxvY2FsKQ0KPj4gPj4gPiB3aGljaCB3 b3VsZCBiZSB2ZXJ5IGJhZCBtYW5uZXJzOyBvciBieSBhdHRlbXB0aW5nIHNvbWUgc29ydCBvZiBJ RVRGDQo+PiA+PiA+IHByb2Nlc3MgdG8gImp1c3RpZnkiIGl0J3MgdXNlLCB3aGljaCB3b3VsZCBs ZWFkIHRvIGEgdHVyZiB3YXIgd2l0aA0KPj4gPj4gPiBJQ0FOTiB0aGF0IHRoZXJlIGlzIG5vIHJl YXNvbiBmb3IuDQo+PiA+PiANCj4+ID4+IFRlY2huaWNhbGx5IHNwZWFraW5nLCBhIDNyZCB3YXkg dG8gZG8gYW4gZXF1aXZhbGVudCB0aGluZyB3b3VsZCBiZQ0KPj4gPj4gYSBzdWJkb21haW4gb2Yg LmFycGEuIEkgYW0gbm90IHN1Z2dlc3RpbmcgdGhpcyBpcyBuZWNlc3NhcmlseQ0KPj4gPj4gYSBn b29kIGlkZWEuDQo+PiA+PiANCj4+ID4+IC0tIA0KPj4gPj4gQWxleCBCbGlnaA0KPj4gPiANCj4+ ID4gVGhlIHdob2xlIGlkZWEgaXMgYmFkLiAgWW91IGRvbid0IGRlc2lnbiBwcm90b2NvbCBleHRl bnNpb24gdG8gd29yaw0KPj4gPiBhcm91bmQgZGV2aWNlcyB3aGljaCBhcmUgYnJlYWtpbmcgdGhl IHByb3RvY29sLiAgWW91IGZpeC9yZXBsYWNlDQo+PiA+IHRoZSBicm9rZW4gZGV2aWNlcy4NCj4+ IA0KPj4gVGhlIGRldmljZXMgYXJlIE5PVCBicm9rZW4uIFRoZSBwcm90b2NvbCBzaG91bGQgaGF2 ZSBiZWVuIGRlc2lnbmVkDQo+PiB0byBiZSBjb21wYXRpYmxlIHdpdGggdGhlIGV4aXN0aW5nIGlu c3RhbGxlZCBiYXNlLiBJJ20gc2ltcGx5IHByb3Bvc2luZw0KPj4gdG8gZml4IHRoZSBwcm90b2Nv bCwgd2hpY2ggaXMgd2hhdCBpcyByZWFsbHkgYnJva2VuLg0KPiANCj4gV2hhdCBpbnN0YWxsZWQg YmFzZT8gIENvbnN1bWVyIEFEU0wsIHdpcmVsZXNzIGFuZCBjYWJsZSBkYXRhIHdlcmUNCj4gZmxl ZGdsaW5nL25vbiBleGlzdGFudCBtYXJrZXRzIHdoZW4gRUROUyB3YXMgZGVzaWduZWQuICBUaGUg d29ybGQNCj4gd2FzIHN0aWxsIG1haW5seSBkaWFsdXAgdG8gYSBzaW5nbGUgaG9tZSBQQy4gIEEg bG90IGhhcyBoYXBwZW5lZA0KPiBpbiB0aGUgbGFzdCBkZWNhZGUuICBBbG1vc3QgYWxsLCBpZiBu b3QgYWxsLCBvZiB0aGUgcHJvZHVjdHMgdGhhdA0KPiBhcmUgY2F1c2luZyB1cyBwcm9ibGVtcyBu b3cgd2VyZSBkZXNpZ25lZCBhZnRlciBFRE5TMCB3YXMgcHVibGlzaGVkLg0KDQpXZWxsIHRoYXQg bWF5IHdlbGwgYmUgdGhlIGNhc2UsIGJ1dCBvZiBjb3Vyc2Ugbm8gb25lIHRha2VzIG11Y2ggYWNj b3VudA0Kb2Ygc3RhbmRhcmRzIHRoYXQgYXJlIG5vdCB3aWRlbHkgZGVwbG95ZWQsIGFuZCB0aGF0 IGhhcyBiZWVuIHRoZSBjYXNlLg0KDQpSZWdhcmRsZXNzIG9mIHRoZSBibGFtZSBmb3IgdGhlIGN1 cnJlbnQgbWVzcywgaGVyZSB3ZSBhcmUsIGFuZCBhDQpyZWFsaXN0aWMgd2F5IGZvcndhcmQgaXMg bmVlZGVkLg0KDQpJIHRoaW5rIHVwZGF0aW5nIHRoZXNlIGJveGVzIGlzIHVucmVhbGlzdGljLCBh bmQgdGhhdCBzb21lIG90aGVyIG9wdGlvbg0Kd2lsbCBzcGVlZCBETlNTRUMgZGVwbG95bWVudC4N Cg0KTGlrZSBLaW5nIENhbnV0ZSwgd2UgbXVzdCByZWNvZ25pc2UgdGhhdCB3ZSBoYXZlIG5vIHBv d2VyIG92ZXIgdGhlIHRpZGUsDQp3ZSBoYXZlIHRvIHN3aW0gd2l0aCBpdC4NCg0KR2VvcmdlDQoN Cj4gUGxlYXNlIHRlbGwgbWUgd2hpY2ggcHJvZHVjdHMgd2Ugd2hlcmUgc3VwcG9zZWQgdG8gaGF2 ZSBkZXNpZ25lZA0KPiBmb3IgdGhhdCBoYWQgRE5TIHByb3hpZXMgKGp1c3QgY29waWVkIHRoZSBR VUVSWSkgaW4gdGhlbSBpbiB0aGUNCj4gMTk5OC8xOTk5IHRpbWUgZnJhbWU/DQo+IA0KPiBBIHJl Y3Vyc2l2ZSBzZXJ2ZXIgd2FzIGRlZmluZWQgdG8gYmUgYSBwaWVjZSBvZiBzb2Z0d2FyZSB0aGF0 DQo+IGdlbmVyYXRlZCBpdHMgb3duIGl0ZXJhdGl2ZSBxdWVyaWVzIHRoZW4gcHV0IHRvZ2V0aGVy IGEgYW5zd2VyIGJhc2VkDQo+IG9uIHdoYXQgaXQgaGFkIHJlY2VpdmVkLiAgVGhlcmUgd2VyZSBy ZWN1cnNpdmUgc2VydmVycyB0aGF0IG1hZGUNCj4gbWFkZSByZWN1cnNpdmUgcXVlcmllcyB0byBv dGhlciByZWN1cnNpdmUgc2VydmVycyBidXQgdGhleSBzdGlsbA0KPiBjb25zdHJ1Y3RlZCB0aGVp ciBvd24gcXVlcmllcy4NCj4gDQo+IFdlIGhhZCBmb3J3YXJkaW5nIG9mIFVQREFURSBwYWNrZXRz IGRlZmluZWQuICBUU0lHIGluIDIwMDAgdG9vayB0aGUNCj4gY2hhbmdlZCBxaWQgaW50byBhY2Nv dW50LiAgVVBEQVRFIHBhY2tldHMgYXJlIGFsc28gc2VudCBkaXJlY3QgdG8NCj4gYXV0aG9yaXRh dGl2ZSBzZXJ2ZXJzIGZvciB0aGUgem9uZS4NCj4gDQo+PiA+IElmIHRoZSB3b3JraW5nIGdyb3Vw IHdhbnRzIHRvIGJlIHByb2R1Y3RpdmUgdGhlIG1lbWJlcnMgc2hvdWxkIGxvb2sNCj4+ID4gYXQg dGhlIGRldmljZXMgdGhleSBoYXZlIGFjY2VzcyB0byBhbmQgcHVibGlzaCB3aGljaCBvbmVzIHdv cmsNCj4+ID4gY29ycmVjdGx5IGFuZCB0byB3aGF0IGV4dGVudCBhbmQgd2hpY2ggb25lcyBkb24n dC4gIFRoaXMgd2lsbCBhbGxvdw0KPj4gPiBjb25zdW1lcnMgdG8gYnV5IGJveGVzIHdoaWNoIHdv cmsuICBUaGUgcmVwb3J0IHNob3VsZCBpbmNsdWRlDQo+PiA+IGhhcmR3YXJlIGFuZCBmaXJtd2Fy ZSByZXZpc2lvbiBudW1iZXJzIHNvIHRoYXQgbWFudWZhY3R1cmVzIGNhbg0KPj4gPiByZXByb2R1 Y2UgdGhlIHJlcG9ydGVkIHByb2JsZW1zIGlmIGRlc2lyZWQuDQo+PiA+IA0KPj4gPiBXb3JraW5n IHNob3VsZCBpbmNsdWRlIHRob3NlIHRoYXQgd2lsbCB3b3JrIGFmdGVyIGEgZmlybXdhcmUgdXBn cmFkZQ0KPj4gPiBhbG9uZyB3aXRoIHRoZSBmaXJtd2FyZSByZXZpc2lvbiByZXF1aXJlZC4NCj4+ ID4gDQo+PiA+IFdlIHNob3VsZCBlbmNvdXJhZ2UgbWFudWZhY3R1cmVzIHRvIHJlcG9ydCBwcm9k dWN0cyB0aGF0IHRoZXkgYmVsaWV2ZQ0KPj4gPiB3b3JrIGNvcnJlY3RseS4NCj4+ID4gDQo+PiA+ IFJheSdzIHJlcG9ydCB3b3VsZCBiZSBhIHVzZWZ1bCBzdGFydGluZyBwb2ludCwgaWYgdGhhdCBp cyBhbGxvd2FibGUuDQo+PiA+IFJheSBkbyB5b3UgaGF2ZSB0aGUgbmVjZXNzYXJ5IGRldGFpbHMg b24gdGhlIGJveGVzIHlvdSB0ZXN0ZWQ/DQo+PiANCj4+IFRoaXMgaXMgd3JvbmcgaW4gcHJpbmNp cGxlLiBJIGFtIHRvdGFsbHkgb3Bwb3NlZCB0byB0aGlzIGFwcHJvYWNoLg0KPj4gSXQgd2lsbCBh bHNvIEkgcHJlZGljdCBiZSB3aG9sbHkgZnV0aWxlLg0KPj4gWW91IGNvbmNlcHQgb2YgdGhlIHR5 cGljYWwgaW50ZXJuZXQgdXNlciBpcyB3aG9sbHkgYXQgdmFyaWFuY2Ugd2l0aCByZWFsaXR5Lg0K Pj4gVGhleSB3aWxsIG5ldmVyIGJlIGFibGUgdG8gY29uZmlndXJlIHRoZXNlIGJveGVzLCBvciBp bnN0YWxsIHVwZGF0ZXMuDQo+PiBOb3Igc2hvdWxkIHRoZXkgaGF2ZSB0bywgc2ltcGx5IGR1ZSB0 byBhIGJhZGx5IGRlc2lnbmVkIHByb3RvY29sLg0KPj4NCj4+IEdlb3JnZQ0KPj4gIA0KPj4gPiBN YXJrDQo+PiA+IC0tIA0KPj4gPiBNYXJrIEFuZHJld3MsIElTQw0KPj4gPiAxIFNleW1vdXIgU3Qu LCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+PiA+IFBIT05FOiArNjEgMiA5 ODcxIDQ3NDIgICAgICAgICAgICAgICAgIElOVEVSTkVUOiBtYXJrYUBpc2Mub3JnDQo+PiA+DQo+ IA0KPiANCj4gLS0gDQo+IE1hcmsgQW5kcmV3cywgSVNDDQo+IDEgU2V5bW91ciBTdC4sIER1bmRh cyBWYWxsZXksIE5TVyAyMTE3LCBBdXN0cmFsaWENCj4gUEhPTkU6ICs2MSAyIDk4NzEgNDc0MiAg ICAgICAgICAgICAgICAgSU5URVJORVQ6IG1hcmthQGlzYy5vcmcNCj4= From owner-namedroppers@ops.ietf.org Mon Aug 31 06:41: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 2C47928C279; Mon, 31 Aug 2009 06:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 I693fRP4gU7F; Mon, 31 Aug 2009 06:41:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1081528C27C; Mon, 31 Aug 2009 06:41:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi73S-000BzE-CR for namedroppers-data0@psg.com; Mon, 31 Aug 2009 13:36: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 1Mi73O-000Bya-HP for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 13:36:16 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 28875E6024; Mon, 31 Aug 2009 13:36: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 n7VDa9Cx000688; Mon, 31 Aug 2009 23:36:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908311336.n7VDa9Cx000688@drugs.dv.isc.org> To: "George Barwood" Cc: "Alex Bligh" , "Doug Barton" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Mon, 31 Aug 2009 09:25:55 +0100." Date: Mon, 31 Aug 2009 23:36:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , "George Barwood" write s: > > ----- Original Message ----- > From: "Alex Bligh" > To: "George Barwood" ; "Mark Andrews" > Cc: "Doug Barton" ; ; "Alex Bligh" > Sent: Monday, August 31, 2009 8:57 AM > Subject: Re: [dnsext] Working around proxies > > > --On 31 August 2009 07:21:26 +0100 George Barwood > > wrote: > > > >> The devices are NOT broken > > > > Sorry? Please explain how, for instance, a device that truncates and then > > passes on an answer is not broken. Or a device that advertises a large > > EDNS0 reply size but can't reassemble the UDP fragments necessary to > > transmit it. > > The devices are fully compatible with the existing DNS standard, by which > I mean the widely deployed standard defined by RFC 1034 / RFC 1035. If they were compatible with RFC 1034 / RFC 1035 then they would have been generating their own queries. This is what a recursive server was described as doing in RFC 1034 / RFC 1035. Instead someone thought they would be "smart" and just copy the packet without thinking about all the possible ramifications of just copying a packet. You are taking on blind faith that the packet you are emitting will not cause problems if you have not fully check the input packet and understood it completely. A device that is fully compatible with a standard is incapable of emitting a packet that is outside of that standard. These devices never were fully compatible with RFC 1034 / RFC 1035 because they are capable of emitting packets which are not compliant with RFC 1034 / RFC 1035. RFC 1034 / RFC 1035 has a lot of "do it this way" in it. Until you try and do it another way you don't realise what was rejected at the design stage or in early prototypes. Recursive servers fall into this category. > Protocol extensions ( such as DNSSEC/EDNS ) must be designed to be fully > compatible with the earlier standard so that they may be easily deployed. The were. These devices were, and still are, not compliant with RFC 1034 / RFC 1035 as it existed or any combinations of the extension to RFC 1034 / RFC 1035. > DNSSEC/EDNS is broken in this repect. EDNS is also anti-social in that it > enables denial of service attacks on third parties ( this is a seperate issue, > that should IMO also be fixed ). > > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 07:07: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 A453D3A6E0E; Mon, 31 Aug 2009 07:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 8chKsTU6HdNh; Mon, 31 Aug 2009 07:07:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 925093A6DCD; Mon, 31 Aug 2009 07:07:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi7U9-000Gjd-5W for namedroppers-data0@psg.com; Mon, 31 Aug 2009 14:03: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 1Mi7U4-000GjF-N4 for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 14:03: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 90ADDE601C; Mon, 31 Aug 2009 14:03: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 n7VE3iNe004282; Tue, 1 Sep 2009 00:03:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908311403.n7VE3iNe004282@drugs.dv.isc.org> To: "George Barwood" Cc: "Alex Bligh" , "Doug Barton" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Mon, 31 Aug 2009 14:06:01 +0100." <339C5564ABB948BAB7F9591DF3325140@localhost> Date: Tue, 01 Sep 2009 00:03:44 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <339C5564ABB948BAB7F9591DF3325140@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Alex Bligh" ; "Doug Barton" ; > Sent: Monday, August 31, 2009 1:22 PM > Subject: Re: [dnsext] Working around proxies > > > > > > In message <1009805BA49B4D22BAD2E408B06FA87B@localhost>, "George Barwood" write > > s: > >> > In message , Alex Bligh writes: > >> >> > There are only 2 ways to "get" a new TLD for this purpose. The first > >> >> > is to go through the ICANN new TLD process. The complexity of this, > >> >> > even if we could get ICANN to waive the fees associated, are daunting > >> >> > to say the least, would take a very long time to complete, and it's > >> >> > not likely to be approved in any case. The other way is for "us" to > >> >> > appropriate one, either by starting to use it (ala .lan or .local) > >> >> > which would be very bad manners; or by attempting some sort of IETF > >> >> > process to "justify" it's use, which would lead to a turf war with > >> >> > ICANN that there is no reason for. > >> >> > >> >> Technically speaking, a 3rd way to do an equivalent thing would be > >> >> a subdomain of .arpa. I am not suggesting this is necessarily > >> >> a good idea. > >> >> > >> >> -- > >> >> Alex Bligh > >> > > >> > The whole idea is bad. You don't design protocol extension to work > >> > around devices which are breaking the protocol. You fix/replace > >> > the broken devices. > >> > >> The devices are NOT broken. The protocol should have been designed > >> to be compatible with the existing installed base. I'm simply proposing > >> to fix the protocol, which is what is really broken. > > > > What installed base? Consumer ADSL, wireless and cable data were > > fledgling/non existant markets when EDNS was designed. The world > > was still mainly dialup to a single home PC. A lot has happened > > in the last decade. Almost all, if not all, of the products that > > are causing us problems now were designed after EDNS0 was published. > > Well that may well be the case, but of course no one takes much account > of standards that are not widely deployed, and that has been the case. > > Regardless of the blame for the current mess, here we are, and a > realistic way forward is needed. > > I think updating these boxes is unrealistic, and that some other option > will speed DNSSEC deployment. We don't need to update the existing boxes. We just need to make sure future boxes behave better. We are doing that by writing down what the vendors got wrong and telling them what they should be doing to fix the issues with their boxes. It it possible to work through most of these boxes. For those you can't you just need to point your clients at a DNS server which is not the box. We did that sort of thing for years before PPP had a nameserver option in the dialup world. Step by step instructions exist showing how to do this for major OS's. Mark > Like King Canute, we must recognise that we have no power over the tide, > we have to swim with it. > > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 07:54: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 6E4633A68D1; Mon, 31 Aug 2009 07:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=-1.586, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6xbtEeQhZjb; Mon, 31 Aug 2009 07:54:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 870533A6D7B; Mon, 31 Aug 2009 07:54:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi8Cj-000N0u-EW for namedroppers-data0@psg.com; Mon, 31 Aug 2009 14:49:57 +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 1Mi8CW-000Mz1-RB for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 14:49:47 +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]:59840) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1Mi8CL-00080p-48 (Exim 4.70) (return-path ); Mon, 31 Aug 2009 15:49:33 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Mi8CL-00035J-8Q (Exim 4.67) (return-path ); Mon, 31 Aug 2009 15:49:33 +0100 Date: Mon, 31 Aug 2009 15:49:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver cc: bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> Message-ID: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, 24 Aug 2009, Nicholas Weaver wrote: > > Whats wrong with "When state exceeds LRU, close", or heck, "If a 'normal' > query, close connection when complete". Remember you should accommodate clients that pipeline multiple queries down the same TCP connection. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Mon Aug 31 07:55: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 95FB53A6D9F; Mon, 31 Aug 2009 07:55:35 -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 g0QGfKEMiIHg; Mon, 31 Aug 2009 07:55:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A5343A68D1; Mon, 31 Aug 2009 07:55:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi8EK-000NHQ-0w for namedroppers-data0@psg.com; Mon, 31 Aug 2009 14:51:36 +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 1Mi8EG-000NGr-RB for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 14:51: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 n7VEpJww015916; Mon, 31 Aug 2009 07:51:19 -0700 (PDT) Cc: Nicholas Weaver , "George Barwood" , "Alex Bligh" , "Doug Barton" , namedroppers@ops.ietf.org Message-Id: <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200908311403.n7VE3iNe004282@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 v936) Subject: Re: [dnsext] Working around proxies Date: Mon, 31 Aug 2009 07:51:18 -0700 References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 31, 2009, at 7:03 AM, Mark Andrews wrote: > We don't need to update the existing boxes. We just need to make > sure future boxes behave better. We are doing that by writing down > what the vendors got wrong and telling them what they should be > doing to fix the issues with their boxes. This is predicated on the premise that the turnover on these boxes is reasonably swift, compared with the desired DNSSEC deployment. I don't believe this is correct. Look at it this way. I'm a technophile. If anyone is going to churn equipment, it would be someone like me. In the past decade-plus, I've gone through 3 NATs. The first one was replaced because it didn't include an AP, and it was my roommate's anyway. The second one had a hardware failure after over 5+ years in service, and I wanted an excuse to upgrade to an 802.11BG access point. During that time, I went through many more computers. The lifespan of these stupid boxes is annoyingly long. > It it possible to work through most of these boxes. For those you > can't you just need to point your clients at a DNS server which is > not the box. We did that sort of thing for years before PPP had a > nameserver option in the dialup world. But this I agree with. And as I've repeatedly advocated, the client needs to run a full recursive resolver in the DNSSEC world anyway, to give a good default failure case for name resolutions. Although these stupid middleboxes are commonly broken, they will almost always pass random-garbage TCP unmolested in our experience, and even on UDP, many will pass non-fragmented DNS with EDNS0 unmolested, or at least pass EDNS@512 unmolested, which means you can construct a local recursive resolver that can effectively and efficiently deal with these broken middleboxes, by quickly discovering their behavior and adapting the recursive resolver to operate within those constraints. > Step by step instructions exist showing how to do this for major OS's. Step by step instructions that my MOTHER can follow? From owner-namedroppers@ops.ietf.org Mon Aug 31 08:23: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 B230B28C2B4; Mon, 31 Aug 2009 08:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, J_CHICKENPOX_26=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 qxYrB07jIODz; Mon, 31 Aug 2009 08:23:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C518F28C2CE; Mon, 31 Aug 2009 08:23:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi8g0-0001Zt-ES for namedroppers-data0@psg.com; Mon, 31 Aug 2009 15:20:12 +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 1Mi8ft-0001Z5-Ec for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 15:20:07 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C99C3E6023; Mon, 31 Aug 2009 15:20:03 +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 n7VFK0Ti013253; Tue, 1 Sep 2009 01:20:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908311520.n7VFK0Ti013253@drugs.dv.isc.org> To: Nicholas Weaver Cc: "George Barwood" , "Alex Bligh" , "Doug Barton" , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Mon, 31 Aug 2009 07:51:18 MST." <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> Date: Tue, 01 Sep 2009 01:19:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu>, Nicholas W eaver writes: > > On Aug 31, 2009, at 7:03 AM, Mark Andrews wrote: > > We don't need to update the existing boxes. We just need to make > > sure future boxes behave better. We are doing that by writing down > > what the vendors got wrong and telling them what they should be > > doing to fix the issues with their boxes. > > This is predicated on the premise that the turnover on these boxes is > reasonably swift, compared with the desired DNSSEC deployment. I > don't believe this is correct. > > Look at it this way. I'm a technophile. If anyone is going to churn > equipment, it would be someone like me. > > In the past decade-plus, I've gone through 3 NATs. The first one was > replaced because it didn't include an AP, and it was my roommate's > anyway. The second one had a hardware failure after over 5+ years in > service, and I wanted an excuse to upgrade to an 802.11BG access point. > > During that time, I went through many more computers. The lifespan of > these stupid boxes is annoyingly long. There is another technology change which is just starting to happen is a big way. Residential IPv6 is starting to be rolled out and that will involve CPE box upgrades/replacements. The same boxes that we want to be fixed are the ones that will be upgraded / replaced to support IPv6 or to continue to support IPv4 when the ISP moves its infrastructure to IPv6. I know I am waiting for a good AP+Router with IPv6 support to replace the existing box. I'd like to know if DNS actually worked in it before buying it. > > It it possible to work through most of these boxes. For those you > > can't you just need to point your clients at a DNS server which is > > not the box. We did that sort of thing for years before PPP had a > > nameserver option in the dialup world. > > But this I agree with. And as I've repeatedly advocated, the client > needs to run a full recursive resolver in the DNSSEC world anyway, to > give a good default failure case for name resolutions. > > Although these stupid middleboxes are commonly broken, they will > almost always pass random-garbage TCP unmolested in our experience, > and even on UDP, many will pass non-fragmented DNS with EDNS0 > unmolested, or at least pass EDNS@512 unmolested, which means you can > construct a local recursive resolver that can effectively and > efficiently deal with these broken middleboxes, by quickly discovering > their behavior and adapting the recursive resolver to operate within > those constraints. > > > Step by step instructions exist showing how to do this for major OS's. > > Step by step instructions that my MOTHER can follow? I don't know your mother. I do know lots of mothers followed such instructions in the past successfully. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 08:53: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 BEBC03A6D00; Mon, 31 Aug 2009 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.091, 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 n1rTljeLDhLL; Mon, 31 Aug 2009 08:53:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC1A728C24E; Mon, 31 Aug 2009 08:53:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi984-0005R9-4F for namedroppers-data0@psg.com; Mon, 31 Aug 2009 15:49:12 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi980-0005QK-2U for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 15:49:10 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 218F3C2DA5; Mon, 31 Aug 2009 16:49:05 +0100 (BST) Date: Mon, 31 Aug 2009 16:48:30 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews , George Barwood cc: Doug Barton , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Working around proxies Message-ID: <4595DFD253DD5280FB55E95B@Ximines.local> In-Reply-To: <200908311403.n7VE3iNe004282@drugs.dv.isc.org> References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 September 2009 00:03:44 +1000 Mark Andrews wrote: > It it possible to work through most of these boxes. For those you > can't you just need to point your clients at a DNS server which is > not the box. With some boxes (e.g. those that drop UDP fragments even in packets not addressed to them), this will cause fallback to TCP for responses greater than 1500 bytes. Whether or not this is acceptable appears to be an open question. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 09:58: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 F124D28C102; Mon, 31 Aug 2009 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 vMWrUnWfr3mf; Mon, 31 Aug 2009 09:58:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EE803A6D5C; Mon, 31 Aug 2009 09:58:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiA7S-000Hx2-M1 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 16:52:38 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiA7N-000HvF-Hu for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 16:52:35 +0000 Received: (qmail 12180 invoked by uid 399); 31 Aug 2009 16:52:28 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Aug 2009 16:52:28 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A9BFFC7.9080805@dougbarton.us> Date: Mon, 31 Aug 2009 09:52:23 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Masataka Ohta CC: George Barwood , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <4A9AF619.3020905@necom830.hpcl.titech.ac.jp> In-Reply-To: <4A9AF619.3020905@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Masataka Ohta wrote: > Doug Barton wrote: > >>>> This sounds like an ideal use case for multicast DNS. > >>> Please explain : I don't see how multicast DNS can help here, >>> but maybe I'm missing something. > >> Well then I guess my next question is, "How much do you know about >> mDNS and how it operates?" A simple response to your question would be >> that the end-user/client box that needs to know the addresses for its >> local resolvers broadcasts the query, and the mDNS process(es) running >> on the local resolver(s) sends out a response that says "Here I am!" > > If you are not talking about link local multicast (you should not, > because local resolvers are often located somewhere beyond local > routers), multicast routing requires a lot of configuration, which > is a lot more complex than DNS configuration, that mDNS is no > solution. If only there were a solution for the problem of hosts behind a local router configuring themselves. We would need something that would allow the host to send out a request for configuration information, and something on the local network to send out information such as a usable IP address, default gateway, netmask, and name servers. Oh, if only such a thing were real! What a wonderful world that would be! > Having a globally unique anycast addresses for default local resolvers > is a better solution. Yeah, I don't see any way THAT could go wrong. Doug From owner-namedroppers@ops.ietf.org Mon Aug 31 10:44:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACAA3A6DE7; Mon, 31 Aug 2009 10:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S-LlzUOqC1B; Mon, 31 Aug 2009 10:44:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFEFA3A6DC6; Mon, 31 Aug 2009 10:44:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiAqb-0000sk-Vn for namedroppers-data0@psg.com; Mon, 31 Aug 2009 17:39:17 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiAqY-0000pd-5P for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 17:39:16 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 8CABCC2DA5; Mon, 31 Aug 2009 18:39:12 +0100 (BST) Date: Mon, 31 Aug 2009 18:38:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Tony Finch , Nicholas Weaver cc: bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <40C2A0A89CFE6F174BCCD299@Ximines.local> In-Reply-To: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 August 2009 15:49:33 +0100 Tony Finch wrote: >> Whats wrong with "When state exceeds LRU, close", or heck, "If a 'normal' >> query, close connection when complete". > > Remember you should accommodate clients that pipeline multiple queries > down the same TCP connection. Hmmm... Elsewhere Mark Andrews suggested that in extremis clients behind broken middleboxen could simply have their nameservers manually coded to resolvers outside the broken middlebox (rather than use the middlebox itself). For these, plus middleboxes which just pass through the external nameserver's address, there is still a problem if they drop UDP fragments or otherwise prevent long answers that aren't addressed to the middlebox, causing TCP fallback. But in such circumstance, if TCP is consistently pipelined, the adverse effect is at least somewhat reduced, as there will be a single caching server being queried by the stub resolver, so at least there won't be a constant stream of setups and tear downs. Question: do stub resolvers on popular operating systems actually fall back to TCP, and if so, do they pipeline? -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 11:09: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 CB1D728C44D; Mon, 31 Aug 2009 11:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 XNFOWNlAD9zM; Mon, 31 Aug 2009 11:09:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A30528C435; Mon, 31 Aug 2009 11:09:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBFB-0005Xz-2z for namedroppers-data0@psg.com; Mon, 31 Aug 2009 18:04:41 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBF6-0005Wr-1F for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 18:04:38 +0000 Received: by ewy11 with SMTP id 11so3985919ewy.11 for ; Mon, 31 Aug 2009 11:04:34 -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; bh=31t9xM1Gn2F/UmB7ZuKyjR5Msvaq6mG623rSwAmvFLM=; b=HOj+XRkfj8QA9m4pzHppIdHMz8qvQ1kbzoeleVVNXQ15S699EcK4WlTYVEEr9mUO3Z 1rftXKCycDSUECmhv5IUDXpdvhGxPFqLY9fZduaVWSyG/ggKuPerQeLe+AOoG8jyF+bI V6TzNeiMCwwMtQDh+r/HxKMK1wkVcivgOr+xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=dHpFpwQc5O7fyVeHf3CLVc4pDIwNwH/uIjdVFX7YQIm1c22kNeZX1MjYBOQmPOFxgA OyYISX6vu+mVjQwS8IjczDhbeHVQgmyQnJ5uAtxXTe7rcf0x8tc8cDy5f17jPhUxVGpk 32/6atya8P/RKZUNlAGPbVlNaAk8W+rVjaANQ= MIME-Version: 1.0 Received: by 10.211.145.15 with SMTP id x15mr5826165ebn.6.1251741874193; Mon, 31 Aug 2009 11:04:34 -0700 (PDT) In-Reply-To: <40C2A0A89CFE6F174BCCD299@Ximines.local> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> From: bert hubert Date: Mon, 31 Aug 2009 20:04:14 +0200 Message-ID: <3efd34cc0908311104y4d3842a3l374f342063b87b3b@mail.gmail.com> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes To: Alex Bligh Cc: Tony Finch , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 31, 2009 at 7:38 PM, Alex Bligh wrote: > Question: do stub resolvers on popular operating systems actually > fall back to TCP, and if so, do they pipeline? Some do. Sadly, it turns out there are multiple stubs in most popular operating systems, with some heavy DNS consumers choosing to roll their own. Some versions of Exchange are known to keep open TCP/IP sessions to a resolver for multiple queries. So it does happen, but it is not common practice. Bert From owner-namedroppers@ops.ietf.org Mon Aug 31 11:19: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 F3E6128C338; Mon, 31 Aug 2009 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=-0.785, 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 XNIorFF72cNt; Mon, 31 Aug 2009 11:19:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D1E528C459; Mon, 31 Aug 2009 11:19:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBPp-0007jo-AJ for namedroppers-data0@psg.com; Mon, 31 Aug 2009 18:15:41 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBPm-0007j1-0V for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 18:15:39 +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 4EE2B2FE8CB8 for ; Mon, 31 Aug 2009 18:15:36 +0000 (UTC) Date: Mon, 31 Aug 2009 14:15:31 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Presentation on DNSSEC that Google brought to my attention Message-ID: <20090831181531.GO13987@shinkuro.com> References: <20090828152742.GV7821@shinkuro.com> <20090828172315.GA11294@shinkuro.com> <20090828185715.GD11294@shinkuro.com> <20090828194551.GF11294@shinkuro.com> <4A9B8094.3020809@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 31, 2009 at 12:55:50AM -0700, Matthew Dempsky wrote: > Assuming the query to the parent name server uses standard DNS, then > yes. However, that's no different from DNSSEC and its DS records. > > The same way caches can be configured with DNSSEC trust anchors, they > can be configured with DNSCurve trust anchors. I'm feeling even more dense than usual, but this sounds to me like you're now saying DNSSEC and DNSCurve have the same property here: if an on-path attack happens, it can result in a DoS, because you detect the attack and reject the data as illegitimate. I don't see why this is supposed to be a big deal: it was the _goal_, in fact, to detect bad data and refuse it. Of course that results in a possible DoS from an on-path attacker. I have never heard of a data-alteration-detection mechanism that can't result in denial of service, in the event there is detected an alteration. The principle is generally that it is better to be turned off than to go to the wrong destination. Again, however, I'd be happy to be corrected. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 31 11:19: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 773D728C435; Mon, 31 Aug 2009 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=0.085, 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 0iQh3uDtYoTW; Mon, 31 Aug 2009 11:19:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FB1128C338; Mon, 31 Aug 2009 11:19:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBPn-0007jR-FI for namedroppers-data0@psg.com; Mon, 31 Aug 2009 18:15:39 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBPb-0007hp-Lu for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 18:15:29 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 9095DC2DA5; Mon, 31 Aug 2009 19:15:25 +0100 (BST) Date: Mon, 31 Aug 2009 19:15:24 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert cc: Tony Finch , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <4DCD3326E873449AD7F8AB92@Ximines.local> In-Reply-To: <3efd34cc0908311104y4d3842a3l374f342063b87b3b@mail.gmail.com> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <3efd34cc0908311104y4d3842a3l374f342063b87b3b@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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 August 2009 20:04:14 +0200 bert hubert wrote: > On Mon, Aug 31, 2009 at 7:38 PM, Alex Bligh wrote: >> Question: do stub resolvers on popular operating systems actually >> fall back to TCP, and if so, do they pipeline? > > Some do. Sadly, it turns out there are multiple stubs in most popular > operating systems, with some heavy DNS consumers choosing to roll > their own. > > Some versions of Exchange are known to keep open TCP/IP sessions to a > resolver for multiple queries. So it does happen, but it is not common > practice. Is it a fair assumption that to deploy DNSSEC a fair number of these stubs will need changing anyway? (and could thus be made to pipeline TCP requests) -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 11:24: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 E657528C476; Mon, 31 Aug 2009 11:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=-0.764, 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 Dx6uZ+zS64rz; Mon, 31 Aug 2009 11:24:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A5BE28C3CE; Mon, 31 Aug 2009 11:24:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBV9-0008dU-26 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 18:21:11 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiBV5-0008cq-Ax for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 18:21:09 +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 4E3CE2FE8CB8 for ; Mon, 31 Aug 2009 18:21:06 +0000 (UTC) Date: Mon, 31 Aug 2009 14:21:03 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC Message-ID: <20090831182103.GQ13987@shinkuro.com> References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> <200908272358.n7RNwrvr038970@drugs.dv.isc.org> <20090828144512.GT7821@shinkuro.com> <200908282207.n7SM73bf056581@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908282207.n7SM73bf056581@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sat, Aug 29, 2009 at 08:07:03AM +1000, Mark Andrews wrote: > > I note that adding a new RR is even easier now: we do it with expert > > review. Are you arguing for that route instead of RFC required? > > No. You were complaining about the lack of interop testing > due to there being no code point. If I left that impression, I apologise. That wasn't what I was complaining about. I was complaining that even uncontroversial code point additions, like SHA 256, take a very long time because the entire IETF WG consensus machinery comes into play. We need a lot of review, there's a tendency for side issues to get explored, and so on. If we had a lighter weight procedure, it wouldn't be so costly and it might therefore happen faster. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 31 12:14: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 AA0953A6EC0; Mon, 31 Aug 2009 12:14:37 -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=-0.276, 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 3UaGEbOpFoVE; Mon, 31 Aug 2009 12:14:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07BC528C4ED; Mon, 31 Aug 2009 12:12:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCAs-000FZv-Gl for namedroppers-data0@psg.com; Mon, 31 Aug 2009 19:04:18 +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 1MiCAp-000FZO-7l for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 19:04:16 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id BE3C4A9443B; Mon, 31 Aug 2009 19:04:14 +0000 (UTC) Message-ID: <4A9C1EAE.2080905@mail-abuse.org> Date: Mon, 31 Aug 2009 12:04:14 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Alex Bligh CC: Tony Finch , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> In-Reply-To: <40C2A0A89CFE6F174BCCD299@Ximines.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/31/09 10:38 AM, Alex Bligh wrote: > --On 31 August 2009 15:49:33 +0100 Tony Finch wrote: > >> Remember you should accommodate clients that pipeline multiple queries >> down the same TCP connection. [] > But in such circumstance, if TCP is consistently pipelined, the > adverse effect is at least somewhat reduced, as there will > be a single caching server being queried by the stub resolver, > so at least there won't be a constant stream of setups and > tear downs. > > Question: do stub resolvers on popular operating systems actually > fall back to TCP, and if so, do they pipeline? DNS message pipe-lining can significantly reduce response latency. However, for TCP, DNS message pipe-lining represents an expensive and complex mode of operation. Without transport level framing, TCP pipelines carrying DNS messages will need to buffer the entire stream subsequent to packet loss. However, SCTP processing of DNS messages can continue subsequent to unrecovered packets. It should be reasonable for DNS servers to limit pipeline operations to the SCTP transport, rather than being handled by the DNS application over TCP. SCTP can also be configured to require clients to re-issue DNS requests, rather than having DNS servers retain images of the DNS messages in transit. This too reduces the required buffering. The complexities related to TCP packet-loss represents a significant impediment to cost effective implementations, largely due to the significant amounts of memory involved. For TCP, buffering would be a function of the RTT and the network bandwidth. Alternatively, SCTP is able to avoid much this buffering requirement. SCTP could be employed to avoid having to upgrade DNS servers to support TCP pipelining. Once TCP is deemed essential, then the expense related to TCP buffering can not be avoided, and it would then represent a vulnerability when it necessitates significant increases in the number of servers. Transport modes that might be either unsafe or too expensive from a resource perspective should not be made essential. -Doug From owner-namedroppers@ops.ietf.org Mon Aug 31 12:27: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 4AF8D28C2D1; Mon, 31 Aug 2009 12:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU3p4PDEH-nY; Mon, 31 Aug 2009 12:27:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79E9C3A6B25; Mon, 31 Aug 2009 12:27:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCS8-000Ijt-Un for namedroppers-data0@psg.com; Mon, 31 Aug 2009 19:22:08 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCS5-000IjA-6i for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 19:22:07 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 63A92C2DA5; Mon, 31 Aug 2009 20:22:03 +0100 (BST) Date: Mon, 31 Aug 2009 20:22:02 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Douglas Otis cc: Tony Finch , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <4767C7EDD8F7E99968B9CA89@Ximines.local> In-Reply-To: <4A9C1EAE.2080905@mail-abuse.org> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 August 2009 12:04:14 -0700 Douglas Otis wrote: > DNS message pipe-lining can significantly reduce response latency. > However, for TCP, DNS message pipe-lining represents an expensive and > complex mode of operation. Without transport level framing, TCP > pipelines carrying DNS messages will need to buffer the entire stream > subsequent to packet loss. Right, but unless I'm missing something, that complexity is already handled by the TCP stacks at either end. As to expense, I would have thought handling n queries pipelined was less expensive than n setups and teardowns; clearly UDP and (for all I know) SCTP would be cheaper than either. > However, SCTP processing of DNS messages can continue subsequent to > unrecovered packets. I will take you word for it re SCTP, but I don't see how that helps here; by assumption, the middlebox is broken and not easily fixed/replaced, and thus extremely unlikely to be permeable to SCTP. Using SCTP requires not only a stub resolver change, but also a client IP stack change, a middlebox change, a nameserver s/w change, and a nameserver IP stack change. That is, I think, changing just about every component in the system, in order to address a problem with one component. I'm not saying TCP fallback is fine. I'm saying that where we might actually see it in practice because of broken middleboxen, it might be less bad than we thought because of pipelining (assuming the stub resolver that sets DO implements this). -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 12:28: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 948A328C2D1; Mon, 31 Aug 2009 12:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.188 X-Spam-Level: **** X-Spam-Status: No, score=4.188 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_26=0.6, 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 WEgo29D9z1YF; Mon, 31 Aug 2009 12:28:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5B283A6B25; Mon, 31 Aug 2009 12:28:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCVG-000JFH-2L for namedroppers-data0@psg.com; Mon, 31 Aug 2009 19:25:22 +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 1MiCVC-000JEg-3I for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 19:25:19 +0000 Received: (qmail 26751 invoked from network); 31 Aug 2009 19:35:31 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 31 Aug 2009 19:35:31 -0000 Message-ID: <4A9C2374.5090105@necom830.hpcl.titech.ac.jp> Date: Tue, 01 Sep 2009 04:24:36 +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: Mark Andrews CC: Nicholas Weaver , George Barwood , Alex Bligh , Doug Barton , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> <200908311520.n7VFK0Ti013253@drugs.dv.isc.org> In-Reply-To: <200908311520.n7VFK0Ti013253@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark Andrews wrote: >>During that time, I went through many more computers. The lifespan of >>these stupid boxes is annoyingly long. > There is another technology change which is just starting to happen > is a big way. Residential IPv6 is starting to be rolled out and > that will involve CPE box upgrades/replacements. The same boxes > that we want to be fixed are the ones that will be upgraded / > replaced to support IPv6 or to continue to support IPv4 when the > ISP moves its infrastructure to IPv6. Wrong. Instead, it is merely that any technology which requires CPE upgrades/replacements has significant difficulty for deployment. > I know I am waiting for a good AP+Router with IPv6 support to replace > the existing box. I'd like to know if DNS actually worked in it > before buying it. You assume that ISPs are willing to perform: support IPv6 modify COE for A+P replace CPE for A+P at the same time as they modify COE which is a lot more difficult than just support IPv6 even which is not happening. With end to end NAT, ISPs only need to modify COE for E2ENAT and they can forget IPv6 support forever. Customers may or may not upgrade end hosts. With the COE modification, we can recommend source port randomization that we don't have to support DNSSEC. > I don't know your mother. I do know lots of mothers followed such > instructions in the past successfully. According to your theory, both IPv6 and DNSSEC should have already been fully deployed. Masataka Ohta From owner-namedroppers@ops.ietf.org Mon Aug 31 12:49: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 BBFAE28C491; Mon, 31 Aug 2009 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 jXoQp4DZsjVm; Mon, 31 Aug 2009 12:49:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FDC828C4DD; Mon, 31 Aug 2009 12:47:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCmo-000NMM-5z for namedroppers-data0@psg.com; Mon, 31 Aug 2009 19:43:30 +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 1MiCmi-000NL0-C7 for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 19:43:28 +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 n7VJh8MQ019418; Mon, 31 Aug 2009 12:43:08 -0700 (PDT) Cc: Nicholas Weaver , Douglas Otis , Tony Finch , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Alex Bligh In-Reply-To: <4767C7EDD8F7E99968B9CA89@Ximines.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Mon, 31 Aug 2009 12:43:08 -0700 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 31, 2009, at 12:22 PM, Alex Bligh wrote: > > > --On 31 August 2009 12:04:14 -0700 Douglas Otis abuse.org> wrote: > >> DNS message pipe-lining can significantly reduce response latency. >> However, for TCP, DNS message pipe-lining represents an expensive and >> complex mode of operation. Without transport level framing, TCP >> pipelines carrying DNS messages will need to buffer the entire stream >> subsequent to packet loss. > > Right, but unless I'm missing something, that complexity is already > handled by the TCP stacks at either end. As to expense, I would have > thought handling n queries pipelined was less expensive than > n setups and teardowns; clearly UDP and (for all I know) SCTP > would be cheaper than either. THere are two resources and one property here: compute, memory, and setup latency. Dropping each TCP connection after a single query will require trivially more compute, but will be massive in terms of saving memory. Assume that each TCP connection requires 50KB in state to manage in the OS/kernel/etc. If you are handling 1000 new hosts/ second, and you maintain each TCP connection for 10 seconds, thats 500MB of state. Owch. But if you tear down each connection after the query is received, its almost NO state, as you don't need to allocate it until you get the last packet in the handshake, and you can immediately deallocate it once the query is responded (if you close with a RST so that you don't leave a half-open connection. Many webservers do this when closing open connections. Once you've decided to close a connection, leaving it half-open is pointless anyway.) The only disadvantage is now all TCP queries will see an additional 1RTT in latency for the handshake. In general, it is both far simpler and far less resource intensive to do "one query per TCP connection". The major reason why this is NOT done for HTTP is that additional 1-RTT latency, and, that for HTTP, you'd be forever stuck in slowstart. From owner-namedroppers@ops.ietf.org Mon Aug 31 13:05: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 34DD328C52B; Mon, 31 Aug 2009 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uifgZYcgv4Xi; Mon, 31 Aug 2009 13:05:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A0F128C45A; Mon, 31 Aug 2009 13:05:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiD3l-0000tJ-LC for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:01:01 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiD3h-0000sY-8E for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:00:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E458AB4B71 for ; Mon, 31 Aug 2009 20:00:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: Your message of "Mon, 31 Aug 2009 12:43:08 MST." References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 31 Aug 2009 20:00:56 +0000 Message-ID: <81591.1251748856@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Nicholas Weaver > Date: Mon, 31 Aug 2009 12:43:08 -0700 > ... > Dropping each TCP connection after a single query will require trivially > more compute, but will be massive in terms of saving memory. Assume that > each TCP connection requires 50KB in state to manage in the > OS/kernel/etc. If you are handling 1000 new hosts/ second, and you > maintain each TCP connection for 10 seconds, thats 500MB of state. Owch. > > But if you tear down each connection after the query is received, its > almost NO state, as you don't need to allocate it until you get the last > packet in the handshake, and you can immediately deallocate it once the > query is responded (if you close with a RST so that you don't leave a > half-open connection. Many webservers do this when closing open > connections. Once you've decided to close a connection, leaving it > half-open is pointless anyway.) > > The only disadvantage is now all TCP queries will see an additional 1RTT > in latency for the handshake. i propose that if we adopt a responder-close attitude toward TCP/53, that responders be permitted to close but not required to, and that a specific strategy mentioned in that specification be that if there is another query in the pipeline, already in the responder's input socket buffers at the time it has transmitted a response, that it consider answering the new query. that way if someone wants a lot of queries answered they can just pipeline. responders should also be allowed to use short timeouts (50ms?) or adaptive timeouts (shorter when there are more concurrent tcp sessions open or more QPS recently handled). something like this may lead to a situation where busy caching servers keep TCP sessions open to popular authority servers, and a session state DoS just slows that down to one query per session. > In general, it is both far simpler and far less resource intensive to do > "one query per TCP connection". The major reason why this is NOT done > for HTTP is that additional 1-RTT latency, and, that for HTTP, you'd be > forever stuck in slowstart. it's not just the slow start, it's all those web pages with 500 images on them, and the inability of both servers and browsers to open 500 tcp sessions at once to get them all in parallel. the couple of RTT's involved in TCP setup and teardown are a terrifying spectacle when doing 500 of them in serial. From owner-namedroppers@ops.ietf.org Mon Aug 31 13:17: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 3D1D328C526; Mon, 31 Aug 2009 13:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.080, 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 9GPKynv1un48; Mon, 31 Aug 2009 13:17:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E540A28C564; Mon, 31 Aug 2009 13:17:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDFV-0003Tp-L1 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:13:09 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDFR-0003ST-EW for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:13:07 +0000 Received: from [192.168.100.85] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id C9B86C2DA5; Mon, 31 Aug 2009 21:13:01 +0100 (BST) Date: Mon, 31 Aug 2009 21:13:09 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , Douglas Otis , Tony Finch , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: In-Reply-To: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Dropping each TCP connection after a single query will require trivially > more compute, but will be massive in terms of saving memory. Assume that > each TCP connection requires 50KB in state to manage in the > OS/kernel/etc. If you are handling 1000 new hosts/second, and you > maintain each TCP connection for 10 seconds, thats 500MB of state. Owch. Mmmm... it's been a while since I looked at this in a live kernel, but I thought the amount of STATE recorded per TCP session in the kernel was closer to 2.5kb (certainly less than a page). In addition to this, you need buffers, the size of which it is possible to control on a per socket basis. Assuming sensible values of buffering, you are well under half the above amount. Reduce the TCP hold time to 5 seconds, and you're at about 100Mb of memory, which these days is in the "so what" zone, I would have thought, for a dedicated caching resolver. > But if you tear down each connection after the query is received, its > almost NO state, as you don't need to allocate it until you get the last > packet in the handshake, and you can immediately deallocate it once the > query is responded (if you close with a RST so that you don't leave a > half-open connection. Many webservers do this when closing open > connections. Once you've decided to close a connection, leaving it > half-open is pointless anyway.) > > The only disadvantage is now all TCP queries will see an additional 1RTT > in latency for the handshake. Plus additional CPU overhead in setting up and tearing down the connection. I would bet handling 10 queries in one TCP session is substantially more lightweight than handling 10 separate TCP sessions. > In general, it is both far simpler and far less resource intensive to do > "one query per TCP connection". The major reason why this is NOT done > for HTTP is that additional 1-RTT latency, and, that for HTTP, you'd be > forever stuck in slowstart. Why don't the same arguments apply to DNS? If your average DNS packet is smaller, the extra 1 x RTT latency is proportionately going to be a more significant part of the transaction. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 13:24: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 C4A2D3A6EB2; Mon, 31 Aug 2009 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.876 X-Spam-Level: X-Spam-Status: No, score=-3.876 tagged_above=-999 required=5 tests=[AWL=-0.577, 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 WQj9XlF6ENWW; Mon, 31 Aug 2009 13:24:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 006BE3A6EC5; Mon, 31 Aug 2009 13:23:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDLW-0004oI-Eh for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:19:22 +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 1MiDLS-0004nR-CO for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:19: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]:56210) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1MiDLE-0006bZ-1B (Exim 4.70) (return-path ); Mon, 31 Aug 2009 21:19:04 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1MiDLE-0003nr-BI (Exim 4.67) (return-path ); Mon, 31 Aug 2009 21:19:04 +0100 Date: Mon, 31 Aug 2009 21:19:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Alex Bligh cc: Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: <40C2A0A89CFE6F174BCCD299@Ximines.local> Message-ID: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, 31 Aug 2009, Alex Bligh wrote: > > Question: do stub resolvers on popular operating systems actually > fall back to TCP, and if so, do they pipeline? The usual high-level resolver APIs don't allow pipelining, but GNU adns (for example) makes it easy. You can pipeline using the low-level resolver API but it's much more fiddly. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Mon Aug 31 13:24: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 AF52C3A6EB7; Mon, 31 Aug 2009 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.077, 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 nOqB5BfegRBh; Mon, 31 Aug 2009 13:24:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7251E3A6ECF; Mon, 31 Aug 2009 13:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDLj-0004rl-SS for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:19:35 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDLX-0004oN-Hm for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:19:26 +0000 Received: from [192.168.100.85] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id AA912C2DA5; Mon, 31 Aug 2009 21:19:20 +0100 (BST) Date: Mon, 31 Aug 2009 21:19:28 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , Nicholas Weaver cc: Nicholas Weaver , Douglas Otis , Tony Finch , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <607643A9B0AD2421ED943808@nimrod.local> In-Reply-To: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 August 2009 21:13:09 +0100 Alex Bligh wrote: > Mmmm... it's been a while since I looked at this in a live kernel, but > I thought the amount of STATE recorded per TCP session in the kernel > was closer to 2.5kb (certainly less than a page). In addition to this, > you need buffers, the size of which it is possible to control on > a per socket basis. Assuming sensible values of buffering, you are > well under half the above amount. Reduce the TCP hold time to 5 > seconds, and you're at about 100Mb of memory, which these days is > in the "so what" zone, I would have thought, for a dedicated > caching resolver. & the above would assume that the socket buffers are fully allocated all the time. It would be sensible for OSs to free socket buffer pages when they are empty, which they would be during the vast majority of the 10 second period you mention. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 13: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 300093A6EB7; Mon, 31 Aug 2009 13:24:22 -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 iJq3kcznEe9D; Mon, 31 Aug 2009 13:24:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8C4A3A6ED5; Mon, 31 Aug 2009 13:24:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDNQ-0005Ef-3s for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:21:20 +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 1MiDNM-0005Da-7V for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:21:17 +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 n7VKKwsA024451; Mon, 31 Aug 2009 13:20:58 -0700 (PDT) Cc: Nicholas Weaver , Douglas Otis , Tony Finch , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <25714F18-EFC2-402C-A63B-F19564FAF89C@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Alex Bligh In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Mon, 31 Aug 2009 13:20:58 -0700 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 31, 2009, at 1:13 PM, Alex Bligh wrote: >> Dropping each TCP connection after a single query will require >> trivially >> more compute, but will be massive in terms of saving memory. >> Assume that >> each TCP connection requires 50KB in state to manage in the >> OS/kernel/etc. If you are handling 1000 new hosts/second, and you >> maintain each TCP connection for 10 seconds, thats 500MB of state. >> Owch. > > Mmmm... it's been a while since I looked at this in a live kernel, but > I thought the amount of STATE recorded per TCP session in the kernel > was closer to 2.5kb (certainly less than a page). In addition to this, > you need buffers, the size of which it is possible to control on > a per socket basis. Assuming sensible values of buffering, you are > well under half the above amount. Reduce the TCP hold time to 5 > seconds, and you're at about 100Mb of memory, which these days is > in the "so what" zone, I would have thought, for a dedicated > caching resolver. Not necessarily. EG, until a packet is ACKed' the TCP stack needs to keep full sending state, which means it can easily be full-window. But I agree, with a short timeout, it should be "whatever". But you have those who insist the DNS spec is sancrosanct in saying you should keep these connections open for 2 minutes (which, thank god, nobody actually does). >> >> The only disadvantage is now all TCP queries will see an additional >> 1RTT >> in latency for the handshake. > > Plus additional CPU overhead in setting up and tearing down the > connection. This really is trivial. With SYN-cookies, its a trivial amount of compute to do. Remember, we are living in a very interesting world: Compute is "Free". State that isn't accessed is almost "free" too, but state which IS accessed is frightfully expensive. > I would bet handling 10 queries in one TCP session is substantially > more lightweight than handling 10 separate TCP sessions. I'd bet the difference is far smaller than you think. Anyone have any benchmarks? From owner-namedroppers@ops.ietf.org Mon Aug 31 13:29: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 748483A6EC2; Mon, 31 Aug 2009 13:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.494, 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 P9Nui8BsfNAX; Mon, 31 Aug 2009 13:29:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E2413A6EB3; Mon, 31 Aug 2009 13:29:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDRU-00063L-FC for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:25:32 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDRP-00062B-Rh for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:25:29 +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]:36258) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1MiDRF-0004HY-Pb (Exim 4.70) (return-path ); Mon, 31 Aug 2009 21:25:17 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1MiDRF-0004H0-Tm (Exim 4.67) (return-path ); Mon, 31 Aug 2009 21:25:17 +0100 Date: Mon, 31 Aug 2009 21:25:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Douglas Otis cc: Alex Bligh , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: <4A9C1EAE.2080905@mail-abuse.org> Message-ID: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.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: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, 31 Aug 2009, Douglas Otis wrote: > > DNS message pipe-lining can significantly reduce response latency. However, > for TCP, DNS message pipe-lining represents an expensive and complex mode of > operation. Without transport level framing, TCP pipelines carrying DNS > messages will need to buffer the entire stream subsequent to packet loss. It isn't really expensive or complex, at least as currently implemented. AFAIK neither the stubs nor the recursors worry about head-of-line blocking and it's common for recursors to process TCP requests in order. Even so, it works well as a fallback for that proportion of requests whose UDP responses get truncated (so the stub only needs two sockets open). Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Mon Aug 31 13: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 55C063A6EE6; Mon, 31 Aug 2009 13:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.875 X-Spam-Level: X-Spam-Status: No, score=-105.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 PGufuojUwulY; Mon, 31 Aug 2009 13:32:05 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 071893A6EE5; Mon, 31 Aug 2009 13:31:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDUQ-0006Vj-TT for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:28:34 +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 1MiDUN-0006Tc-7l for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:28:33 +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 n7VKSS5h025519; Mon, 31 Aug 2009 13:28:28 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Paul Vixie In-Reply-To: <81591.1251748856@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Date: Mon, 31 Aug 2009 13:28:28 -0700 References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> <81591.1251748856@nsa.vix.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Aug 31, 2009, at 1:00 PM, Paul Vixie wrote: > i propose that if we adopt a responder-close attitude toward TCP/53, > that > responders be permitted to close but not required to, and that a > specific > strategy mentioned in that specification be that if there is another > query > in the pipeline, already in the responder's input socket buffers at > the > time it has transmitted a response, that it consider answering the new > query. that way if someone wants a lot of queries answered they can > just > pipeline. responders should also be allowed to use short timeouts > (50ms?) > or adaptive timeouts (shorter when there are more concurrent tcp > sessions > open or more QPS recently handled). > > something like this may lead to a situation where busy caching > servers keep > TCP sessions open to popular authority servers, and a session state > DoS just > slows that down to one query per session. This makes a lot of sense. You can avoid the overhead in the case where things are persistent, but not hold the state. However, simpler heuristics would work just as well. EG, "When under state pressure, close in an Least Recently Used" fashion: close most-idle first, and close with a RST to free all state immediately. This would have the same effect, really: you can always answer a new TCP query (which requires near-zero state), and old persistent connections can stick around for as long as possible. >> In general, it is both far simpler and far less resource intensive >> to do >> "one query per TCP connection". The major reason why this is NOT >> done >> for HTTP is that additional 1-RTT latency, and, that for HTTP, >> you'd be >> forever stuck in slowstart. > > it's not just the slow start, it's all those web pages with 500 > images on > them, and the inability of both servers and browsers to open 500 tcp > sessions at once to get them all in parallel. the couple of RTT's > involved > in TCP setup and teardown are a terrifying spectacle when doing 500 > of them > in serial. The 1 RTT latency... Latency is a shocking killer in the Web world, its part of the reason HTTPS isn't ubiquitous: https requires several more RTTs to set up a connection. From owner-namedroppers@ops.ietf.org Mon Aug 31 13: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 65DE93A6EE5; Mon, 31 Aug 2009 13:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDr4RstHQ8Pv; Mon, 31 Aug 2009 13:32:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EF1E3A6EE9; Mon, 31 Aug 2009 13:31:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDTn-0006PW-BM for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:27:55 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDTj-0006Or-QT for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:27:53 +0000 Received: from [192.168.100.85] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 08A6DC2DA5; Mon, 31 Aug 2009 21:27:48 +0100 (BST) Date: Mon, 31 Aug 2009 21:27:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , Douglas Otis , Tony Finch , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] root DNSKEY response is 1749 bytes Message-ID: <5C5293FF59FB4D9130B09321@nimrod.local> In-Reply-To: <25714F18-EFC2-402C-A63B-F19564FAF89C@ICSI.Berkeley.EDU> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> <25714F18-EFC2-402C-A63B-F19564FAF89C@ICSI.Berkeley.EDU> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 August 2009 13:20:58 -0700 Nicholas Weaver wrote: >> Plus additional CPU overhead in setting up and tearing down the >> connection. > > This really is trivial. With SYN-cookies, its a trivial amount of > compute to do. It wasn't so much that bit I was worried about, as the allocating/deallocating of a new FD etc. A /dis/advantage of pipelining is going to be that you are potentially more prone to FD exhaustion. >> I would bet handling 10 queries in one TCP session is substantially >> more lightweight than handling 10 separate TCP sessions. > > I'd bet the difference is far smaller than you think. Anyone have any > benchmarks? This would be a better idea than both of us speculating :-) -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 31 13:35: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 A8B2428C527; Mon, 31 Aug 2009 13:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMVecQ+xdfqM; Mon, 31 Aug 2009 13:35:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7DF928C430; Mon, 31 Aug 2009 13:35:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDXi-00071S-57 for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:31:58 +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 1MiDXd-00070o-Io for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:31:55 +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]:45764) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1MiDXc-0001yD-6J (Exim 4.70) (return-path ); Mon, 31 Aug 2009 21:31:52 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1MiDXc-0004lx-UH (Exim 4.67) (return-path ); Mon, 31 Aug 2009 21:31:52 +0100 Date: Mon, 31 Aug 2009 21:31:52 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-Reply-To: <81591.1251748856@nsa.vix.com> Message-ID: References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> <4767C7EDD8F7E99968B9CA89@Ximines.local> <81591.1251748856@nsa.vix.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, 31 Aug 2009, Paul Vixie wrote: > Nicholas Weaver wrote: > > > > In general, it is both far simpler and far less resource intensive to do > > "one query per TCP connection". The major reason why this is NOT done > > for HTTP is that additional 1-RTT latency, and, that for HTTP, you'd be > > forever stuck in slowstart. > > it's not just the slow start, it's all those web pages with 500 images on > them, and the inability of both servers and browsers to open 500 tcp > sessions at once to get them all in parallel. the couple of RTT's involved > in TCP setup and teardown are a terrifying spectacle when doing 500 of them > in serial. Especially when the round trip includes a POTS modem :-) The other big reason is that TCP congestion control takes a while to get going. In the mid-1990s many people were predicting the imminent death of the net due to congestion collapse caused by most TCP connections being too short-lived. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Mon Aug 31 14:02: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 635EB28C458; Mon, 31 Aug 2009 14:02:57 -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 kCLZVwV+1DI6; Mon, 31 Aug 2009 14:02:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12EFF28C4BE; Mon, 31 Aug 2009 14:02:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDwf-000BGk-2t for namedroppers-data0@psg.com; Mon, 31 Aug 2009 20:57:45 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:956f] (helo=out-71.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiDwa-000BGH-FF for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 20:57:42 +0000 Received: from smtp-14.smtp.ucla.edu (smtp-14.smtp.ucla.edu [169.232.46.250]) by out-71.smtp.ucla.edu with ESMTP id n7VKucSI031367; Mon, 31 Aug 2009 13:56:44 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VKucSI031367; Mon, 31 Aug 2009 13:56:38 -0700 Received: from [172.16.0.2] (Clippers.CS.UCLA.EDU [131.179.96.72]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VKa9s8017915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2009 13:41:19 -0700 Cc: namedroppers@ops.ietf.org Message-Id: From: Eric Osterweil To: Olafur Gudmundsson/DNSEXT chair In-Reply-To: <200908251744.n7PHiqmI073529@stora.ogud.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-713141185" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Mon, 31 Aug 2009 14:32:44 -0600 References: <200908251744.n7PHiqmI073529@stora.ogud.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.250 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25-713141185 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Sorry for the Johnny-come-lately response: On Aug 25, 2009, at 11:44 AM, Olafur Gudmundsson/DNSEXT chair wrote: > > Dear colleagues, > > After reading all the messages on EDNS0 buffer sizes and fallback > your chairs have huddled and tried to agree on an approach to go =20 > forward > and what/if protocol work is needed. > > For the sake of argument we want to limit the discussion to > "ENDS0 capable entities" > and their behavior. The goal is to minimize fallback. > By decreasing fallback cases we speed up DNS resolution for everyone. > > We think that the current evidence suggests three main problems: > - inability or refusal to handle UDP packets larger than 600 bytes. > - inability or refusal to handle UDP fragments. > - failure to set the advertised EDNS0 buffer sizes correctly given > the actual network conditions > > Model: > A is the issuer of a DNS query > B is the target server of the query > > A <---pipe1---> INTERNET <----pipe2----> B > > If A advertises a ENDS0 buffer size that is larger than will go =20 > through > "pipe1" then B may send back an answer that is larger than fits =20 > through the > pipe. Then A will time-out and do a fallback. > > If B attempts to put an answer into "pipe2" that is larger than fits =20= > into > it A will not get an answer and will do a fallback. > > If both A and B know the "width" of their LOCAL pipes fallback > between them is rare and if B has an answer that does not fit, it will > set the TC bit. > > If the problem is actually in the INTERNET part of the diagram, > fallback is needed no matter what. We can put of evaluation of how > much of the problem is in fact in the middle, because we know for sure > right now that there are problems at the end points. Since those are > under the control of the affected parties, we can tackle this problem > first. > > The assumption here is A and B can detect the "width" of their local =20= > pipes > and either fix them or set UDP-buffersize parameters to values that =20= > their > local pipe will pass. If either A or B have multiple paths to the =20 > Internet > they should set their buffer sizes to the smallest pipe width. > In particular B should NEVER provide an answer to a normal (i.e. non =20= > ANY and > non RRSIG) query that does not pass through "Pipe2". > > Work to be done: > - Provide tools that measure local pipes and provide configuration =20= > hints We presented dnsfunnel for this at IETF 75, and I think it would be =20 great for people to download it and try it out to see this for =20 themselves: http://www.vantage-points.org/ You can point dnsfunnel at any zone and it will tell you if there is a =20= problem and what sizes fit. This has the benefit of testing the path =20= from _your_ stub to each name server in whichever zone you aim it at. Eric =E9 > > - Educate users to use the tools, where to look for problems and how > to update configurations. > - Make the firewall community aware that firewall's are causing DNS =20= > problems > and educate them in how to update their configurations, to allow =20 > well > formed UDP fragments to pass. (i.e. non overlapping fragments) > - ditto for DNS proxy vendors. > - Improve EDNS0 fallback strategies. > > Only the last one is a protocol work that DNSEXT can undertake, all =20= > the others > are external educations activities that are outside the scope of the =20= > working > group. > > As DNS is not the only UDP based protocol that is affected by the =20 > restrictions on > UDP packets, modifying DNS to work around misbehaving middle boxes =20 > is counter > productive to making the Internet better in the long run. > Adding complexity to DNS to handle the misbehaving units is a wasted =20= > effort > as the educational tasks will still have to be undertaken and =20 > provide a > quicker return on investment. > > Olafur & Andrew --Apple-Mail-25-713141185 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 v2.0.9 (Darwin) iEYEARECAAYFAkqcM2wACgkQK/tq6CJjZQJHzQCfRh1wCXy9MeMfDmSTrzzLsWhk 8LQAn1rSmIHoi+l8KnGE5UNPNuBzL/zs =LlDR -----END PGP SIGNATURE----- --Apple-Mail-25-713141185-- From owner-namedroppers@ops.ietf.org Mon Aug 31 14:15: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 2639D3A6EFA; Mon, 31 Aug 2009 14:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 N4nOjhW9F6fS; Mon, 31 Aug 2009 14:15:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC42A3A6EF7; Mon, 31 Aug 2009 14:15:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiE9n-000D1b-Gc for namedroppers-data0@psg.com; Mon, 31 Aug 2009 21:11:19 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiE9j-000D17-W1 for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 21:11:17 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D1A49E601E; Mon, 31 Aug 2009 21:11: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 n7VLBBko016730; Tue, 1 Sep 2009 07:11:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908312111.n7VLBBko016730@drugs.dv.isc.org> To: Alex Bligh Cc: Tony Finch , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes In-reply-to: Your message of "Mon, 31 Aug 2009 18:38:36 +0100." <40C2A0A89CFE6F174BCCD299@Ximines.local> Date: Tue, 01 Sep 2009 07:11:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <40C2A0A89CFE6F174BCCD299@Ximines.local>, Alex Bligh writes: > > > --On 31 August 2009 15:49:33 +0100 Tony Finch wrote: > > >> Whats wrong with "When state exceeds LRU, close", or heck, "If a 'normal' > >> query, close connection when complete". > > > > Remember you should accommodate clients that pipeline multiple queries > > down the same TCP connection. > > Hmmm... Elsewhere Mark Andrews suggested that in extremis clients behind > broken middleboxen could simply have their nameservers manually coded > to resolvers outside the broken middlebox (rather than use the middlebox > itself). > > For these, plus middleboxes which just pass through the external > nameserver's address, there is still a problem if they drop > UDP fragments or otherwise prevent long answers that aren't > addressed to the middlebox, causing TCP fallback. > > But in such circumstance, if TCP is consistently pipelined, the > adverse effect is at least somewhat reduced, as there will > be a single caching server being queried by the stub resolver, > so at least there won't be a constant stream of setups and > tear downs. > > Question: do stub resolvers on popular operating systems actually > fall back to TCP, and if so, do they pipeline? Yes and yes if requested by the application. This has been the case since BIND 4.8 days. This is also one of the reason how I can't understand how a DNS proxy can fail to support TCP since there have been stub resolvers that fallback to TCP the entire time. No real testing was ever done to see what enviroment they were going into. TCP queries, due to TC=1 being set, were rare but not non-existant. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 14:18: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 D5B2F3A6EFA; Mon, 31 Aug 2009 14:18:17 -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 XBG7lt3GJbRq; Mon, 31 Aug 2009 14:18:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66BBB3A6EEA; Mon, 31 Aug 2009 14:18:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEBc-000DKA-Ld for namedroppers-data0@psg.com; Mon, 31 Aug 2009 21:13:12 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febe:116e] (helo=out-61.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEBX-000DJO-MC for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 21:13:09 +0000 Received: from smtp-12.smtp.ucla.edu (smtp-12.smtp.ucla.edu [169.232.46.248]) by out-61.smtp.ucla.edu with ESMTP id n7VLCSBC013205; Mon, 31 Aug 2009 14:12:29 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-12.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VLCSBC013205; Mon, 31 Aug 2009 14:12:28 -0700 Received: from [172.16.0.2] (Clippers.CS.UCLA.EDU [131.179.96.72]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VKpjkg019669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2009 13:57:01 -0700 Cc: namedroppers@ops.ietf.org Message-Id: From: Eric Osterweil To: Olafur Gudmundsson/DNSEXT chair In-Reply-To: <200908251744.n7PHiqmI073529@stora.ogud.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-713141185" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Mon, 31 Aug 2009 14:32:44 -0600 References: <200908251744.n7PHiqmI073529@stora.ogud.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.248 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25-713141185 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Sorry for the Johnny-come-lately response: On Aug 25, 2009, at 11:44 AM, Olafur Gudmundsson/DNSEXT chair wrote: > > Dear colleagues, > > After reading all the messages on EDNS0 buffer sizes and fallback > your chairs have huddled and tried to agree on an approach to go =20 > forward > and what/if protocol work is needed. > > For the sake of argument we want to limit the discussion to > "ENDS0 capable entities" > and their behavior. The goal is to minimize fallback. > By decreasing fallback cases we speed up DNS resolution for everyone. > > We think that the current evidence suggests three main problems: > - inability or refusal to handle UDP packets larger than 600 bytes. > - inability or refusal to handle UDP fragments. > - failure to set the advertised EDNS0 buffer sizes correctly given > the actual network conditions > > Model: > A is the issuer of a DNS query > B is the target server of the query > > A <---pipe1---> INTERNET <----pipe2----> B > > If A advertises a ENDS0 buffer size that is larger than will go =20 > through > "pipe1" then B may send back an answer that is larger than fits =20 > through the > pipe. Then A will time-out and do a fallback. > > If B attempts to put an answer into "pipe2" that is larger than fits =20= > into > it A will not get an answer and will do a fallback. > > If both A and B know the "width" of their LOCAL pipes fallback > between them is rare and if B has an answer that does not fit, it will > set the TC bit. > > If the problem is actually in the INTERNET part of the diagram, > fallback is needed no matter what. We can put of evaluation of how > much of the problem is in fact in the middle, because we know for sure > right now that there are problems at the end points. Since those are > under the control of the affected parties, we can tackle this problem > first. > > The assumption here is A and B can detect the "width" of their local =20= > pipes > and either fix them or set UDP-buffersize parameters to values that =20= > their > local pipe will pass. If either A or B have multiple paths to the =20 > Internet > they should set their buffer sizes to the smallest pipe width. > In particular B should NEVER provide an answer to a normal (i.e. non =20= > ANY and > non RRSIG) query that does not pass through "Pipe2". > > Work to be done: > - Provide tools that measure local pipes and provide configuration =20= > hints We presented dnsfunnel for this at IETF 75, and I think it would be =20 great for people to download it and try it out to see this for =20 themselves: http://www.vantage-points.org/ You can point dnsfunnel at any zone and it will tell you if there is a =20= problem and what sizes fit. This has the benefit of testing the path =20= from _your_ stub to each name server in whichever zone you aim it at. Eric =E9 > > - Educate users to use the tools, where to look for problems and how > to update configurations. > - Make the firewall community aware that firewall's are causing DNS =20= > problems > and educate them in how to update their configurations, to allow =20 > well > formed UDP fragments to pass. (i.e. non overlapping fragments) > - ditto for DNS proxy vendors. > - Improve EDNS0 fallback strategies. > > Only the last one is a protocol work that DNSEXT can undertake, all =20= > the others > are external educations activities that are outside the scope of the =20= > working > group. > > As DNS is not the only UDP based protocol that is affected by the =20 > restrictions on > UDP packets, modifying DNS to work around misbehaving middle boxes =20 > is counter > productive to making the Internet better in the long run. > Adding complexity to DNS to handle the misbehaving units is a wasted =20= > effort > as the educational tasks will still have to be undertaken and =20 > provide a > quicker return on investment. > > Olafur & Andrew --Apple-Mail-25-713141185 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 v2.0.9 (Darwin) iEYEARECAAYFAkqcM2wACgkQK/tq6CJjZQJHzQCfRh1wCXy9MeMfDmSTrzzLsWhk 8LQAn1rSmIHoi+l8KnGE5UNPNuBzL/zs =LlDR -----END PGP SIGNATURE----- --Apple-Mail-25-713141185-- From owner-namedroppers@ops.ietf.org Mon Aug 31 14:34: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 A12E528C308; Mon, 31 Aug 2009 14:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 jrq-qhbliLS7; Mon, 31 Aug 2009 14:34:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 875E83A6BF1; Mon, 31 Aug 2009 14:34:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEU1-000Ge1-Dp for namedroppers-data0@psg.com; Mon, 31 Aug 2009 21:32:13 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiETx-000Gd4-NF for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 21:32:11 +0000 Received: by ewy11 with SMTP id 11so4112890ewy.11 for ; Mon, 31 Aug 2009 14:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=BKiCEM2h6QUSY9R9YGLfCJMofvlmAbAsq5Ovh7oSF1A=; b=hGSqpR2LGf8+bruk+lcOqslUT5FDFdjw/z+eXl93kcB5EwZiRr84zRL2oBAYlpqi/m fq3HrsPitu5HW7AEFlCI+Q+6OZJumBAJuJ7Iq+weDMio/zJzfp5pjL/T3vVl8nn3BqCU fshb3zJlrDlt536L5N6TrYtRZUHQ1GOXgf7qE= 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=vY0X0Kvxj+Hz0Yozwj6tPRsUoRPCNAIr6DM03ynCz+RMH4krz2sjxhx5len8ivp8t3 YF8LRN9n5mj91T9gkd3AxUhxgiG1GTuyGLAQJVm9BkKiknaJlWavE1QD/RxN6TsYkPVp JC15/tRkFERL4IApc4/7i9qmVybAOeKWCUp1Q= MIME-Version: 1.0 Received: by 10.211.179.15 with SMTP id g15mr5065491ebp.94.1251754325087; Mon, 31 Aug 2009 14:32:05 -0700 (PDT) In-Reply-To: <200908312111.n7VLBBko016730@drugs.dv.isc.org> References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <200908312111.n7VLBBko016730@drugs.dv.isc.org> From: bert hubert Date: Mon, 31 Aug 2009 23:31:40 +0200 Message-ID: <3efd34cc0908311431x48eb17f1s6beb3281c934a842@mail.gmail.com> Subject: Re: [dnsext] root DNSKEY response is 1749 bytes To: Mark Andrews Cc: Alex Bligh , Tony Finch , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 31, 2009 at 11:11 PM, Mark Andrews wrote: > Yes and yes if requested by the application. =A0This has been the > case since BIND 4.8 days. =A0This is also one of the reason how I > can't understand how a DNS proxy can fail to support TCP since there > have been stub resolvers that fallback to TCP the entire time. > > No real testing was ever done to see what enviroment they were going > into. =A0TCP queries, due to TC=3D1 being set, were rare but not > non-existant. I estimate that your average Windows based end-user ('client') PC spends its whole life without ever doing a single TCP/IP DNS request. I would not even be very surprised if it turns out the default Windows stub can't do it. Bert From owner-namedroppers@ops.ietf.org Mon Aug 31 14: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 2B74628C308; Mon, 31 Aug 2009 14:34:52 -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 IId-nKjtJnO6; Mon, 31 Aug 2009 14:34:50 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 39C933A6C5B; Mon, 31 Aug 2009 14:34:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiERr-000GI3-OZ for namedroppers-data0@psg.com; Mon, 31 Aug 2009 21:29:59 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febf:cfa7] (helo=out-56.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiERn-000GHL-Im for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 21:29:57 +0000 Received: from smtp-11.smtp.ucla.edu (smtp-11.smtp.ucla.edu [169.232.46.244]) by out-56.smtp.ucla.edu with ESMTP id n7VLTMEl000423; Mon, 31 Aug 2009 14:29:22 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-11.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VLTMEl000423; Mon, 31 Aug 2009 14:29:22 -0700 Received: from [172.16.0.2] (Clippers.CS.UCLA.EDU [131.179.96.72]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VL7Y2U021472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2009 14:12:43 -0700 Cc: Alex Bligh , "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org Message-Id: <64917DCD-ADCF-441E-B836-22B2AF2B8F66@cs.ucla.edu> From: Eric Osterweil To: Nicholas Weaver In-Reply-To: <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-713333626" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Mon, 31 Aug 2009 14:35:56 -0600 References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.244 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-713333626 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 25, 2009, at 1:31 PM, Nicholas Weaver wrote: > > On Aug 25, 2009, at 11:32 AM, Alex Bligh wrote: > >> >> >> --On 25 August 2009 13:44:28 -0400 "Olafur Gudmundsson/DNSEXT =20 >> chair" wrote: >> >>> Work to be done: >>> - Provide tools that measure local pipes and provide =20 >>> configuration hints >>> - Educate users to use the tools, where to look for problems and =20= >>> how >>> to update configurations. >>> - Make the firewall community aware that firewall's are causing DNS >>> problems >>> and educate them in how to update their configurations, to allow =20= >>> well >>> formed UDP fragments to pass. (i.e. non overlapping fragments) >>> - ditto for DNS proxy vendors. >>> - Improve EDNS0 fallback strategies. >>> >>> Only the last one is a protocol work that DNSEXT can undertake, =20 >>> all the >>> others are external educations activities that are outside the scope >>> of the working group. >> >> a) Re 2nd & 3rd, was BCP 152 / RFC 5625 out of scope for the =20 >> working group? >> >> b) I note that as currently formulated, 4th would exclude (e.g.) =20 >> EDNS Paging >> strategies if not implemented as a fallback). Is this deliberate? >> It might be that the best strategy when querying for DNSSEC records =20= >> is >> to use as a first strategy (rather than a fallback) a technique that >> that will allow replies greater than 1492 bytes without >> fragmentation, given large replies seem common and there seems to be >> at some degree of support for the idea that either fragmentation is >> bad and should be avoided per se (even if middleboxen were perfectly >> behaved), or that it is commonly dropped by middleboxen. Perhaps your >> final para (which I chopped off - sorry) precludes this approach. > > Its actually interesting. I'll argue as follows: > > Fragmentation is NOT a problem for ~85% +/- some delta of =20 > resolvers. Which means, for MOST resolvers, its OK if the response =20= > fragments. So let the responses be large, we have these large =20 > DNSSEC responses anyway, so go for it. > > > > But fragmentation IS a problem for ~15%. > > This is probably too large a number for education strategies to =20 > work, since that requires upgrading/replacing existing middleboxes. > > And too large a number for any strategy which requires timeouts per =20= > authority before deciding its a problem, which will kill performance =20= > and cause "DNSSEC is broken" complaints once .com starts signing data. > > But it is a small enough number that these CAN specify an EDNS =20 > buffer small enough to fragment, if the resolver can detect that its =20= > a global problem, with fallback to TCP on truncation: you're talking =20= > ~10-20% of the total queries, assuming all responses exceed the =20 > ~1400 MTU of a typical fallback: significant but hardly a killer. First, a caveat: this is a position I completely agree with (as I =20 think I've advocated it since the very beginning, back in 2008). However, I think this discussion needs to keep in mind that this is a =20= moving target. Key-set sizes change as keys and revocations, etc are =20= added and removed. Moreover, the path characteristics change too. =20 This is why SecSpider is doing a longitudinal study. If we say 85% =20 today, it does not necessarily mean this will be the right # tomorrow. Ultimately, I think a the protocol should expose semantics that let =20 client code adapt to these PMTU problems as it encounters them. This =20 should let resolvers handle problems without any operator intervention. > > > Especially since the .org TCP load is probably representative: =20 > significant but should be tolerable. Resolvers behind broken =20 > middleboxes will today do the fallback to TCP eventually when =20 > querying .org for a large response, they are just going through an =20 > annoying, performance-killing timeout first. > > > > As for authorities, if the authority has a problem SENDING =20 > fragments, let it get hammered by having all its responses over =20 > TCP: Either it can keep up with the load and they only see an extra =20= > couple of RTTs on DNS lookups, or it falls over dead until the =20 > offending middlebox get fixed: a self-correcting situation. > > > And as for the rest of the Internet protocols, I think its probably =20= > safe to say everyone else has given up on UDP fragments working =20 > always on the Internet, judging by the workarounds for IKE. Thus I =20= > don't see the particular problem in the DNS protocol saying "We MUST =20= > NOT rely on UDP fragmentation working in all cases, but MAY rely on =20= > fragmentation working in most cases" > > Therefore, I believe the objective should be "Make sure that DNSSEC =20= > works on an Internet that MOSTLY is OK with UDP fragments, but =20 > understands that some resolvers can't handle fragments, and some =20 > authorities can't handle fragments", without ANY protocol changes =20 > and single-sided changes to just resolvers. Which appears quite =20 > doable. How about, make DNSSEC avoid falling back to fragmented UDP packets =20 when it can avoid this by detecting PMTU limits? THen there is no =20 declaration about the brokenness of anything, simply a statement of =20 how to proceed? Eric =E9 --Apple-Mail-26-713333626 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 v2.0.9 (Darwin) iEYEARECAAYFAkqcNCwACgkQK/tq6CJjZQI4FwCfVNWKoqPkTN5MpjCN3zfzSX4Z vncAmwe24SgaeNybearhgAJMd+iQTDVR =2apG -----END PGP SIGNATURE----- --Apple-Mail-26-713333626-- From owner-namedroppers@ops.ietf.org Mon Aug 31 14:36: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 B02F03A6EA3; Mon, 31 Aug 2009 14:36:59 -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 oES1PQUjlLfc; Mon, 31 Aug 2009 14:36:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C907A28C308; Mon, 31 Aug 2009 14:36:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEVr-000Gx7-WB for namedroppers-data0@psg.com; Mon, 31 Aug 2009 21:34:08 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:956f] (helo=out-71.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEVn-000GwI-5V for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 21:34:05 +0000 Received: from smtp-14.smtp.ucla.edu (smtp-14.smtp.ucla.edu [169.232.46.250]) by out-71.smtp.ucla.edu with ESMTP id n7VLXTLI029108; Mon, 31 Aug 2009 14:33:30 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VLXTLI029108; Mon, 31 Aug 2009 14:33:29 -0700 Received: from [172.16.0.3] (Clippers.CS.UCLA.EDU [131.179.96.72]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VLXIi6019210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2009 14:33:21 -0700 Cc: Alex Bligh , "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org Message-Id: <64917DCD-ADCF-441E-B836-22B2AF2B8F66@cs.ucla.edu> From: Eric Osterweil To: Nicholas Weaver In-Reply-To: <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-713333626" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Mon, 31 Aug 2009 14:35:56 -0600 References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.250 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-713333626 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Aug 25, 2009, at 1:31 PM, Nicholas Weaver wrote: > > On Aug 25, 2009, at 11:32 AM, Alex Bligh wrote: > >> >> >> --On 25 August 2009 13:44:28 -0400 "Olafur Gudmundsson/DNSEXT =20 >> chair" wrote: >> >>> Work to be done: >>> - Provide tools that measure local pipes and provide =20 >>> configuration hints >>> - Educate users to use the tools, where to look for problems and =20= >>> how >>> to update configurations. >>> - Make the firewall community aware that firewall's are causing DNS >>> problems >>> and educate them in how to update their configurations, to allow =20= >>> well >>> formed UDP fragments to pass. (i.e. non overlapping fragments) >>> - ditto for DNS proxy vendors. >>> - Improve EDNS0 fallback strategies. >>> >>> Only the last one is a protocol work that DNSEXT can undertake, =20 >>> all the >>> others are external educations activities that are outside the scope >>> of the working group. >> >> a) Re 2nd & 3rd, was BCP 152 / RFC 5625 out of scope for the =20 >> working group? >> >> b) I note that as currently formulated, 4th would exclude (e.g.) =20 >> EDNS Paging >> strategies if not implemented as a fallback). Is this deliberate? >> It might be that the best strategy when querying for DNSSEC records =20= >> is >> to use as a first strategy (rather than a fallback) a technique that >> that will allow replies greater than 1492 bytes without >> fragmentation, given large replies seem common and there seems to be >> at some degree of support for the idea that either fragmentation is >> bad and should be avoided per se (even if middleboxen were perfectly >> behaved), or that it is commonly dropped by middleboxen. Perhaps your >> final para (which I chopped off - sorry) precludes this approach. > > Its actually interesting. I'll argue as follows: > > Fragmentation is NOT a problem for ~85% +/- some delta of =20 > resolvers. Which means, for MOST resolvers, its OK if the response =20= > fragments. So let the responses be large, we have these large =20 > DNSSEC responses anyway, so go for it. > > > > But fragmentation IS a problem for ~15%. > > This is probably too large a number for education strategies to =20 > work, since that requires upgrading/replacing existing middleboxes. > > And too large a number for any strategy which requires timeouts per =20= > authority before deciding its a problem, which will kill performance =20= > and cause "DNSSEC is broken" complaints once .com starts signing data. > > But it is a small enough number that these CAN specify an EDNS =20 > buffer small enough to fragment, if the resolver can detect that its =20= > a global problem, with fallback to TCP on truncation: you're talking =20= > ~10-20% of the total queries, assuming all responses exceed the =20 > ~1400 MTU of a typical fallback: significant but hardly a killer. First, a caveat: this is a position I completely agree with (as I =20 think I've advocated it since the very beginning, back in 2008). However, I think this discussion needs to keep in mind that this is a =20= moving target. Key-set sizes change as keys and revocations, etc are =20= added and removed. Moreover, the path characteristics change too. =20 This is why SecSpider is doing a longitudinal study. If we say 85% =20 today, it does not necessarily mean this will be the right # tomorrow. Ultimately, I think a the protocol should expose semantics that let =20 client code adapt to these PMTU problems as it encounters them. This =20 should let resolvers handle problems without any operator intervention. > > > Especially since the .org TCP load is probably representative: =20 > significant but should be tolerable. Resolvers behind broken =20 > middleboxes will today do the fallback to TCP eventually when =20 > querying .org for a large response, they are just going through an =20 > annoying, performance-killing timeout first. > > > > As for authorities, if the authority has a problem SENDING =20 > fragments, let it get hammered by having all its responses over =20 > TCP: Either it can keep up with the load and they only see an extra =20= > couple of RTTs on DNS lookups, or it falls over dead until the =20 > offending middlebox get fixed: a self-correcting situation. > > > And as for the rest of the Internet protocols, I think its probably =20= > safe to say everyone else has given up on UDP fragments working =20 > always on the Internet, judging by the workarounds for IKE. Thus I =20= > don't see the particular problem in the DNS protocol saying "We MUST =20= > NOT rely on UDP fragmentation working in all cases, but MAY rely on =20= > fragmentation working in most cases" > > Therefore, I believe the objective should be "Make sure that DNSSEC =20= > works on an Internet that MOSTLY is OK with UDP fragments, but =20 > understands that some resolvers can't handle fragments, and some =20 > authorities can't handle fragments", without ANY protocol changes =20 > and single-sided changes to just resolvers. Which appears quite =20 > doable. How about, make DNSSEC avoid falling back to fragmented UDP packets =20 when it can avoid this by detecting PMTU limits? THen there is no =20 declaration about the brokenness of anything, simply a statement of =20 how to proceed? Eric =E9 --Apple-Mail-26-713333626 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 v2.0.9 (Darwin) iEYEARECAAYFAkqcNCwACgkQK/tq6CJjZQI4FwCfVNWKoqPkTN5MpjCN3zfzSX4Z vncAmwe24SgaeNybearhgAJMd+iQTDVR =2apG -----END PGP SIGNATURE----- --Apple-Mail-26-713333626-- From owner-namedroppers@ops.ietf.org Mon Aug 31 14:37: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 940673A6B1E; Mon, 31 Aug 2009 14:37:03 -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 AAIH1sfQOQVD; Mon, 31 Aug 2009 14:37:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DB433A6EDE; Mon, 31 Aug 2009 14:37:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEWA-000H04-KM for namedroppers-data0@psg.com; Mon, 31 Aug 2009 21:34:26 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febf:cfa7] (helo=out-56.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEW6-000GzA-Ig for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 21:34:24 +0000 Received: from smtp-11.smtp.ucla.edu (smtp-11.smtp.ucla.edu [169.232.46.244]) by out-56.smtp.ucla.edu with ESMTP id n7VLXh17008588; Mon, 31 Aug 2009 14:33:47 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-11.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VLXh17008588; Mon, 31 Aug 2009 14:33:43 -0700 Received: from [172.16.0.3] (Clippers.CS.UCLA.EDU [131.179.96.72]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VLXIi9019210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2009 14:33:38 -0700 Cc: namedroppers@ops.ietf.org Message-Id: <7CD8A493-FCFA-4135-91AC-BC1800BDDF3F@CS.UCLA.EDU> From: Eric Osterweil To: Olafur Gudmundsson/DNSEXT chair In-Reply-To: <200908251744.n7PHiqmI073529@stora.ogud.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-29-715087824" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Mon, 31 Aug 2009 15:05:10 -0600 References: <200908251744.n7PHiqmI073529@stora.ogud.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.244 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-29-715087824 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Sorry for the Johnny-come-lately response: On Aug 25, 2009, at 11:44 AM, Olafur Gudmundsson/DNSEXT chair wrote: > > Dear colleagues, > > After reading all the messages on EDNS0 buffer sizes and fallback > your chairs have huddled and tried to agree on an approach to go =20 > forward > and what/if protocol work is needed. > > For the sake of argument we want to limit the discussion to > "ENDS0 capable entities" > and their behavior. The goal is to minimize fallback. > By decreasing fallback cases we speed up DNS resolution for everyone. > > We think that the current evidence suggests three main problems: > - inability or refusal to handle UDP packets larger than 600 bytes. > - inability or refusal to handle UDP fragments. > - failure to set the advertised EDNS0 buffer sizes correctly given > the actual network conditions > > Model: > A is the issuer of a DNS query > B is the target server of the query > > A <---pipe1---> INTERNET <----pipe2----> B > > If A advertises a ENDS0 buffer size that is larger than will go =20 > through > "pipe1" then B may send back an answer that is larger than fits =20 > through the > pipe. Then A will time-out and do a fallback. > > If B attempts to put an answer into "pipe2" that is larger than fits =20= > into > it A will not get an answer and will do a fallback. > > If both A and B know the "width" of their LOCAL pipes fallback > between them is rare and if B has an answer that does not fit, it will > set the TC bit. > > If the problem is actually in the INTERNET part of the diagram, > fallback is needed no matter what. We can put of evaluation of how > much of the problem is in fact in the middle, because we know for sure > right now that there are problems at the end points. Since those are > under the control of the affected parties, we can tackle this problem > first. > > The assumption here is A and B can detect the "width" of their local =20= > pipes > and either fix them or set UDP-buffersize parameters to values that =20= > their > local pipe will pass. If either A or B have multiple paths to the =20 > Internet > they should set their buffer sizes to the smallest pipe width. > In particular B should NEVER provide an answer to a normal (i.e. non =20= > ANY and > non RRSIG) query that does not pass through "Pipe2". > > Work to be done: > - Provide tools that measure local pipes and provide configuration =20= > hints We presented dnsfunnel for this at IETF 75, and I think it would be =20 great for people to download it and try it out to see this for =20 themselves: http://www.vantage-points.org/ You can point dnsfunnel at any zone and it will tell you if there is a =20= problem and what sizes fit. This has the benefit of testing the path =20= from _your_ stub to each name server in whichever zone you aim it at. Eric =E9 > > - Educate users to use the tools, where to look for problems and how > to update configurations. > - Make the firewall community aware that firewall's are causing DNS =20= > problems > and educate them in how to update their configurations, to allow well > formed UDP fragments to pass. (i.e. non overlapping fragments) > - ditto for DNS proxy vendors. > - Improve EDNS0 fallback strategies. > > Only the last one is a protocol work that DNSEXT can undertake, all =20= > the others > are external educations activities that are outside the scope of the =20= > working > group. > > As DNS is not the only UDP based protocol that is affected by the =20 > restrictions on > UDP packets, modifying DNS to work around misbehaving middle boxes =20 > is counter > productive to making the Internet better in the long run. > Adding complexity to DNS to handle the misbehaving units is a wasted =20= > effort > as the educational tasks will still have to be undertaken and =20 > provide a > quicker return on investment. > > Olafur & Andrew --Apple-Mail-29-715087824 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 v2.0.9 (Darwin) iEYEARECAAYFAkqcOwoACgkQK/tq6CJjZQJwCgCbB4qreqdwMmMeMuHPw3uIYuZt iRYAn2E7w1Io46wpEKOqWaM3ymY7aTfY =16Qp -----END PGP SIGNATURE----- --Apple-Mail-29-715087824-- From owner-namedroppers@ops.ietf.org Mon Aug 31 15:03: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 BBEC23A6B93; Mon, 31 Aug 2009 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_26=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 FVKEoScKv3kl; Mon, 31 Aug 2009 15:03:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4C6E3A6B1E; Mon, 31 Aug 2009 15:03:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEvC-000Ktj-9F for namedroppers-data0@psg.com; Mon, 31 Aug 2009 22:00: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 1MiEv8-000KtI-Dx for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 22:00:16 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 2E66CE6056; Mon, 31 Aug 2009 22:00: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 n7VM06PF017221; Tue, 1 Sep 2009 08:00:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908312200.n7VM06PF017221@drugs.dv.isc.org> To: Masataka Ohta Cc: Nicholas Weaver , George Barwood , Alex Bligh , Doug Barton , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> <200908311520.n7VFK0Ti013253@drugs.dv.isc.org> <4A9C2374.5090105@necom830.hpcl.titech.ac.jp> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Tue, 01 Sep 2009 04:24:36 +0900." <4A9C2374.5090105@necom830.hpcl.titech.ac.jp> Date: Tue, 01 Sep 2009 08:00:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A9C2374.5090105@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > >>During that time, I went through many more computers. The lifespan of > >>these stupid boxes is annoyingly long. > > > There is another technology change which is just starting to happen > > is a big way. Residential IPv6 is starting to be rolled out and > > that will involve CPE box upgrades/replacements. The same boxes > > that we want to be fixed are the ones that will be upgraded / > > replaced to support IPv6 or to continue to support IPv4 when the > > ISP moves its infrastructure to IPv6. > > Wrong. > > Instead, it is merely that any technology which requires CPE > upgrades/replacements has significant difficulty for deployment. > > > I know I am waiting for a good AP+Router with IPv6 support to replace > > the existing box. I'd like to know if DNS actually worked in it > > before buying it. > > You assume that ISPs are willing to perform: > > support IPv6 > > modify COE for A+P > > replace CPE for A+P at the same time as they modify COE > > which is a lot more difficult than just > > support IPv6 > > even which is not happening. Except it is. It's cruch time and residential ISP are now reacting. There are commisioning CPE product development, now, to allow them to support both IPv4 (NAT'd) and IPv6 into the future. > With end to end NAT, ISPs only need to > > modify COE for E2ENAT > > and they can forget IPv6 support forever. Customers may or may not > upgrade end hosts. > > With the COE modification, we can recommend source port randomization > that we don't have to support DNSSEC. > > > I don't know your mother. I do know lots of mothers followed such > > instructions in the past successfully. > > According to your theory, both IPv6 and DNSSEC should have already > been fully deployed. > > Masataka Ohta > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 15:05: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 B2C8828C52D; Mon, 31 Aug 2009 15:05:55 -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 2iikXbWy5D3h; Mon, 31 Aug 2009 15:05:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B79C328C258; Mon, 31 Aug 2009 15:05:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiExr-000LEY-AM for namedroppers-data0@psg.com; Mon, 31 Aug 2009 22:03:03 +0000 Received: from [2607:f010:3fe:102:101c:23ff:febf:cfa7] (helo=out-56.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiExn-000LE9-Rw for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 22:03:01 +0000 Received: from smtp-11.smtp.ucla.edu (smtp-11.smtp.ucla.edu [169.232.46.247]) by out-56.smtp.ucla.edu with ESMTP id n7VM2YNL030146; Mon, 31 Aug 2009 15:02:34 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-11.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VM2YNL030146 for ; Mon, 31 Aug 2009 15:02:34 -0700 Received: from [172.16.0.3] (Clippers.CS.UCLA.EDU [131.179.96.72]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n7VM2Sm8023702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Aug 2009 15:02:33 -0700 Message-Id: From: Eric Osterweil To: "namedroppers@ops.ietf.org WG" Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-718525404" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Sorry for the redundant emails Date: Mon, 31 Aug 2009 16:02:28 -0600 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.247 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-718525404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable My tunnel appears to have been flaky enough that my MUA got confused =20 and re-transmitted several emails several times. My sincere apologies for the noise. Eric =E9 --Apple-Mail-2-718525404 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 v2.0.9 (Darwin) iEYEARECAAYFAkqcSHQACgkQK/tq6CJjZQJ6kwCcDH83s1YALrQV8XICQLFAUbMC rcQAoIJTqINVA+Ze0uLtFEKq4DKWCBLu =hPUu -----END PGP SIGNATURE----- --Apple-Mail-2-718525404-- From owner-namedroppers@ops.ietf.org Mon Aug 31 15: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 0F83928C258; Mon, 31 Aug 2009 15:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=-0.264, 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 ng9tEdIeT28s; Mon, 31 Aug 2009 15:09:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E984C28C5A6; Mon, 31 Aug 2009 15:06:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiEyw-000LMT-It for namedroppers-data0@psg.com; Mon, 31 Aug 2009 22:04:10 +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 1MiEyt-000LM0-8y for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 22:04:08 +0000 Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id D1AD5A9443E; Mon, 31 Aug 2009 22:04:06 +0000 (UTC) Message-ID: <4A9C48D6.1040203@mail-abuse.org> Date: Mon, 31 Aug 2009 15:04:06 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Tony Finch CC: Alex Bligh , Nicholas Weaver , bmanning@vacation.karoshi.com, Michael Graff , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] root DNSKEY response is 1749 bytes References: <4A907B6D.1050905@gmail.com> <61661.1251006812@nsa.vix.com> <3efd34cc0908230247s3678e811q6809608ddc620746@mail.gmail.com> <4A93013E.6030806@isc.org> <20090824220451.GF17279@vacation.karoshi.com.> <0C66638E-0D60-4A8E-8480-6977B8AB73CE@icsi.berkeley.edu> <40C2A0A89CFE6F174BCCD299@Ximines.local> <4A9C1EAE.2080905@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/31/09 1:25 PM, Tony Finch wrote: > On Mon, 31 Aug 2009, Douglas Otis wrote: >> >> DNS message pipe-lining can significantly reduce response latency. However, >> for TCP, DNS message pipe-lining represents an expensive and complex mode of >> operation. Without transport level framing, TCP pipelines carrying DNS >> messages will need to buffer the entire stream subsequent to packet loss. > > It isn't really expensive or complex, at least as currently implemented. > AFAIK neither the stubs nor the recursors worry about head-of-line > blocking and it's common for recursors to process TCP requests in order. > Even so, it works well as a fallback for that proportion of requests whose > UDP responses get truncated (so the stub only needs two sockets open). DNS message handling for TCP is done by the DNS application, even when enduring the expensive head-of-line blocking. Full message handling, and options to avoid the expense caused by packet loss or errors is provided by SCTP, but not by TCP. DNS messages pipe-lined over the TCP byte-stream use a 16 bit length value prefixed to each. Over TCP, DNS messages should be considered independent of packet boundaries, and once a packet is lost, locations of message boundaries within subsequent packets becomes unknown. This is not the case with SCTP. SCTP is not a byte stream transport. Objects handled by SCTP can represent full DNS messages. To support TCP re-transmissions of lost portions of DNS messages, the entire outstanding transmitted byte stream must be retained. This is also not required for SCTP. During times of stress, such as attacks, packet-loss will place non-linearly increasing demands upon server resources. SCTP is able to avoid these run-away demands dependent upon external RTT, data rates, and packet-loss rates, which can lead to TCP services collapsing. -Doug From owner-namedroppers@ops.ietf.org Mon Aug 31 15:57: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 7554B3A69D7; Mon, 31 Aug 2009 15:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnKtBH5Drw+u; Mon, 31 Aug 2009 15:57:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 957343A68B1; Mon, 31 Aug 2009 15:57:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiFis-0002H8-JY for namedroppers-data0@psg.com; Mon, 31 Aug 2009 22:51: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 1MiFio-0002Gc-Dj for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 22:51: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 5C431E601E; Mon, 31 Aug 2009 22:51:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7VMpRtn017814; Tue, 1 Sep 2009 08:51:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908312251.n7VMpRtn017814@drugs.dv.isc.org> To: Alex Bligh Cc: George Barwood , Doug Barton , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <4595DFD253DD5280FB55E95B@Ximines.local> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Mon, 31 Aug 2009 16:48:30 +0100." <4595DFD253DD5280FB55E95B@Ximines.local> Date: Tue, 01 Sep 2009 08:51:27 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4595DFD253DD5280FB55E95B@Ximines.local>, Alex Bligh writes: > --On 1 September 2009 00:03:44 +1000 Mark Andrews wrote: > > > It it possible to work through most of these boxes. For those you > > can't you just need to point your clients at a DNS server which is > > not the box. > > With some boxes (e.g. those that drop UDP fragments even in packets > not addressed to them), this will cause fallback to TCP for responses > greater than 1500 bytes. Whether or not this is acceptable appears > to be an open question. You can still work through them. Fallback to TCP is not a open question for these boxes. Even if you read RFC 3226 as disallowing advertising EDNS@512, EDNS at sizes which prevent fragmentation is still expected and this will result in TCP occuring. The amount of TCP depends on lots of factors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 16:54: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 8E9743A6BAD; Mon, 31 Aug 2009 16:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.986 X-Spam-Level: ** X-Spam-Status: No, score=2.986 tagged_above=-999 required=5 tests=[AWL=1.147, 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 pZ6kaktgAuU3; Mon, 31 Aug 2009 16:54:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0B053A6DC9; Mon, 31 Aug 2009 16:53:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiGd9-000ACc-PS for namedroppers-data0@psg.com; Mon, 31 Aug 2009 23:49:47 +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 1MiGd5-000ABy-C5 for namedroppers@ops.ietf.org; Mon, 31 Aug 2009 23:49:45 +0000 Received: (qmail 58278 invoked from network); 31 Aug 2009 23:59:58 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 31 Aug 2009 23:59:58 -0000 Message-ID: <4A9C616C.3090408@necom830.hpcl.titech.ac.jp> Date: Tue, 01 Sep 2009 08:49:00 +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: Mark Andrews CC: Nicholas Weaver , George Barwood , Alex Bligh , Doug Barton , namedroppers@ops.ietf.org Subject: Re: [dnsext] Working around proxies References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> <200908311520.n7VFK0Ti013253@drugs.dv.isc.org> <4A9C2374.5090105@necom830.hpcl.titech.ac.jp> <200908312200.n7VM06PF017221@drugs.dv.isc.org> In-Reply-To: <200908312200.n7VM06PF017221@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark Andrews wrote: >>which is a lot more difficult than just >> >> support IPv6 >> >>even which is not happening. > Except it is. It's cruch time and residential ISP are now reacting. Well... According to some people, yes, IPv6 deployment has been happening for these 15 years. So? > There are commisioning CPE product development, now, to allow them > to support both IPv4 (NAT'd) and IPv6 into the future. It's easy to develop products. However, there is hardly any incentive for ISPs to replace all the CPEs, which costs a lot. Anyway, if we can instruct NAT vendors to follow our guideline on DNS relaying behavior, we can let them implement plain old DNS securely that there is no point to have DNSSEC, which is merely weakly secure. Masataka Ohta From owner-namedroppers@ops.ietf.org Mon Aug 31 17:20: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 8296A28C1CC; Mon, 31 Aug 2009 17:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 E7kHRbuQ7obY; Mon, 31 Aug 2009 17:20:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95D7428C18A; Mon, 31 Aug 2009 17:20:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiH1g-000Drw-BV for namedroppers-data0@psg.com; Tue, 01 Sep 2009 00:15:08 +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 1MiH1c-000DrL-B8 for namedroppers@ops.ietf.org; Tue, 01 Sep 2009 00:15:06 +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 13441E6024; Tue, 1 Sep 2009 00:15:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n810EvQM041991; Tue, 1 Sep 2009 10:14:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200909010014.n810EvQM041991@drugs.dv.isc.org> To: Masataka Ohta Cc: Nicholas Weaver , George Barwood , Alex Bligh , Doug Barton , namedroppers@ops.ietf.org From: Mark Andrews References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <1BE8B1F5-0CAB-4375-99F5-32ACF6FB9D90@icsi.berkeley.edu> <200908311520.n7VFK0Ti013253@drugs.dv.isc.org> <4A9C2374.5090105@necom830.hpcl.titech.ac.jp> <200908312200.n7VM06PF017221@drugs.dv.isc.org> <4A9C616C.3090408@necom830.hpcl.titech.ac.jp> Subject: Re: [dnsext] Working around proxies In-reply-to: Your message of "Tue, 01 Sep 2009 08:49:00 +0900." <4A9C616C.3090408@necom830.hpcl.titech.ac.jp> Date: Tue, 01 Sep 2009 10:14:57 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4A9C616C.3090408@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > >>which is a lot more difficult than just > >> > >> support IPv6 > >> > >>even which is not happening. > > > Except it is. It's cruch time and residential ISP are now reacting. > > Well... > > According to some people, yes, IPv6 deployment has been happening > for these 15 years. > > So? > > > There are commisioning CPE product development, now, to allow them > > to support both IPv4 (NAT'd) and IPv6 into the future. > > It's easy to develop products. > > However, there is hardly any incentive for ISPs to replace all > the CPEs, which costs a lot. > > Anyway, if we can instruct NAT vendors to follow our guideline > on DNS relaying behavior, we can let them implement plain old > DNS securely that there is no point to have DNSSEC, which is > merely weakly secure. > > Masataka Ohta The problem is that the boxes are not EDNS compliant or even RFC 103[45] compliant. I want a box that will do DNS/TCP. The Netgear box I have sitting next to me doesn't do that and Netgear expect me to pay them to talk to them about this. This is not a level 1 problem, you have to pay to get to level 2. The bloody hide of them. DNS/TCP is basic DNS. Nothing fancy. At least CISCO (Linksys) will talk to you. They will acknowledge faults in their products without you have to pay to do so. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 17:59: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 D95B13A68D1; Mon, 31 Aug 2009 17:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXhBNF5pWp7l; Mon, 31 Aug 2009 17:59:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4CED3A66B4; Mon, 31 Aug 2009 17:59:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiHei-000Jmp-71 for namedroppers-data0@psg.com; Tue, 01 Sep 2009 00:55:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiHed-000Jlg-0D for namedroppers@ops.ietf.org; Tue, 01 Sep 2009 00:55: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 71FAAE601C; Tue, 1 Sep 2009 00:55: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 n810tI2W047942; Tue, 1 Sep 2009 10:55:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200909010055.n810tI2W047942@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <934623C28D56444CB073F90BC35244BB05325C@TK5EX14MBXC128.redmond.corp.microsoft.com> <20090826043344.GI5405@shinkuro.com> <934623C28D56444CB073F90BC35244BB05365B@TK5EX14MBXC128.redmond.corp.microsoft.com> <934623C28D56444CB073F90BC35244BB05E980@TK5EX14MBXC121.redmond.corp.microsoft.com> <20090827180305.GK7821@shinkuro.com> <200908272358.n7RNwrvr038970@drugs.dv.isc.org> <20090828144512.GT7821@shinkuro.com> <200908282207.n7SM73bf056581@drugs.dv.isc.org> <20090831182103.GQ13987@shinkuro.com> Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC In-reply-to: Your message of "Mon, 31 Aug 2009 14:21:03 -0400." <20090831182103.GQ13987@shinkuro.com> Date: Tue, 01 Sep 2009 10:55:18 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20090831182103.GQ13987@shinkuro.com>, Andrew Sullivan writes: > On Sat, Aug 29, 2009 at 08:07:03AM +1000, Mark Andrews wrote: > > > I note that adding a new RR is even easier now: we do it with expert > > > review. Are you arguing for that route instead of RFC required? > > > > No. You were complaining about the lack of interop testing > > due to there being no code point. > > If I left that impression, I apologise. That wasn't what I was > complaining about. I was complaining that even uncontroversial code > point additions, like SHA 256, take a very long time because the > entire IETF WG consensus machinery comes into play. We need a lot of > review, there's a tendency for side issues to get explored, and so on. > > If we had a lighter weight procedure, it wouldn't be so costly and it > might therefore happen faster. SHA256 was special because we had to teach the working group that new signature algorithms need to support both NSEC and NSEC3. SHA256 should not be seen as representative of the time it will take in future. DNSEXT goes from one extreme to the other. RR allocation was a example of that. New procedures were defined and people complained that RR's take too long without even trying the new procedures. I don't think we need new procedures for DNSSEC algorithm assignments. Nobody has really demonstrated that there is a problem with the current procedure. DNSSEC is too new operationaly to have any evidence that there is a problem. Things are always slower when they are new. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 31 22:28:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC5A3A6D37; Mon, 31 Aug 2009 22:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.753 X-Spam-Level: X-Spam-Status: No, score=-6.753 tagged_above=-999 required=5 tests=[AWL=-0.625, 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 nnaH7Ce6x+D9; Mon, 31 Aug 2009 22:28:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F6F33A6F4B; Mon, 31 Aug 2009 22:28:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiLoZ-0008Lr-0k for namedroppers-data0@psg.com; Tue, 01 Sep 2009 05:21:55 +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 1MiLoS-0008Ky-OA for namedroppers@ops.ietf.org; Tue, 01 Sep 2009 05:21:51 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcAAORLnEqQ/uCKe2dsb2JhbACKDpB9HAEBFiQGpQuIQQGPVAWEGoFaiH4 X-IronPort-AV: E=Sophos;i="4.44,310,1249257600"; d="sig'?scan'208";a="48308879" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Sep 2009 05:21:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n815Lka6023150; Tue, 1 Sep 2009 07:21:46 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n815LkOR001983; Tue, 1 Sep 2009 05:21:46 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 07:21:46 +0200 Received: from 79.138.157.145.bredband.tre.se ([10.61.108.108]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 07:21:46 +0200 Cc: Alex Bligh , "Olafur Gudmundsson/DNSEXT chair" , namedroppers@ops.ietf.org Message-Id: <55C7E390-6E9B-49AD-B346-6B19935244F1@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Nicholas Weaver In-Reply-To: <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-139-744888632" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] EDNS0 fallback "revisited" Date: Tue, 1 Sep 2009 07:21:51 +0200 References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Sep 2009 05:21:46.0255 (UTC) FILETIME=[197539F0:01CA2AC4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3896; t=1251782506; x=1252646506; c=relaxed/simple; s=amsdkim1002; 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]=20EDNS0=20fallback=20=22revisi ted=22=20 |Sender:=20; bh=+Zvq5jRrxDxF/UOtBYkVZnSuweNiUepNyarWrRWhddI=; b=ckIuJ2dblUZHOuXAvcIEXFhFVbNwWi2N9CQ3dXtZwqBFzauwlLCnGSvIM+ I/BIiCf86bMU3q+MtdNU18Vt3gqwSxn1rx2wjdigxz3GiQz1SVXbDC80wAvf byl0m5DFou; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-139-744888632 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 25 aug 2009, at 21.31, Nicholas Weaver wrote: > Fragmentation is NOT a problem for ~85% +/- some delta of > resolvers. Which means, for MOST resolvers, its OK if the response > fragments. So let the responses be large, we have these large > DNSSEC responses anyway, so go for it. > > > But fragmentation IS a problem for ~15%. It is a bit more complicated than this. It might be ok with fragmentation, as long as the fragments arrive in order. This implies it even might work _sometimes_. > This is probably too large a number for education strategies to > work, since that requires upgrading/replacing existing middleboxes. Well, the 85% number is high enough so that we can say "this is how it should be"...but in general I agree with you. > And too large a number for any strategy which requires timeouts per > authority before deciding its a problem, which will kill performance > and cause "DNSSEC is broken" complaints once .com starts signing data. The question is who the complaint is going to. Some DNSSEC problems will target the large ISPs that run the large resolvers. They will detect people with broken signed zones -- but they will most certainly _not_ have the fragmentation issues (or they have serious problems anyway). The complaints on fragmentation will hit the smaller resolvers that sit behind firewalls that do the wrong thing. I presume here people have correct firewalls in front of authoritative servers with signed zones -- because here I also think we have other problems if people have that broken stuff. I am optimistic here. If something causes a delay (the time for a fallback to TCP), then people will start to investigate why that happens. In a way similar to the IPv6 deployment issue. Why do we get a timeout? Aha, the IPv6 routing was broken, and we have to fall back to IPv4. > Especially since the .org TCP load is probably representative: > significant but should be tolerable. > Resolvers behind broken middleboxes will today do the fallback to > TCP eventually when querying .org for a large response, they are > just going through an annoying, performance-killing timeout first. ...and then fix their middlebox...or send correct EDNS0 bufsize...or... > And as for the rest of the Internet protocols, I think its probably > safe to say everyone else has given up on UDP fragments working > always on the Internet, judging by the workarounds for IKE. Thus I > don't see the particular problem in the DNS protocol saying "We MUST > NOT rely on UDP fragmentation working in all cases, but MAY rely on > fragmentation working in most cases" > > Therefore, I believe the objective should be "Make sure that DNSSEC > works on an Internet that MOSTLY is OK with UDP fragments, but > understands that some resolvers can't handle fragments, and some > authorities can't handle fragments", without ANY protocol changes > and single-sided changes to just resolvers. Which appears quite > doable. Maybe tune this a bit. It might not be the resolver or authorities that can not handle fragments. It might be something in between. Otherwise I am with this. Patrik --Apple-Mail-139-744888632 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) iD8DBQFKnK9vvHlR2X0luNwRAvWjAJsGO1FuVf1Pxidds+QBCSfjE0WwOQCg7Uxz OWUBeYpj+eyb3BbpGYaBxB8= =bQwB -----END PGP SIGNATURE----- --Apple-Mail-139-744888632-- From owner-namedroppers@ops.ietf.org Mon Aug 31 23:01: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 73A983A6F41; Mon, 31 Aug 2009 23:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=0.073, 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 JN6LRPaocr5V; Mon, 31 Aug 2009 23:01:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FCA03A6F5E; Mon, 31 Aug 2009 23:01:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiML3-000D9V-OL for namedroppers-data0@psg.com; Tue, 01 Sep 2009 05:55:29 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiMKv-000D2t-Vi for namedroppers@ops.ietf.org; Tue, 01 Sep 2009 05:55:27 +0000 Received: from [192.168.100.85] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 3F166C2DA3; Tue, 1 Sep 2009 06:55:11 +0100 (BST) Date: Tue, 01 Sep 2009 06:55:13 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews cc: George Barwood , Doug Barton , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Working around proxies Message-ID: In-Reply-To: <200908312251.n7VMpRtn017814@drugs.dv.isc.org> References: <4CB0582F89044745BF1D1EBF09E549B6@localhost> <4A998A15.6050602@dougbarton.us> <4A9AC3CF.4000106@dougbarton.us> <200908310153.n7V1rUhR088199@drugs.dv.isc.org> <1009805BA49B4D22BAD2E408B06FA87B@localhost> <200908311222.n7VCMX8j000197@drugs.dv.isc.org> <339C5564ABB948BAB7F9591DF3325140@localhost> <200908311403.n7VE3iNe004282@drugs.dv.isc.org> <4595DFD253DD5280FB55E95B@Ximines.local> <200908312251.n7VMpRtn017814@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 September 2009 08:51:27 +1000 Mark Andrews wrote: > You can still work through them. > > Fallback to TCP is not a open question for these boxes. Even if > you read RFC 3226 as disallowing advertising EDNS@512, EDNS at sizes > which prevent fragmentation is still expected and this will result > in TCP occuring. The amount of TCP depends on lots of factors. For clarity, the situation I meant was as follows: 1. Client advertises EDNS0@4096 which it is perfectly capable of handling 2. Client addresses DNS query directly to server (outside middlebox) 3. Middlebox passes query untouched (except perhaps normal NAT stuff) 4. Response is UDP, and >1500 bytes, so fragmented 5. Middlebox passes first packet only, and drops UDP fragments 6. Client never receives all fragments to reassemble Now you might say "well the client should be advertising EDNS0@1500 or whatever" but won't work (even if it is on the fallback path) where the response is >1500 bytes (and can't be trimmed of extraneous stuff so as to fit). Ignoring for a moment EDNS page option type innovations, that one would have to go via TCP as far as I can see. -- Alex Bligh