From owner-namedroppers@ops.ietf.org Sun Mar 2 11:11:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EC13A6AB8; Sun, 2 Mar 2008 11:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.863 X-Spam-Level: X-Spam-Status: No, score=-4.863 tagged_above=-999 required=5 tests=[AWL=-0.368, 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 QoDG9RlLq3S4; Sun, 2 Mar 2008 11:10:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA31C3A6AA0; Sun, 2 Mar 2008 11:10:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVtQU-000PFu-7S for namedroppers-data@psg.com; Sun, 02 Mar 2008 19:00:46 +0000 Received: from [216.82.250.131] (helo=mail128.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVtQQ-000PEt-PK for namedroppers@ops.ietf.org; Sun, 02 Mar 2008 19:00:44 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1204484434!11162986!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26269 invoked from network); 2 Mar 2008 19:00:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 2 Mar 2008 19:00:34 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m22J0VqA005053 for ; Sun, 2 Mar 2008 12:00:34 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m22J0VGv017255 for ; Sun, 2 Mar 2008 13:00:31 -0600 (CST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m22J0UcH017248 for ; Sun, 2 Mar 2008 13:00:30 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: dns-0x20.txt Date: Sun, 2 Mar 2008 14:00:22 -0500 Message-ID: <3870C46029D1F945B1472F170D2D97900391DE97@de01exm64.ds.mot.com> In-Reply-To: <47C67A17.4000407@nlnetlabs.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns-0x20.txt Thread-Index: Ach56YwRL/T6QSRYTN6vTJv7DoGxhQCm5c1A References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.com> <47C67A17.4000407@nlnetlabs.nl> From: "Eastlake III Donald-LDE008" To: "Wouter Wijngaards" Cc: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Hi Wouter,=20 > -----Original Message----- > From: Wouter Wijngaards [mailto:wouter@nlnetlabs.nl]=20 > Sent: Thursday, February 28, 2008 4:09 AM > To: Eastlake III Donald-LDE008 > Cc: Michael Graff; namedroppers@ops.ietf.org > Subject: Re: dns-0x20.txt >=20 > Eastlake III Donald-LDE008 wrote: > | Hi, > | > | On using an EDNS0 option, please see my draft at > |=20 > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt > | . > | For simplicity is proposes a fixed size but it would be=20 > trivial to make > | it variable. >=20 > I like the idea of using an EDNS0 option to contain random data. > Perhaps without a complicated hashing scheme (as you have),=20 > but simpler > (once you know the server speaks that option; you are guarded by the > server copying the option back to you; of course the=20 > occasional timeout > or reboot presents small windows of downgrade attack. State could be > stored on disk though.). Anyway, your proposal is nice. Thanks. Actually, it depends on what attacks you are considering. As hashing schemes go, what I suggest is pretty trivial and if the computation load were too heavy, you could go to some even simpler and weaker hash function, like maybe MD4. (It recommends HMAC-SHA1 because I think anything weaker as the default recommendation would run into a lot of flak from people in the Security Area. But I don't really think, for this application, it needs to be that strong.) Anyway, as I say, a brief window where you can sneak by the protection isn't a downgrade attack. A downgrade attack is an attack which, if it succeeds, puts the participants in a sustained degraded mode of operation, such as an attack which persuades them to use a weaker key or weaker algorithm such that the protection is weakened permanently, or at least until the next reset. > Also the dns-0x20 draft breaks binary labels. Badly. > Binary data is garbled by the process. If this is deployed, binary > labels are no longer an option later on (as some upstream=20 > full resolver > may break the uppercase bit in the binary data). >=20 > DNSSEC, as it gets deployed, makes spoof protection=20 > mechanisms obsolete. > And DNSSEC is already deployed on some TLDs. Configuring keys=20 > is a much > more reliable way to prevent spoofing for them. TSIG is a complete and superior replacement for DNS Cookies but I assume your are talking about the data origin authentication (and maybe authenticated denial of existence) aspects of DNSSEC. Those aspects of DNSSEC don't help denial of service attacks on servers. In fact, DNSSEC makes those attacks worse, at least for a recursive server, because of the computational load of the cryptographic operations it may have to perform in trying to produce an answer. And those aspects of DNSSEC don't help amplification attacks. In fact, DNSSEC makes those attacks via DNS servers worse because the signatures over the RRs in the result make the answer bigger. I think you would want DNS Cookies even if you had 100% deployment of DNSSEC. In fact, I think universal deployment of DNSSEC would make DNS Cookies more desirable, not less. > Best regards, > ~ Wouter Thanks, Donald -- to unsubscribe send a message to namedroppers-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 Mar 2 17:50:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549793A6E29; Sun, 2 Mar 2008 17:50:43 -0800 (PST) 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 tN9kFTqHQMB5; Sun, 2 Mar 2008 17:50:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F8853A6CFB; Sun, 2 Mar 2008 17:50:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVzdl-0007n6-E8 for namedroppers-data@psg.com; Mon, 03 Mar 2008 01:38:53 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVzdi-0007mU-Fx for namedroppers@ops.ietf.org; Mon, 03 Mar 2008 01:38:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 015B91146C; Mon, 3 Mar 2008 01:38:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org cc: dagon@cc.gatech.edu Subject: dns-0x20 section 5.4 X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Mar 2008 01:38:44 +0000 Message-ID: <82869.1204508324@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion thanks very much to wouters@nlnetlabs for this important observation+technique: Index: dns-0x20.ms =================================================================== RCS file: /udir/vixie/src/cvsroot/i-d/Working/dns-0x20.ms,v retrieving revision 1.2 diff -u -r1.2 dns-0x20.ms --- dns-0x20.ms 3 Mar 2008 01:21:30 -0000 1.2 +++ dns-0x20.ms 3 Mar 2008 01:26:16 -0000 @@ -191,6 +191,14 @@ their operations log when a mismatch in the 0x20 bits occurs, to help measure global cache poisoning attempts, and to diagnose problems which may be due to DNS middleboxes. +.LP +5.4. Requestors should take care to remember the original question name, so +that following successful verification of the 0x20-randomized question name, +the original can be copied into the response message before the other sections +are uncompressed. This is because compression pointers in the answer, +authority, and additional section often point back to the question section, +with the ugly result of copying the 0x20-randomized bits into the cache, and +into subsequent responses which include data from the cache. .\" ------------------------------- .Sh "5 - Implementation and Measurement" .LP i noted from the above diff that i had two section 5's. further investigation revealed a lack of a section 10. i renumbered the second 5, and 6..9, by +1. that URL again is . -- to unsubscribe send a message to namedroppers-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 Mar 2 19:21:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEA33A680D; Sun, 2 Mar 2008 19:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.804 X-Spam-Level: X-Spam-Status: No, score=-99.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 j2osiAovYCAX; Sun, 2 Mar 2008 19:21:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84B273A69C3; Sun, 2 Mar 2008 19:21:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JW17X-000ILj-6y for namedroppers-data@psg.com; Mon, 03 Mar 2008 03:13:43 +0000 Received: from [202.224.39.218] (helo=mails2.asahi-net.or.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JW17U-000ILR-4c for namedroppers@ops.ietf.org; Mon, 03 Mar 2008 03:13:41 +0000 Received: from mailav2.asahi-net.or.jp (mailav2.asahi-net.or.jp [202.224.39.221]) by mails2f.asahi-net.or.jp (Postfix) with SMTP id 9EB94C60E for ; Mon, 3 Mar 2008 12:13:39 +0900 (JST) Received: from mails1.asahi-net.or.jp ([202.224.39.217]) by mailav2.asahi-net.or.jp (NAVGW 2.5.2.9) with SMTP id M2008030312133904337 for ; Mon, 03 Mar 2008 12:13:39 +0900 Received: from reseaux.priv.k2r.org (s163221.ppp.asahi-net.or.jp [220.157.163.221]) by mails1.asahi-net.or.jp (Postfix) with ESMTP id DB0E3C609 for ; Mon, 3 Mar 2008 12:13:37 +0900 (JST) Received: (qmail 68795 invoked by uid 1000); 3 Mar 2008 03:13:37 -0000 Date: Mon, 3 Mar 2008 12:13:37 +0900 From: Kenji Rikitake To: namedroppers@ops.ietf.org Subject: Re: edns0-bis submitted Message-ID: <20080303031337.GA68521@k2r.org> References: <30604.1204133581@sa.vix.com> <200802272321.m1RNLj3L033154@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802272321.m1RNLj3L033154@drugs.dv.isc.org> User-Agent: Mutt/1.5.14 (2007-02-12) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion In the message <200802272321.m1RNLj3L033154@drugs.dv.isc.org> dated Thu, Feb 28, 2008 at 10:21:22AM +1100, Mark Andrews writes: > The only transitions allowed for packet loss should be. > > EDNS -> EDNS @512 (for broken firewalls) > > If a firewall is not going to allow EDNS though then it should be > responding to the query with FORMERR. Just curious: Mark, what do you think about the following case? * a resolver send a UDP request to a server for a large RR with EDNS * the server responds with the answer in a large UDP datagram which fragments into two or more pieces of IP packets * unfortunately the resolver is behind a middlebox (firewall, router, whatever) and could not get the answer due to the blockage of the DF-bit-set IP packets In this case, I think falling back to EDNS @IP-MTU-aware-value (presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though the state management will get more complicated because it's adding another state between EDNS and "EDNS @512". I'd like to see the pros and cons. I also feel, however, to accept the conservative approach of > I'm tempted to say don't do any fallbacks on packet loss and > just treat "packet loss" as "packet loss". because assuming the reason of a packet loss without a proof often backfires (e.g., a "real" packet loss may change the maximum-length-limit state of EDNS). Kenji Rikitake -- to unsubscribe send a message to namedroppers-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 Mar 2 19:50:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FC23A6A7D; Sun, 2 Mar 2008 19:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNHkvd7MIXQ9; Sun, 2 Mar 2008 19:50:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1682B3A6B5F; Sun, 2 Mar 2008 19:50:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JW1cB-000Lab-M4 for namedroppers-data@psg.com; Mon, 03 Mar 2008 03:45:23 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JW1c8-000LaL-I1 for namedroppers@ops.ietf.org; Mon, 03 Mar 2008 03:45:22 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m233jE6A084554; Mon, 3 Mar 2008 14:45:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803030345.m233jE6A084554@drugs.dv.isc.org> To: Kenji Rikitake Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: edns0-bis submitted In-reply-to: Your message of "Mon, 03 Mar 2008 12:13:37 +0900." <20080303031337.GA68521@k2r.org> Date: Mon, 03 Mar 2008 14:45:14 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > In the message <200802272321.m1RNLj3L033154@drugs.dv.isc.org> > dated Thu, Feb 28, 2008 at 10:21:22AM +1100, > Mark Andrews writes: > > The only transitions allowed for packet loss should be. > > > > EDNS -> EDNS @512 (for broken firewalls) > > > > If a firewall is not going to allow EDNS though then it should be > > responding to the query with FORMERR. > > Just curious: Mark, what do you think about the following case? > > * a resolver send a UDP request to a server for a large RR with EDNS > > * the server responds with the answer in a large UDP datagram which > fragments into two or more pieces of IP packets > > * unfortunately the resolver is behind a middlebox (firewall, router, > whatever) and could not get the answer due to the blockage of the > DF-bit-set IP packets Any nameserver that sets DF for IPv4 UDP resonses is broken. For IPv6 network MTU fragmentation should be being performed. > In this case, I think falling back to EDNS @IP-MTU-aware-value > (presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though > the state management will get more complicated because it's adding > another state between EDNS and "EDNS @512". > > I'd like to see the pros and cons. It's not worth trying to detect. I actually sit behind a NAT which can't handle out of order fragments. I just configure the nameserver to advertise a EDNS UDP size of 1460. > I also feel, however, to accept the conservative approach of > > > I'm tempted to say don't do any fallbacks on packet loss and > > just treat "packet loss" as "packet loss". > > because assuming the reason of a packet loss without a proof often > backfires (e.g., a "real" packet loss may change the > maximum-length-limit state of EDNS). > > Kenji Rikitake > > -- > to 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: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 3 12:40:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA29B3A6ADD; Mon, 3 Mar 2008 12:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.276, 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 XjujRhXpzPjj; Mon, 3 Mar 2008 12:40:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62E573A6940; Mon, 3 Mar 2008 12:40:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWHFM-000C0X-RU for namedroppers-data@psg.com; Mon, 03 Mar 2008 20:26:52 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWHFK-000C03-1H for namedroppers@ops.ietf.org; Mon, 03 Mar 2008 20:26:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8C7C411432 for ; Mon, 3 Mar 2008 20:26:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: implications of RFC 2181 on cname chains X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Mar 2008 20:26:44 +0000 Message-ID: <56066.1204576004@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion in a private discussion with jinmei, he showed me this text from RFC 2181: > Note that the answer section of an authoritative answer normally > contains only authoritative data. However when the name sought is an > alias (see section 10.1.1) only the record describing that alias is > necessarily authoritative. Clients should assume that other records > may have come from the server's cache. Where authoritative answers > are required, the client should query again, using the canonical name > associated with the alias. i've struggled with this concept, since i had always restricted this treatment to "out of zone" cnames. in other words when i receive... www.example.com. cname xxx.example.com. xxx.example.com. aaaa dead::beef ...i had been treating both names as authoritative, since both are children of the apex i was querying under. i've realized that xxx.example.com might be an NS RR for which the example.com authority servers happen to have an AAAA RR cached (or might have it as glue in the example.com zone). so, i have altered my own caching server to ignore the second name in the above example, and to re-fetch from the end of my cached cname chain, so that i have to build my cached cname chain one query at a time, no matter what the authority server says. i recommend that authority servers stop sending back full cname chains. i don't think this implication was obvious during the production of RFC 2181. only the name matching the qname can be seen as authoritative. everything else is just fluff. cname chains are nec'y for RD=1 RA=1, otherwise useless. -- to unsubscribe send a message to namedroppers-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 Mar 3 13:55:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F8F3A6E4B; Mon, 3 Mar 2008 13:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.295, 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 lCZ36laqUUw4; Mon, 3 Mar 2008 13:55:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 570363A6935; Mon, 3 Mar 2008 13:55:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWIXM-000Lgg-4d for namedroppers-data@psg.com; Mon, 03 Mar 2008 21:49:32 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWIXI-000Lg4-Aq for namedroppers@ops.ietf.org; Mon, 03 Mar 2008 21:49:30 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m23LnLKH075282; Tue, 4 Mar 2008 08:49:21 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803032149.m23LnLKH075282@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: implications of RFC 2181 on cname chains In-reply-to: Your message of "Mon, 03 Mar 2008 20:26:44 -0000." <56066.1204576004@sa.vix.com> Date: Tue, 04 Mar 2008 08:49:21 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > in a private discussion with jinmei, he showed me this text from RFC 2181: > > > Note that the answer section of an authoritative answer normally > > contains only authoritative data. However when the name sought is an > > alias (see section 10.1.1) only the record describing that alias is > > necessarily authoritative. Clients should assume that other records > > may have come from the server's cache. Where authoritative answers > > are required, the client should query again, using the canonical name > > associated with the alias. > > i've struggled with this concept, since i had always restricted this > treatment to "out of zone" cnames. in other words when i receive... > > www.example.com. cname xxx.example.com. > xxx.example.com. aaaa dead::beef > > ...i had been treating both names as authoritative, since both are children o > f > the apex i was querying under. i've realized that xxx.example.com might be a > n > NS RR for which the example.com authority servers happen to have an AAAA RR > cached (or might have it as glue in the example.com zone). so, i have altere > d > my own caching server to ignore the second name in the above example, and to > re-fetch from the end of my cached cname chain, so that i have to build my > cached cname chain one query at a time, no matter what the authority server > says. > > i recommend that authority servers stop sending back full cname chains. i > don't think this implication was obvious during the production of RFC 2181. > only the name matching the qname can be seen as authoritative. everything > else is just fluff. cname chains are nec'y for RD=1 RA=1, otherwise useless. It's 1034 that you are chasing and with DNSSEC it doesn't matter as you should end up being able to cryptographically verify the entire CNAME chain regardless of its source. > -- > to 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: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 3 16:17:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4A33A67B2; Mon, 3 Mar 2008 16:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=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 W3MdMRslQQKG; Mon, 3 Mar 2008 16:17:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AF263A6785; Mon, 3 Mar 2008 16:17:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWKew-000FvK-7V for namedroppers-data@psg.com; Tue, 04 Mar 2008 00:05:30 +0000 Received: from [216.168.239.75] (helo=osprey.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWKes-000Fua-Mu for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 00:05:28 +0000 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id m23NtFW3017553; Mon, 3 Mar 2008 18:55:15 -0500 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 19:05:22 -0500 Received: from [10.131.30.86] ([10.131.30.86]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 19:05:21 -0500 Cc: namedroppers@ops.ietf.org Message-Id: <9B42DCB2-978F-473A-9193-965E635FE32E@verisign.com> From: David Blacka To: Paul Vixie In-Reply-To: <56066.1204576004@sa.vix.com> Content-Type: multipart/signed; boundary=Apple-Mail-8-796138870; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: implications of RFC 2181 on cname chains Date: Mon, 3 Mar 2008 19:05:21 -0500 References: <56066.1204576004@sa.vix.com> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 04 Mar 2008 00:05:21.0899 (UTC) FILETIME=[705AE3B0:01C87D8B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Apple-Mail-8-796138870 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 3, 2008, at 3:26 PM, Paul Vixie wrote: > in a private discussion with jinmei, he showed me this text from RFC > 2181: > >> Note that the answer section of an authoritative answer normally >> contains only authoritative data. However when the name sought >> is an >> alias (see section 10.1.1) only the record describing that alias is >> necessarily authoritative. Clients should assume that other >> records >> may have come from the server's cache. Where authoritative answers >> are required, the client should query again, using the canonical >> name >> associated with the alias. > > i've struggled with this concept, since i had always restricted this > treatment to "out of zone" cnames. in other words when i receive... > > www.example.com. cname xxx.example.com. > xxx.example.com. aaaa dead::beef > > ...i had been treating both names as authoritative, since both are > children of > the apex i was querying under. i've realized that xxx.example.com > might be an > NS RR for which the example.com authority servers happen to have an > AAAA RR > cached (or might have it as glue in the example.com zone). so, i > have altered > my own caching server to ignore the second name in the above > example, and to > re-fetch from the end of my cached cname chain, so that i have to > build my > cached cname chain one query at a time, no matter what the authority > server > says. > > i recommend that authority servers stop sending back full cname > chains. i > don't think this implication was obvious during the production of > RFC 2181. > only the name matching the qname can be seen as authoritative. > everything > else is just fluff. cname chains are nec'y for RD=1 RA=1, otherwise > useless. I was actually thinking about writing a draft about this, but figured that it was either too tall a hill to climb or not actually solving a real problem (or both). I was thinking that authoritative servers should still be allowed to chase CNAMEs within zone, but your point suggests otherwise, which I find interesting. My thinking was that, since modern resolvers should certainly the rest of the CNAME chain when it goes out of zone, then authoritative servers should not waste their time. Your point is stronger. -- David Blacka Sr. Engineer VeriSign Infrastructure Product Engineering --Apple-Mail-8-796138870 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILiDCCA6Yw ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb if1JwnUEA5el1JaB2CNB8DCCBBYwggN/oAMCAQICEH/ky2MD0Ks+tybXzdJAD/EwDQYJKoZIhvcN AQEFBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt cGxveWVlIENBMB4XDTA4MDMwMzAwMDAwMFoXDTA5MDMwMzIzNTk1OVowajERMA8GA1UEChMIVkVS SVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRh dmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALf4yQLwzdrWeSe8hErx/kvENPF+K5/iHQcWFp4QZuGga+UeifgP6YNZdgTvzPmO4eZV ZADPq7tuQwvwsXtbSxqLjw7b8xpzyFDlG1LxrLdLDCUcEnWGtazaDaThrN/2VS72bfN6COSRB+Gj YjGO2CKeZ3OoaCnIUCoYistgQJabAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAw TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VF bXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJ bmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4g KGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjANBgkqhkiG9w0BAQUFAAOBgQAmUg2DmlM+ixRWjnMTDWoPPaSa9S0cA8/n1cnjv7FS 4IMZqIdAcgWi/sTCoarffoH6FsXLmScTGTTWaCPZDL+ydxeQp25IW4kkOS3mNQrqnmZZYGVofvqg Ea9Yrn3aOm5X/2baHHR5d+vMdFGvZYh4vVwatnufLTU0oo6xRvwb8TGCA3UwggNxAgEBMIHBMIGs MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBD QQIQf+TLYwPQqz63JtfN0kAP8TAJBgUrDgMCGgUAoIICCTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODAzMDQwMDA1MjJaMCMGCSqGSIb3DQEJBDEWBBTyGeFConmB Jmpo2Pl3JsUzKsN6UTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQf+TLYwPQqz63JtfN0kAP8TCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJt cyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJp U2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB/5MtjA9CrPrcm183SQA/xMA0GCSqGSIb3DQEBAQUA BIGAU3ZzkDVTInmCaT5JA3zoyOshps5cTs/460GFygHOjwPrNP64aqzmcwWWNOWSZfo5MV+ON0TY w77G0OIt1AN3DAshwOuxy+mpHAe+hluRHnI3RWLZCLdHxjfcSQag0rm6sr6e/kj5iKb9sCCLUxuW dGhpobEUdCziRmFtJMe5OAcAAAAAAAA= --Apple-Mail-8-796138870-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From kc3z@att.com Mon Mar 3 18:35:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB9528C309 for ; Mon, 3 Mar 2008 18:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.004 X-Spam-Level: X-Spam-Status: No, score=-30.004 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, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, LOW_PRICE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_AB_SURBL=10, 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 ibQGK3Vjy50M for ; Mon, 3 Mar 2008 18:35:17 -0800 (PST) Received: from cpe-66-65-165-103.nyc.res.rr.com (cpe-66-65-165-103.nyc.res.rr.com [66.65.165.103]) by core3.amsl.com (Postfix) with ESMTP id 930F928C42E for ; Mon, 3 Mar 2008 18:34:49 -0800 (PST) Message-ID: <000701c87da0$044889d6$021b8bb0@gkfbem> From: "dell kirsten" To: "Marietta Todd" Subject: exclusive watches, brand name quality rolex Date: Tue, 04 Mar 2008 00:47:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Discover Our Range of Luxury Rolex Watches for Men and Women... Incredibly Low Prices! http://busksalmahoxy.com/ From owner-namedroppers@ops.ietf.org Mon Mar 3 20:29:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F413A69A2; Mon, 3 Mar 2008 20:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.263, 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 PajowLqe4x4I; Mon, 3 Mar 2008 20:29:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 317DE3A696B; Mon, 3 Mar 2008 20:29:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWOeo-0000Hn-Vt for namedroppers-data@psg.com; Tue, 04 Mar 2008 04:21:38 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWOel-0000HH-10 for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 04:21:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7FE9A11433; Tue, 4 Mar 2008 04:21:29 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: implications of RFC 2181 on cname chains In-Reply-To: Your message of "Mon, 03 Mar 2008 19:05:21 EST." <9B42DCB2-978F-473A-9193-965E635FE32E@verisign.com> References: <56066.1204576004@sa.vix.com> <9B42DCB2-978F-473A-9193-965E635FE32E@verisign.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 04 Mar 2008 04:21:29 +0000 Message-ID: <74791.1204604489@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > ... > > i recommend that authority servers stop sending back full cname chains. i > > don't think this implication was obvious during the production of RFC > > 2181. only the name matching the qname can be seen as authoritative. > > everything else is just fluff. cname chains are nec'y for RD=1 RA=1, > > otherwise useless. > > I was actually thinking about writing a draft about this, but figured that > it was either too tall a hill to climb or not actually solving a real > problem (or both). i've realized that the point in 1034 and 2181 is so subtle that a separate i-d is required. perhaps you would do me the honour of co-authoring it? > I was thinking that authoritative servers should still be allowed to chase > CNAMEs within zone, but your point suggests otherwise, which I find > interesting. i can't escape the feeling that in-zone cnames ought to be chainable in a single response, nor the feeling that they really, in fact, cannot be. in any case any RD=0 initiator has to be prepared to detect and finish incomplete cname chains, whether due to out-of-zone, or ttl-expired-middle-member, and so this change adds no new logic, except the part where they have to ignore all answer records whose owner != qname, even if it otherwise looks like a complete in-zone chain. the recommendation that servers stop sending this swill is minor in comparison to what the initiator has to stop believing. > My thinking was that, since modern resolvers should certainly ... the rest > of the CNAME chain when it goes out of zone, then authoritative servers > should not waste their time. Your point is stronger. but as you say, authoritative servers really shouldn't waste their time, but if they do, then RD=0 initiators really shouldn't believe what they say. (RD=1 initiators, so-called "stubs", are a different story, they should believe what they hear from RA=1 responders, including cname chains.) if this draft gets writ, then it would be a fine time to announce, once and for all, that if RD=1, there is no need for an authority section, with or without an RFC2308 SOA proof, and that the additional section should only pertain to the answer section, not the (ought to be empty) authority section. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 3 21:12:23 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA4F28C2DC; Mon, 3 Mar 2008 21:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 mYXPUhGVpLoy; Mon, 3 Mar 2008 21:12:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7194928C2E6; Mon, 3 Mar 2008 21:12:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWPNW-0005nY-2R for namedroppers-data@psg.com; Tue, 04 Mar 2008 05:07:50 +0000 Received: from [2001:980:fff:31::a] (helo=mx.spodhuis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWPNS-0005n5-Uo for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 05:07:48 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=d200803; d=spodhuis.org; h=Received:Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=xE7hj3MBnhhhHz1uXuMrUMLVXXzmkyHuVnxDQLEQcN6SD2rxlmK9HQpmU7hu4NIP6En2wzDrWTEw7XbVSPSlqK2/1gjKmoP56mbPxaoIxy9oji6zLi8euU+7fwqPKGAWOYN2YAxvejAYhOFBaPGB/pIxOwYm/95Mixi230/wUxo=; Received: by smtp.spodhuis.org with local id 1JWPNQ-0007pr-4g; Tue, 04 Mar 2008 05:07:44 +0000 Date: Mon, 3 Mar 2008 21:07:44 -0800 From: Phil Pennock To: Paul Vixie Cc: David Blacka , namedroppers@ops.ietf.org Subject: Re: implications of RFC 2181 on cname chains Message-ID: <20080304050743.GA29985@redoubt.spodhuis.org> Mail-Followup-To: Paul Vixie , David Blacka , namedroppers@ops.ietf.org References: <56066.1204576004@sa.vix.com> <9B42DCB2-978F-473A-9193-965E635FE32E@verisign.com> <74791.1204604489@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74791.1204604489@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 2008-03-04 at 04:21 +0000, Paul Vixie wrote: > i can't escape the feeling that in-zone cnames ought to be chainable in a > single response, nor the feeling that they really, in fact, cannot be. This seems reasonable to me, so please shoot holes in it: If the responder orders the additional records so that authoritative responses come before non-authoritative responses, then an EDNS0 option AUTHADDITIONAL could provide an integer N in the range 0 to number_of_additional_responses (inclusive) with the interpretation that it is authoritative for the first N additional responses, not counting the OPT pseudo-RR. Clients that don't understand the extension treat all additional responses identically (and hopefully non-authoritative). Clients that _might_ understand the extension will have issued an EDNS0 query suggesting that it will correctly ignore unknown extended options. (Worst case, a new extended flag requesting an authadditional response). Clients that do understand the extension gain the ability to reduce the number of round-trips to safely chase CNAME chains, providing a performance benefit to enabling EDNS0 where the server supports this. Clients that understand the extension talking to a server which doesn't support the extension won't get the new option response so won't see the immediate benefit, but no harm done. No additional octets required for query packets. Adds six octets to response packets where this is used. Since it's an EDNS0 response, there should typically be a larger buffer to play with in the first place. Assumption is that 16 bits will be sufficient to count the number of additional records for which the server is authoritative. The deployment path looks clean, the benefits look obvious, the cost is minimal (given the additional packet-size available with EDNS0) and it helps push EDNS0 to on-by-default in clients. Two birds, one stone? Now someone will point out what I'm missing and I'll be duly embarrassed. -Phil -- to unsubscribe send a message to namedroppers-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 Mar 4 00:40:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC54E3A6EB7; Tue, 4 Mar 2008 00:40:36 -0800 (PST) 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 fOlGbM1Dc3+u; Tue, 4 Mar 2008 00:40:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50F553A6EB5; Tue, 4 Mar 2008 00:40:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWSZX-0005pU-Az for namedroppers-data@psg.com; Tue, 04 Mar 2008 08:32:27 +0000 Received: from [2001:7b8:206:1::68] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWSZN-0005mA-6i for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 08:32:23 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [213.154.224.58]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m248W7hv009908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:32:08 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47CD0907.3010405@nlnetlabs.nl> Date: Tue, 04 Mar 2008 09:32:07 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Paul Vixie CC: David Blacka , namedroppers@ops.ietf.org Subject: Re: implications of RFC 2181 on cname chains References: <56066.1204576004@sa.vix.com> <9B42DCB2-978F-473A-9193-965E635FE32E@verisign.com> <74791.1204604489@sa.vix.com> In-Reply-To: <74791.1204604489@sa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Tue, 04 Mar 2008 09:32:08 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: |>> ... |>> i recommend that authority servers stop sending back full cname chains. i |>> don't think this implication was obvious during the production of RFC |>> 2181. only the name matching the qname can be seen as authoritative. |>> everything else is just fluff. cname chains are nec'y for RD=1 RA=1, |>> otherwise useless. | i've realized that the point in 1034 and 2181 is so subtle that a separate | i-d is required. perhaps you would do me the honour of co-authoring it? |> I was thinking that authoritative servers should still be allowed to chase |> CNAMEs within zone, but your point suggests otherwise, which I find |> interesting. Hi, I think that (as it says in RFC2181) the remainder of the CNAME chain is still useful, but simply receives a lower trust rank order. RFC2181 does not say that the remainder of the CNAME chains has to be discarded. You receive a reply with AA bit set from the authority server, and thus classify the RRsets in the answer section as ~ + The authoritative data included in the answer section of an ~ authoritative reply. But the data after the CNAME has to be classified as ~ + Data from the answer section of a non-authoritative answer, and ~ non-authoritative data from the answer section of authoritative ~ answers, Which is a lower trust rank. This means that the queryer has to lower its belief in the remainder of the CNAME chain. And a-query-per-CNAME is not required (unless the queryer wants to have all of the CNAME chain with the same trust rank). If you decide to produce text about this, please consider this point to soften the hard-line 'one query per CNAME'-solution. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHzQkHkDLqNwOhpPgRAiuCAJ9fnUyIlwEeDGErcKbc2SLNCq05VQCdEo74 fVFobnKoJWqKXHYS8D270iU= =xCu9 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 4 01:29:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD883A6BCB; Tue, 4 Mar 2008 01:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr3Eg+X+wKkD; Tue, 4 Mar 2008 01:29:43 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C79B33A6B54; Tue, 4 Mar 2008 01:29:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWTNH-000DLf-Ka for namedroppers-data@psg.com; Tue, 04 Mar 2008 09:23:51 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWTNF-000DLE-0c for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 09:23:50 +0000 X-IronPort-AV: E=Sophos;i="4.25,443,1199664000"; d="scan'208";a="15690739" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 04 Mar 2008 09:23:46 +0000 In-Reply-To: <56066.1204576004@sa.vix.com> References: <56066.1204576004@sa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: implications of RFC 2181 on cname chains MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Tue, 4 Mar 2008 10:23:45 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/03/2008 09:23:46 AM, Serialize complete at 04/03/2008 09:23:46 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion owner-namedroppers@ops.ietf.org wrote on 03/03/2008 09:26:44 PM: > Paul Vixie > Sent by: owner-namedroppers@ops.ietf.org > > 03/03/08 09:26 PM > > To > > namedroppers@ops.ietf.org > > cc > > Subject > > implications of RFC 2181 on cname chains > > in a private discussion with jinmei, he showed me this text from RFC 2181: > > > Note that the answer section of an authoritative answer normally > > contains only authoritative data. However when the name sought is an > > alias (see section 10.1.1) only the record describing that alias is > > necessarily authoritative. Clients should assume that other records > > may have come from the server's cache. Where authoritative answers > > are required, the client should query again, using the canonical name > > associated with the alias. > > i've struggled with this concept, since i had always restricted this > treatment to "out of zone" cnames. in other words when i receive... > > www.example.com. cname xxx.example.com. > xxx.example.com. aaaa dead::beef > > ...i had been treating both names as authoritative, since both are children of > the apex i was querying under. i've realized that xxx.example.com might be an > NS RR for which the example.com authority servers happen to have an AAAA RR > cached (or might have it as glue in the example.com zone). Or the server might be authoritative for both the zone example.com and the zone xxx.example.com. I have argued many times that the concept of zone is lost to the resolver, hence the resolver can not distinguish between 'in zone' and 'out of zone'. Roy -- to unsubscribe send a message to namedroppers-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 Mar 4 02:55:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A874C3A6A5D; Tue, 4 Mar 2008 02:55:08 -0800 (PST) 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 P8Wn1qPF9Wd4; Tue, 4 Mar 2008 02:55:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3344A3A6DAE; Tue, 4 Mar 2008 02:55:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWUfc-000PLa-On for namedroppers-data@psg.com; Tue, 04 Mar 2008 10:46:52 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWUfW-000PJH-TY for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 10:46:51 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m24Ajdxi002297; Tue, 4 Mar 2008 10:45:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m24AjXub002296; Tue, 4 Mar 2008 10:45:33 GMT Date: Tue, 4 Mar 2008 10:45:33 +0000 From: bmanning@vacation.karoshi.com To: Roy Arends Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: implications of RFC 2181 on cname chains Message-ID: <20080304104533.GA2266@vacation.karoshi.com.> References: <56066.1204576004@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > Or the server might be authoritative for both the zone example.com and the > zone xxx.example.com. I have argued many times that the concept of zone is > lost to the resolver, hence the resolver can not distinguish between 'in > zone' and 'out of zone'. > > Roy thats certainly true for a resolver - i'd argue that a validator has to understand the concept of zone... --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 4 03:59:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859943A67A9; Tue, 4 Mar 2008 03:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 hXVdrkkC-85p; Tue, 4 Mar 2008 03:59:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D189928C32B; Tue, 4 Mar 2008 03:57:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWVft-0009CB-HF for namedroppers-data@psg.com; Tue, 04 Mar 2008 11:51:13 +0000 Received: from [195.72.179.98] (helo=boo.jadickinson.co.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWVfm-00096p-Mv for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 11:51:12 +0000 Received: from [192.168.1.210] (unknown [192.168.1.210]) by boo.jadickinson.co.uk (Postfix) with ESMTP id 7A16229A3 for ; Tue, 4 Mar 2008 11:51:05 +0000 (GMT) Message-Id: From: John Dickinson To: namedroppers@ops.ietf.org In-Reply-To: <20080304104533.GA2266@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 v919.2) Subject: Re: implications of RFC 2181 on cname chains Date: Tue, 4 Mar 2008 11:51:05 +0000 References: <56066.1204576004@sa.vix.com> <20080304104533.GA2266@vacation.karoshi.com.> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 4 Mar 2008, at 10:45, bmanning@vacation.karoshi.com wrote: >> >> Or the server might be authoritative for both the zone example.com >> and the >> zone xxx.example.com. I have argued many times that the concept of >> zone is >> lost to the resolver, hence the resolver can not distinguish >> between 'in >> zone' and 'out of zone'. >> >> Roy > > thats certainly true for a resolver - i'd argue that a validator > has to understand the concept of zone... Why? A validator is just something that knows how to do something with the records it got from a resolver. The only other info it has that the resolver didn't know is the trust anchor. John --- John Dickinson -- to unsubscribe send a message to namedroppers-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 Mar 4 04:23:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41AE28C3F0; Tue, 4 Mar 2008 04:23:55 -0800 (PST) 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 XBFiRs9FnvPO; Tue, 4 Mar 2008 04:23:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2944928C433; Tue, 4 Mar 2008 04:23:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWW6x-000EK8-0Q for namedroppers-data@psg.com; Tue, 04 Mar 2008 12:19:11 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWW6e-000EHh-Hq for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 12:18:53 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m24CHTxi003357; Tue, 4 Mar 2008 12:17:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m24CHTSH003356; Tue, 4 Mar 2008 12:17:29 GMT Date: Tue, 4 Mar 2008 12:17:29 +0000 From: bmanning@vacation.karoshi.com To: John Dickinson Cc: namedroppers@ops.ietf.org Subject: Re: implications of RFC 2181 on cname chains Message-ID: <20080304121729.GB3241@vacation.karoshi.com.> References: <56066.1204576004@sa.vix.com> <20080304104533.GA2266@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: DNSEXT discussion On Tue, Mar 04, 2008 at 11:51:05AM +0000, John Dickinson wrote: > > On 4 Mar 2008, at 10:45, bmanning@vacation.karoshi.com wrote: > > >> > >>Or the server might be authoritative for both the zone example.com > >>and the > >>zone xxx.example.com. I have argued many times that the concept of > >>zone is > >>lost to the resolver, hence the resolver can not distinguish > >>between 'in > >>zone' and 'out of zone'. > >> > >>Roy > > > > thats certainly true for a resolver - i'd argue that a validator > > has to understand the concept of zone... > > > Why? A validator is just something that knows how to do something with > the records it got from a resolver. The only other info it has that > the resolver didn't know is the trust anchor. > > John Dickinson perhaps we are speaking past each other. a validatior walks the trust chain - starting from the data in the response from the query - until it reaches a keyset that matches one of its locally configured TAs. query - returns an RRset (and we are done, modulo the question of where did all the data in the RRset come from) no real need to know/care about delegation heirarchy. at least from the resolver end. validation - a series of query/responses to build a trust chain back to one of my local TAs. Very much needs to know how to walk the delegation hierarchy line. or did you mean something else? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 4 05:19:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312463A67E1; Tue, 4 Mar 2008 05:19:54 -0800 (PST) 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 axQA9URZg9jI; Tue, 4 Mar 2008 05:19:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77EA53A6A07; Tue, 4 Mar 2008 05:19:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWWxP-000LZa-KX for namedroppers-data@psg.com; Tue, 04 Mar 2008 13:13:23 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWWxL-000LYt-SF for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 13:13:21 +0000 Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m24DDBgK052644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 14:13:11 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <47CD4AE6.4090407@nlnetlabs.nl> Date: Tue, 04 Mar 2008 14:13:10 +0100 From: Matthijs Mekking User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: version -01 of draft-ietf-dnsext-dns-protocol-profile sent X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Tue, 04 Mar 2008 14:13:11 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I recently read this draft and I was 'suprised' by the structure. I was expecting a list of DNS references and how they relate to each other, but when I start reading I saw some common requirements, requirements for authoritative servers, stub resolvers, recursive resolvers, middle boxes and per category some extra information about zone contents, zone synchronization, message processing, further query processing, some extra information about the additional section, label compression, truncations, then NSEC is mentioned, some info about NSID... My point is: I was way lost in how all these documents and requirements was related. So I guess what I was expecting was something like: 1. Introduction ... 2. Fundamental requirements The basic DNS implementation and specification is described in: - RFC 1035. Implementations MUST follow the specification in this document. Background information can be found in: - RFC 1034: Domain names: concepts and facilities - ... 3. Extensional requirements For modern DNS implementations the following extensions MUST be implemented: - RFC 2671: EDNS0 - RFC 4035: DNS Security Extensions ... For modern DNS implementations the following extensions SHOULD be implemented: ... 4. Resource Records A modern DNS implementation MUST handle the following RRtypes correctly: - from RFC 1035: A, NS, MX, ... - from ... 5. Zone files ... Well, after this rather elaborating example, I should ask: do you agree? If not, I would like to suggest that in the introduction you describe how this document is structured, to give the reader some guidance. Otherwise, maybe a restructuring of the document should be considered. I have some other comments too: - - What is the definition of modern DNS implementation? This information is not included in the draft. - - page 5: EDNS0 MUST be implemented by all DNS systems. --> all modern DNS systems - - in 4.5 Additional Data processing >> Additional data may be added as long as there is space in the packet. {need reference} The reference is in RFC 1035 (section 4.1): >> the additional records section contains RRs which relate to the query, but are not strictly answers >> for the question. RFC 1035 also has many information about which RRs causes additional section processing. - - However, there are limits to this: RFC 4035 (section 3.1.2, page 11) states: >> The name server SHOULD NOT include the DNSKEY RRset unless there is enough space in the response >> message for both the DNSKEY RRset and its associated RRSIG RR(s). I suggest the following text to be added, (but actually I think this is too much detail, and should not be in this draft at all): Exceptions: * RFC 4035 (section 3.1.2, page 11) * ... (I don't know if there are more limitations to adding additional data that should be noted?) To summarize: I would like to see a different structure for this draft, and that it sums the necessary RFCs for the "modern" DNS implementation, and how these RFCs relate. Otherwise, consider Regards, Matthijs Mekking NLnet Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzUrmIXqNzxRs6egRAvH1AKCAvT2mVSqH4HoNHhV+sDRQgHT4UwCghQub AQYHxC1ib/ytfTbBvMzY9I0= =fco6 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 4 06:21:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86C428C55A; Tue, 4 Mar 2008 06:21:25 -0800 (PST) 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 1Vzb4HBDeb7z; Tue, 4 Mar 2008 06:21:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30CEA28C24F; Tue, 4 Mar 2008 06:21:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWXsa-0005Yu-KP for namedroppers-data@psg.com; Tue, 04 Mar 2008 14:12:28 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWXsX-0005YE-ML for namedroppers@ops.ietf.org; Tue, 04 Mar 2008 14:12:27 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m24ECJQS058433; Wed, 5 Mar 2008 01:12:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803041412.m24ECJQS058433@drugs.dv.isc.org> To: John Dickinson Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: implications of RFC 2181 on cname chains In-reply-to: Your message of "Tue, 04 Mar 2008 11:51:05 -0000." Date: Wed, 05 Mar 2008 01:12:19 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > On 4 Mar 2008, at 10:45, bmanning@vacation.karoshi.com wrote: > > >> > >> Or the server might be authoritative for both the zone example.com > >> and the > >> zone xxx.example.com. I have argued many times that the concept of > >> zone is > >> lost to the resolver, hence the resolver can not distinguish > >> between 'in > >> zone' and 'out of zone'. > >> > >> Roy > > > > thats certainly true for a resolver - i'd argue that a validator > > has to understand the concept of zone... > > > Why? A validator is just something that knows how to do something with > the records it got from a resolver. The only other info it has that > the resolver didn't know is the trust anchor. It knows the trust anchor for a ZONE. You chain trust across ZONE boundaries with signed DS and DNSKEY records. You go insecure at ZONE boundaries by presenting the correctly signed NSEC records. > John > --- > John Dickinson -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@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 Mar 4 21:53:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06273A6A6B; Tue, 4 Mar 2008 21:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.678 X-Spam-Level: X-Spam-Status: No, score=-4.678 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 7sf4T7YoACFy; Tue, 4 Mar 2008 21:53:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9116828C1E8; Tue, 4 Mar 2008 21:53:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWmOj-000DRR-6A for namedroppers-data@psg.com; Wed, 05 Mar 2008 05:42:37 +0000 Received: from [129.9.168.76] (helo=shvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWmOe-000DOz-WF for namedroppers@ops.ietf.org; Wed, 05 Mar 2008 05:42:35 +0000 Received: from shnavip4-hme0.shdc.chrysler.com (unknown [53.231.141.98]) by shvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id EE8B0110564 for ; Wed, 5 Mar 2008 00:32:08 -0500 (EST) Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by shnavip4-hme0.shdc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008030500423010144 for ; Wed, 05 Mar 2008 00:42:30 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m255gVPZ019962 for ; Wed, 5 Mar 2008 00:42:31 -0500 (EST) Message-ID: <47CE32C7.8070709@chrysler.com> Date: Wed, 05 Mar 2008 00:42:31 -0500 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: edns-0 References: <200802280321.m1S3Ltgw073526@drugs.dv.isc.org> <47C677A2.3050207@nlnetlabs.nl> In-Reply-To: <47C677A2.3050207@nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Wouter Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Changed subject line. > > Mark Andrews wrote: > |>> EDNS has been on standards track for 9+ years now. It takes > |>> less than a day to add EDNS support to a nameserver. There > |>> really is no excuse anymore for any vendor shipping a DNS > |>> server that doesn't respond to EDNS queries using EDNS. > |>> > |>> If you have a DNS server, however old, that drops EDNS > |>> queries then you should ship a fix. The server is BROKEN > |>> and the rest of us are feed up with working around broken > |>> implementations. > |> "send diffs." > | > | 5.3. Responders who do not understand these protocol extensions > | are expected to send a response with RCODE NOTIMPL or FORMERR > | as per RFC 1034. Firewalls that do not pass EDNS are expected > | to respond requests with FORMERR. > | > | 5.4. Firewalls that see a UDP/EDNS request that indicates a UDP > | buffer size that is larger than the firewall's maximum DNS/UDP > | transmission size should respond to the EDNS request with > | RCODE= and set the UDP size to the firewalls maximum DNS/UDP > | transmission size. > > I like the text up to here. The remainder is not going in the draft. > > | 5.5. There are firewalls that pass EDNS queries but fail to allow > | responses larger that 512 octets through. A client MAY choose to > | treat a timeout out as indicating the a UDP buffer size of 512 > | octets should be advertised in future requests. > > Firewalls that drop responses larger than 512 should send an errorcode. > > | 5.6. There are responder and firewalls that silently drop EDNS > | requests. A client MAY choos to treat timeouts as indicating > | lack of EDNS support. The client however MUST first attempt > | making EDNS requests with a UDP payload size of 512 if it makes > | this decision. > > Firewalls should not silently drop EDNS, but instead send the rcode. I don't like this at all. It moves us a big step away from the End-to-End Principle, from *passive* violation of the principle -- a firewall posing as "noise", passing or dropping packets as its policy dictates, with packet drop being handled by the usual retry/retransmit mechanisms and/or parameters -- to *active* violation of the principle, by deliberate and direct in-transit manipulation of the endpoint-to-endpoint payload by an intermediate node. In my opinion, this is almost as bad as NAT or its associated in-transit DNS "fixups". Beyond the pure protocol objection, I also have little confidence that a firewall implementor who hasn't bothered to add EDNS0 compatibility after all this time is suddenly going to acquire the enthusiasm and wherewithal to enhance their product(s) with a new "error code" feature. Or, if they attempt it, they'll probably get it wrong. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From cereeves@att.com Wed Mar 5 07:09:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5071A28C4CF for ; Wed, 5 Mar 2008 07:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.723 X-Spam-Level: X-Spam-Status: No, score=-22.723 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, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, LOW_PRICE=0.001, PRICES_ARE_AFFORDABLE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, 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 LWYetUomxQIw for ; Wed, 5 Mar 2008 07:09:52 -0800 (PST) Received: from pool-11-143-197-89.dbd-ipconnect.net (pool-11-143-197-89.dbd-ipconnect.net [89.197.143.11]) by core3.amsl.com (Postfix) with ESMTP id 36CAA3A6EDC for ; Wed, 5 Mar 2008 07:09:52 -0800 (PST) Message-ID: <000801c87ed2$069e7f7c$468e1ebd@ffiduxqd> From: "care ellen" To: "Velma Costello" Subject: exclusive watches, affordable prices rolex Date: Wed, 05 Mar 2008 13:22:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Discover Our Range of Luxury Rolex Watches for Men and Women... Incredibly Low Prices! http://beryldomemits.com/ From owner-namedroppers@ops.ietf.org Wed Mar 5 18:31:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F4D3A692A; Wed, 5 Mar 2008 18:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.804 X-Spam-Level: X-Spam-Status: No, score=-99.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 xxLXYiffsIli; Wed, 5 Mar 2008 18:31:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D7E33A686F; Wed, 5 Mar 2008 18:31:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX5mE-000LuY-Ti for namedroppers-data@psg.com; Thu, 06 Mar 2008 02:24:10 +0000 Received: from [202.224.39.217] (helo=mails1.asahi-net.or.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX5mC-000LuI-Gz for namedroppers@ops.ietf.org; Thu, 06 Mar 2008 02:24:09 +0000 Received: from mailav1.asahi-net.or.jp (mailav1.asahi-net.or.jp [202.224.39.220]) by mails1f.asahi-net.or.jp (Postfix) with SMTP id DDC07C609 for ; Thu, 6 Mar 2008 11:24:07 +0900 (JST) Received: from mails1.asahi-net.or.jp ([202.224.39.217]) by mailav1.asahi-net.or.jp (NAVGW 2.5.2.9) with SMTP id M2008030611240713959 for ; Thu, 06 Mar 2008 11:24:07 +0900 Received: from reseaux.priv.k2r.org (s163221.ppp.asahi-net.or.jp [220.157.163.221]) by mails1.asahi-net.or.jp (Postfix) with ESMTP id 75B08C609 for ; Thu, 6 Mar 2008 11:24:07 +0900 (JST) Received: (qmail 72843 invoked by uid 1000); 6 Mar 2008 02:24:07 -0000 Date: Thu, 6 Mar 2008 11:24:07 +0900 From: Kenji Rikitake To: namedroppers@ops.ietf.org Subject: Re: edns0-bis submitted Message-ID: <20080306022407.GA72790@k2r.org> References: <20080303031337.GA68521@k2r.org> <200803030345.m233jE6A084554@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803030345.m233jE6A084554@drugs.dv.isc.org> User-Agent: Mutt/1.5.14 (2007-02-12) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion In the message <200803030345.m233jE6A084554@drugs.dv.isc.org> dated Mon, Mar 03, 2008 at 02:44:51PM +1100, Mark Andrews writes: > Any nameserver that sets DF for IPv4 UDP resonses is broken. Does this sentence implicate that for a large-size answer (such as that for DNSSEC) exceeding the IPv4 MTU should (or even must) be sent by TCP? > For IPv6 network MTU fragmentation should be being performed. I understand that IPv6 has its own end-to-end fragmentation header and routers do not fragment IPv6 packets, so that this is a negotiable issue between the hosts. Correct me if I'm wrong. > [Rikitake writes:] > > In this case, I think falling back to EDNS @IP-MTU-aware-value > > (presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though > > the state management will get more complicated because it's adding > > another state between EDNS and "EDNS @512". > > > > I'd like to see the pros and cons. > > It's not worth trying to detect. OK, I understand your idea. > I actually sit behind a NAT which can't handle out of order > fragments. I just configure the nameserver to advertise a > EDNS UDP size of 1460. Is it by the "maxudp" option on BIND 9.4 and later? Kenji Rikitake -- to unsubscribe send a message to namedroppers-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 Mar 5 19:04:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B9F28C0FA; Wed, 5 Mar 2008 19:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2hK-7TCS+NC; Wed, 5 Mar 2008 19:04:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D22F3A6CD0; Wed, 5 Mar 2008 19:03:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX6Jb-0000le-FX for namedroppers-data@psg.com; Thu, 06 Mar 2008 02:58:39 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX6JY-0000jt-Bk for namedroppers@ops.ietf.org; Thu, 06 Mar 2008 02:58:37 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m262wN50018093; Thu, 6 Mar 2008 13:58:23 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803060258.m262wN50018093@drugs.dv.isc.org> To: Kenji Rikitake Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: edns0-bis submitted In-reply-to: Your message of "Thu, 06 Mar 2008 11:24:07 +0900." <20080306022407.GA72790@k2r.org> Date: Thu, 06 Mar 2008 13:58:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > In the message <200803030345.m233jE6A084554@drugs.dv.isc.org> > dated Mon, Mar 03, 2008 at 02:44:51PM +1100, > Mark Andrews writes: > > Any nameserver that sets DF for IPv4 UDP resonses is broken. > > Does this sentence implicate that for a large-size answer (such as that > for DNSSEC) exceeding the IPv4 MTU should (or even must) be sent by TCP? > > > For IPv6 network MTU fragmentation should be being performed. > > I understand that IPv6 has its own end-to-end fragmentation header and > routers do not fragment IPv6 packets, so that this is a negotiable issue > between the hosts. Correct me if I'm wrong. > > > [Rikitake writes:] > > > In this case, I think falling back to EDNS @IP-MTU-aware-value > > > (presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though > > > the state management will get more complicated because it's adding > > > another state between EDNS and "EDNS @512". > > > > > > I'd like to see the pros and cons. > > > > It's not worth trying to detect. > > OK, I understand your idea. > > > I actually sit behind a NAT which can't handle out of order > > fragments. I just configure the nameserver to advertise a > > EDNS UDP size of 1460. > > Is it by the "maxudp" option on BIND 9.4 and later? edns-udp-size as it's a problem with the inbound path. > Kenji Rikitake > > -- > to 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: Mark_Andrews@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 Mar 5 19:06:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B73028C0FA; Wed, 5 Mar 2008 19:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-1.478, 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 rrBsz8Uv8bqR; Wed, 5 Mar 2008 19:06:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DCC83A686F; Wed, 5 Mar 2008 19:06:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX6NZ-0001QC-Vv for namedroppers-data@psg.com; Thu, 06 Mar 2008 03:02:45 +0000 Received: from [202.12.29.58] (helo=mint.apnic.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JX6NW-0001PS-Aj for namedroppers@ops.ietf.org; Thu, 06 Mar 2008 03:02:44 +0000 Received: from dhcp245.apnic.net (dhcp245.apnic.net [202.12.29.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 7285DD5F2D for ; Thu, 6 Mar 2008 13:02:41 +1000 (EST) Message-Id: <626494D4-7D31-40C8-91CB-8E9C78F4D634@apnic.net> From: George Michaelson To: namedroppers@ops.ietf.org In-Reply-To: <47CD4AE6.4090407@nlnetlabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: version -01 of draft-ietf-dnsext-dns-protocol-profile sent Date: Thu, 6 Mar 2008 13:02:41 +1000 References: <47CD4AE6.4090407@nlnetlabs.nl> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Thanks for your comments Matthijs. The structure of the document was chosen as a guide to implementors/ testers/purchasors, following RFC4035. Its aimed at giving them the information that relates to the architecture they are interested in. Its not a general DNS reading list, but a requirements document. I will certainly try to improve the introductory text(s) to make it clearer, and if you have any suggested wordings I'd welcome them! -George On 04/03/2008, at 11:13 PM, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I recently read this draft and I was 'suprised' by the structure. > I was expecting a list of DNS references and how they relate to each > other, > but when I start reading I saw some common requirements, requirements > for authoritative servers, stub resolvers, recursive resolvers, middle > boxes and per category some extra information about zone contents, > zone synchronization, message processing, further query processing, > some extra information about the additional section, label > compression, truncations, then NSEC is mentioned, some info about > NSID... > > My point is: I was way lost in how all these documents and > requirements was related. > So I guess what I was expecting was something like: > > 1. Introduction > ... > 2. Fundamental requirements > The basic DNS implementation and specification is described > in: > - RFC 1035. > Implementations MUST follow the specification in this > document. > Background information can be found in: > - RFC 1034: Domain names: concepts and facilities > - ... > 3. Extensional requirements > For modern DNS implementations the following extensions MUST > be implemented: > - RFC 2671: EDNS0 > - RFC 4035: DNS Security Extensions > ... > For modern DNS implementations the following extensions > SHOULD be implemented: > ... > 4. Resource Records > A modern DNS implementation MUST handle the following RRtypes > correctly: > - from RFC 1035: A, NS, MX, ... > - from ... > 5. Zone files > ... > > Well, after this rather elaborating example, I should ask: do you > agree? If not, I would like to > suggest that in the introduction you describe how this document is > structured, to give the reader > some guidance. Otherwise, maybe a restructuring of the document should > be considered. > > I have some other comments too: > > - - What is the definition of modern DNS implementation? This > information is not included in the draft. > > - - page 5: EDNS0 MUST be implemented by all DNS systems. --> all > modern > DNS systems > > - - in 4.5 Additional Data processing >>> Additional data may be added as long as there is space in the > packet. {need reference} > The reference is in RFC 1035 (section 4.1): >>> the additional records section contains RRs which relate to the > query, but are not strictly answers >>> for the question. > RFC 1035 also has many information about which RRs causes additional > section processing. > > - - However, there are limits to this: RFC 4035 (section 3.1.2, page > 11) > states: >>> The name server SHOULD NOT include the DNSKEY RRset unless there > is enough space in the response >>> message for both the DNSKEY RRset and its associated RRSIG RR(s). > I suggest the following text to be added, (but actually I think this > is too much detail, and should not > be in this draft at all): > Exceptions: > * RFC 4035 (section 3.1.2, page 11) > * ... > (I don't know if there are more limitations to adding additional > data that should be noted?) > > > To summarize: I would like to see a different structure for this > draft, and that it sums the necessary RFCs > for the "modern" DNS implementation, and how these RFCs relate. > Otherwise, consider > > Regards, > > Matthijs Mekking > NLnet Labs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHzUrmIXqNzxRs6egRAvH1AKCAvT2mVSqH4HoNHhV+sDRQgHT4UwCghQub > AQYHxC1ib/ytfTbBvMzY9I0= > =fco6 > -----END PGP SIGNATURE----- > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 6 10:02:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3CA28C42C; Thu, 6 Mar 2008 10:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 kxeMra0lOo2u; Thu, 6 Mar 2008 10:02:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFF5228C3CD; Thu, 6 Mar 2008 10:01:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXKDo-000N0w-CC for namedroppers-data@psg.com; Thu, 06 Mar 2008 17:49:36 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXKCr-000MqT-Tx for namedroppers@ops.ietf.org; Thu, 06 Mar 2008 17:48:57 +0000 Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXKCp-000DnI-HM; Thu, 06 Mar 2008 17:48:35 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <6E50EFAC-AD55-4EB5-A04E-1566992A1B00@ca.afilias.info> From: Joe Abley To: Kenji Rikitake In-Reply-To: <20080306022407.GA72790@k2r.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: edns0-bis submitted Date: Thu, 6 Mar 2008 12:48:34 -0500 References: <20080303031337.GA68521@k2r.org> <200803030345.m233jE6A084554@drugs.dv.isc.org> <20080306022407.GA72790@k2r.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 5-Mar-2008, at 21:24, Kenji Rikitake wrote: > In the message <200803030345.m233jE6A084554@drugs.dv.isc.org> > dated Mon, Mar 03, 2008 at 02:44:51PM +1100, > Mark Andrews writes: >> Any nameserver that sets DF for IPv4 UDP resonses is broken. > > Does this sentence implicate that for a large-size answer (such as > that > for DNSSEC) exceeding the IPv4 MTU should (or even must) be sent by > TCP? I read it as saying that large-size answers sent over UDP should be sent with DF=0 (i.e. such that fragmentation is possible). Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 6 14:08:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B749428CB02; Thu, 6 Mar 2008 14:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2XDrYnniiIg; Thu, 6 Mar 2008 14:08:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F24A028CB0E; Thu, 6 Mar 2008 14:06:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXO5l-000MKh-Bj for namedroppers-data@psg.com; Thu, 06 Mar 2008 21:57:33 +0000 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXO5i-000MK3-98 for namedroppers@ops.ietf.org; Thu, 06 Mar 2008 21:57:31 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id CBE991186AD; Thu, 6 Mar 2008 13:57:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5155 on DNS Security (DNSSEC) Hashed Authenticated Denial of Existence From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Message-Id: <20080306215729.CBE991186AD@bosco.isi.edu> Date: Thu, 6 Mar 2008 13:57:29 -0800 (PST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion A new Request for Comments is now available in online RFC libraries. RFC 5155 Title: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Author: B. Laurie, G. Sisson, R. Arends, D. Blacka Status: Standards Track Date: March 2008 Mailbox: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com Pages: 52 Characters: 112338 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-nsec3-13.txt URL: http://www.rfc-editor.org/rfc/rfc5155.txt The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to unsubscribe send a message to namedroppers-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 Mar 6 15:31:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA43A6938; Thu, 6 Mar 2008 15:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-1.946, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 763SzwgnJtSR; Thu, 6 Mar 2008 15:31:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80E483A67CC; Thu, 6 Mar 2008 15:31:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXPRC-000CL4-Ne for namedroppers-data@psg.com; Thu, 06 Mar 2008 23:23:46 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXPR1-000CJ1-Eo for namedroppers@ops.ietf.org; Thu, 06 Mar 2008 23:23:37 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m26NNM5a072146; Fri, 7 Mar 2008 10:23:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803062323.m26NNM5a072146@drugs.dv.isc.org> To: Joe Abley Cc: Kenji Rikitake , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: edns0-bis submitted In-reply-to: Your message of "Thu, 06 Mar 2008 12:48:34 CDT." <6E50EFAC-AD55-4EB5-A04E-1566992A1B00@ca.afilias.info> Date: Fri, 07 Mar 2008 10:23:22 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > On 5-Mar-2008, at 21:24, Kenji Rikitake wrote: > > > In the message <200803030345.m233jE6A084554@drugs.dv.isc.org> > > dated Mon, Mar 03, 2008 at 02:44:51PM +1100, > > Mark Andrews writes: > >> Any nameserver that sets DF for IPv4 UDP resonses is broken. > > > > Does this sentence implicate that for a large-size answer (such as > > that > > for DNSSEC) exceeding the IPv4 MTU should (or even must) be sent by > > TCP? > > I read it as saying that large-size answers sent over UDP should be > sent with DF=0 (i.e. such that fragmentation is possible). Correct. DF works reasonably well with TCP. DF does not work well with many UDP applications which includes DNS. IPv6 a setsockopt() to force network MTU to be used. A DNS server should be setting it. if (pf == AF_INET6) { (void)setsockopt(sock->fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, (void *)&on, sizeof(on)); } Network MTU does not make sense for IPv4. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 7 11:14:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830B03A6B1F; Fri, 7 Mar 2008 11:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqMaw6MEw0BG; Fri, 7 Mar 2008 11:14:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4F623A6F22; Fri, 7 Mar 2008 11:14:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXhrh-000EYd-4m for namedroppers-data@psg.com; Fri, 07 Mar 2008 19:04:21 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXhre-000EXS-9B for namedroppers@ops.ietf.org; Fri, 07 Mar 2008 19:04:19 +0000 Received: from [192.168.1.100] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m27J48lj011240; Fri, 7 Mar 2008 14:04:09 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <54773.1204307824@sa.vix.com> References: <69903.1204047792@sa.vix.com> <72809.1204051801@sa.vix.com> <3870C46029D1F945B1472F170D2D9790038E3F18@de01exm64.ds.mot.com> <48860.1204160051@sa.vix.com> <2E7BB4EB-08BD-4E80-AEAA-17CDD8FB02E8@ca.afilias.info> <54773.1204307824@sa.vix.com> Date: Fri, 7 Mar 2008 13:59:31 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: dns-0x20.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 17:57 +0000 2/29/08, Paul Vixie wrote: >i agree. however, we have in the past insisted that all authority servers for >a zone support the same level of dnssec. could we not also insist that all >members of anycast clusters support the same level of edns? I don't think that any protocol defining document can credibly "insist" any operational practice, nor define a protocol based on the assumption that the operators comply with the "insisted" behavior. It would be ideal if all servers answering to a single IP address were 100% compatible. But there are times in operations when it isn't (/may not be) practical to stick to that recommendation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Mail archives, backups. Sometimes I think the true beneficiaries of standards work are the suppliers of disk drives. -- to unsubscribe send a message to namedroppers-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 Mar 8 05:30:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9684229359A; Sat, 8 Mar 2008 05:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.804 X-Spam-Level: X-Spam-Status: No, score=-99.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 1pnu3bjphS6I; Sat, 8 Mar 2008 05:28:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B3F22937FD; Fri, 7 Mar 2008 15:33:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXlvM-000L2k-Sa for namedroppers-data@psg.com; Fri, 07 Mar 2008 23:24:24 +0000 Received: from [202.224.39.218] (helo=mails2.asahi-net.or.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXlvJ-000L14-Lk for namedroppers@ops.ietf.org; Fri, 07 Mar 2008 23:24:23 +0000 Received: from mailav2.asahi-net.or.jp (mailav2.asahi-net.or.jp [202.224.39.221]) by mails2f.asahi-net.or.jp (Postfix) with SMTP id 5867FC60B for ; Sat, 8 Mar 2008 08:24:20 +0900 (JST) Received: from mails2.asahi-net.or.jp ([202.224.39.218]) by mailav2.asahi-net.or.jp (NAVGW 2.5.2.9) with SMTP id M2008030808242004219 for ; Sat, 08 Mar 2008 08:24:20 +0900 Received: from reseaux.priv.k2r.org (s163221.ppp.asahi-net.or.jp [220.157.163.221]) by mails2.asahi-net.or.jp (Postfix) with ESMTP id 91C57C60B for ; Sat, 8 Mar 2008 08:24:19 +0900 (JST) Received: (qmail 4273 invoked by uid 1000); 7 Mar 2008 23:24:19 -0000 Date: Sat, 8 Mar 2008 08:24:19 +0900 From: Kenji Rikitake To: namedroppers@ops.ietf.org Subject: Re: edns0-bis submitted Message-ID: <20080307232419.GA4075@k2r.org> References: <6E50EFAC-AD55-4EB5-A04E-1566992A1B00@ca.afilias.info> <200803062323.m26NNM5a072146@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803062323.m26NNM5a072146@drugs.dv.isc.org> User-Agent: Mutt/1.5.14 (2007-02-12) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I 100% agree with Joe and Mark's answers on setting DF when sending TCP (and NOT in UDP). My wording of DF might have caused misunderstanding. My thanks to Joe and Mark. Let me rephrase. I am thinking about dealing with a middie box dropping IP fragments (i.e., the second or later parts of fragmented IP datagrams), and consequently blocking UDP with multiple IP fragments. If this middlebox is set on the resolver's side, the resolver's query will reach to the server without problem, but the server's answer will be blocked by the middlebox, so the transaction will fail until the client decides to fall back on TCP. I understand that Mark wrote the above case is not worth to detect. Should the resolver just wait and see? Kenji Rikitake -- to unsubscribe send a message to namedroppers-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 Mar 8 05:59:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DDF28CBD2; Sat, 8 Mar 2008 05:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y04IFEHObngF; Sat, 8 Mar 2008 05:59:10 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5BA928E70B; Fri, 7 Mar 2008 16:16:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXmeO-000A84-Fp for namedroppers-data@psg.com; Sat, 08 Mar 2008 00:10:56 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JXmeJ-000A6x-TO for namedroppers@ops.ietf.org; Sat, 08 Mar 2008 00:10:55 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m280Aiit036843; Sat, 8 Mar 2008 11:10:44 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803080010.m280Aiit036843@drugs.dv.isc.org> To: Kenji Rikitake Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: edns0-bis submitted In-reply-to: Your message of "Sat, 08 Mar 2008 08:24:19 +0900." <20080307232419.GA4075@k2r.org> Date: Sat, 08 Mar 2008 11:10:44 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I 100% agree with Joe and Mark's answers on setting DF when sending TCP > (and NOT in UDP). My wording of DF might have caused misunderstanding. > My thanks to Joe and Mark. > > Let me rephrase. > > I am thinking about dealing with a middie box dropping IP fragments > (i.e., the second or later parts of fragmented IP datagrams), and > consequently blocking UDP with multiple IP fragments. It the packet is fragmented it will almost certainly be bigger than 512 octets originally. This is indistingishable from a firewall which drops unfragmented UDP responses bigger than 512 octets. Falling back to 512 octet EDNS packets handles both cases. Trying to find the largest packet size that works is not worth the effort. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 8 15:46:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE373A6B96; Sat, 8 Mar 2008 15:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDX4i8fppMvw; Sat, 8 Mar 2008 15:46:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E87E93A6A5D; Sat, 8 Mar 2008 15:46:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JY8Wx-0006PD-GG for namedroppers-data@psg.com; Sat, 08 Mar 2008 23:32:43 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JY8Wt-0006Mu-S6 for namedroppers@ops.ietf.org; Sat, 08 Mar 2008 23:32:41 +0000 Received: from [10.150.132.54] (72-255-25-105.client.stsn.net [72.255.25.105]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m28NWXVC094087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Mar 2008 00:32:34 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Cc: Phillip Hallam-Baker Message-Id: From: Olaf Kolkman To: IETF DNSEXT WG Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-37--921313727" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Fwd: Impending publication: draft-iab-dns-choices-05 Date: Sat, 8 Mar 2008 18:32:32 -0500 References: <5197D0B7-7EF3-4F88-87DB-AFE0A33FE048@NLnetLabs.nl> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.919.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Sun, 09 Mar 2008 00:32:35 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-37--921313727 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I wrote that I CC-ed the message to DNSEXT and used the wrong address. Here is a forward. Begin forwarded message: > From: Olaf Kolkman > Date: March 8, 2008 6:28:22 PM EST > To: Phillip Hallam-Baker > Cc: Patrik F=E4ltstr=F6m , IETF-Discussion = Discussion =20 > , "iab@iab.org IAB" , dnsext@ietf.org > Subject: RE: Impending publication: draft-iab-dns-choices-05 > > > Dear Philip, > > You referred to draft-hallambaker-xptr-00.txt and wrote: > >> The list of comments does not include my core objection made in the =20= >> 'Domain Centric Administration' and XPTR drafts, that it is in fact =20= >> possible to create 'midpoint' wildcards of the form =20 >> '_prefix.*.example.com' by the simple measure of introducing a =20 >> layer of indirection. This may be implemented by defining semantics =20= >> for the existing PTR record in the forward DNS or by introducing =20 >> one new RR to deal with the issue as is suggested in XPTR. >> >> [U] If you want to construct this wildcard you may use: >> >> *.example.com PTR _wildcard.example.com >> _prefix1._wildcard.example.com TXT "Text" >> _prefix2._wildcard.example.com SRV blah... >> _prefix3._wildcard.example.com NAPTR blah... >> >> The search strategy is then quite simple, if a search for the =20 >> record itself returns no answer you look for the PTR record at the =20= >> node to be queried, if that exists you concatenate the prefix to =20 >> the result of the PTR indirection and do a lookup there. >> > > This strategy is one that may work. I'd argue that defining an XPTR =20= > RR is probably cleaner than the re-use of a pointer record because =20 > the semantics of PTR might be hardcoded somewhere outside of your =20 > control. > > An observation of more fundamental nature is that you are moving =20 > away from a query-response model to a search strategy. And the first =20= > tradeoff you make there is one of performance and load on the system =20= > as a whole. It is easy to argue that the DNS can deal with the extra =20= > load, but I note that your proposed strategy involves an extra =20 > query _every_ time that you do not get a response to a query to the =20= > direct name. Obviously not a problem during the onset of the =20 > deployment (your proposal has the nice property of incremental =20 > deployment) but if the approach gets ubiquitous then we have pushed =20= > significant costs to the system as a whole. I am of the opinion that =20= > taking NO (NXDOMAIN) for an answer is, IMHO, an important property =20 > of the scalability of the DNS and we need to think very deep about =20 > the consequences of these extra queries. > > >> The strategy always completes in two or three lookups, there is =20 >> never a requirement to do tree climbing. A DNS server can =20 >> efficiently predict the optimum responses to send as additional =20 >> records. It is fully compatible with other DNS extensions. > > The above paragraph suggests a strategy to deal with the performance =20= > issue. Note however that this means that your proposal relies on =20 > special processing that will will need to be implemented in =20 > authoritative and recursive nameservers. That makes this performance =20= > optimization is subject to the same arguments you use to counter the =20= > arguments that one cannot rely on the ubiquitous support for unknown =20= > resource records. Also there are reasons not to rely on the results =20= > provided in the additional sections (in absence of DNSSEC). > > There have been proposals to do some sort of pre-processing to =20 > generate the nodes that should match _bla._foo.*.example.com. Such =20 > proposals will not be able to generate each an every combination for =20= > the wild-card but that may be sufficient for the use cases at hand. > > All and all, I am not convinced if your proposal is _the_ solution =20 > to the wildcard problems at hand. My main problem with it is the =20 > "extra query after an NXDOMAIN". I think that the DNSEXT working =20 > group is a better place to discuss the proposal and I've CC-ed them =20= > on this note. > > Having said all this, I do agree with your point that the "RR-type" =20= > space is not infinite. The question if that is a problem can only be =20= > answered by the Crystal Ball of the proper brand. I think it would =20= > be fair to suggest some text to deal with that issue. > > Also, although I know I'm biased, and can blame English to be my =20 > second language, I have always read the dns-choices document as a =20 > series of considerations and trade-offs. If you could point out the =20= > fragments of text that come across as degrading that would help the =20= > editor. In that context the request to "send text" is fair. > > In the spirit of the send-text and the above discussion I would =20 > suggest text along the following line: > > > Somewhere around the section where the wildcard arguments are made: > > -- > There have been proposals to deal with the problem that DNS wild-=20 > cards are always terminal records. These proposals introduce an =20 > additional set of trade-offs that would need to be taken into =20 > account when assessing which extension mechanism to choose. Aspects =20= > of extra response time needed to perform the extra queries, costs of =20= > pre-calculation of possible answers, or the costs induced to the =20 > system as a whole come to mind. At the time of writing none of these =20= > proposals has been published as standards tracks RFCs. > -- > > And we probably need to mention explicitly that the RRTYPE code =20 > space is finite. I think that somewhere in section 5 we can add a =20 > paragraph along the following lines: > > -- > There is a drawback to defining new RR types that is worth =20 > mentioning. The RRTYPE is a 16 bit value and hence a a limited =20 > resource. In order to prevent herding the registry has a review =20 > based allocation policy [RFC2929bis], however this may not be =20 > sufficient if extension of the DNS by addition of new RR types takes =20= > up significantly and the registry starts nearing completion. In that =20= > case the trade-offs with respect to choosing an extension mechanism =20= > may need to change. > -- > > > To the last paragraph one could add a suggestion for a future IAB to =20= > review the trade-offs when the allocation rate suggests completion =20 > of the registry in a decade. > > > Kind regards, without hats, > > --Olaf > --Apple-Mail-37--921313727 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) Comment: This message is locally signed. iEYEARECAAYFAkfTIhAACgkQtN/ca3YJIoehdwCeKsf1vrqvUY++9uNGEeaDsCp3 3OYAnjJMATR0MhDd6VC5yjBGhcKARssF =jjO7 -----END PGP SIGNATURE----- --Apple-Mail-37--921313727-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From WesleytimetableGardner@novell.com Sun Mar 9 16:32:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082493A682B; Sun, 9 Mar 2008 16:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.927 X-Spam-Level: *** X-Spam-Status: No, score=3.927 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, DATE_IN_PAST_06_12=1.069, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_LH_HOME=3.714, INVALID_MSGID=1.9, MALE_ENHANCE=2.596, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utxI8imu63LH; Sun, 9 Mar 2008 16:32:34 -0700 (PDT) Received: from begebeo7favt8y.lan (unknown [207.112.84.154]) by core3.amsl.com (Postfix) with SMTP id CA06B3A68CA; Sun, 9 Mar 2008 16:32:33 -0700 (PDT) Message-ID: 3f73001c8823d$84eb2cc0$4001a8c0@begebeo7favt8y From: "Dustin Pierce" To: Cc: , , , Subject: Male Enhancement Reviews Date: Sun, 9 Mar 2008 19:30:02 +0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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.1441 Make the Impossible, Possible. Enlarge your Penis by 3" in Weeks! http://Kolrettinos.com/ From owner-namedroppers@ops.ietf.org Tue Mar 11 08:09:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86A028C4E5; Tue, 11 Mar 2008 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg7O7DXCLsV5; Tue, 11 Mar 2008 08:09:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECFE23A6D15; Tue, 11 Mar 2008 08:07:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ5uY-000AKT-KL for namedroppers-data@psg.com; Tue, 11 Mar 2008 14:57:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ5uI-000AHM-Aj for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 14:56:53 +0000 Received: from [130.129.23.164] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2BEuZsv075723; Tue, 11 Mar 2008 10:56:36 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080218210001.AB0E13A6876@core3.amsl.com> References: <20080218210001.AB0E13A6876@core3.amsl.com> Date: Tue, 11 Mar 2008 10:55:55 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Referring to: >Title : Measures for making DNS more resilient against >forged answers >Date : 2008-02-18 >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt In Section 3: # DNS data is accepted by a resolver if and only if: # # 1. The question section of the reply packet is identical to that of # a question packet currently waiting for an answer # ... # # 5. It is the first answer to match the previous four conditions. I"m not sure if this is a statement of historic fact, current recommended behavior, or a proposed set of rules. So my comments might just slide off the table. I think #1 isn't a "given" rule, as there is another proto-draft distributed to try to make it so. I disagree with #5. In one scenario, the "last" answer to match is the best - that is, if the true responder is "further away" than the source of a stuffed answer. (Such as a DNS spoofer on the same wireless LAN the client is on.) All in all, there's no hard and fast rule about whether it is the "first" or "last" that is most credible or trustworthy. # 4.5. Have the answer arrive before the authentic answer # # Once any packet has matched the previous four conditions, no further # answers should be accepted. Again, not sure of the tone of this statement, I think this is a bad recommendation and, fwiw, a general weakness in DNSSEC?TSIG/SIG(0) implementations. It isn't the first answer that is the end of the network transaction, it's the first verifiable answer that is needed. Receivers of DNS responses ought to keep listening past the first receipt of an answer that matches the superficial criteria, listening until they verify an answer or hit the timeout for a non-response. # 5. Birthday attacks # # The so called birthday paradox means that a group of 22 people # suffices to have a more than even chance of having two or more # members of the group share a birthday. Such a statement of fact should be supported by a reference to a proof, or include a proof. Doesn't the number 22 have to do with the fact that there are just 366 possible dates? # 6. Accepting only in-zone answers # # Answers from authoritative nameservers often contain information that # is not part of the zone for which we deem it authoritative. As an # example, a query for the MX record of a domain might get as its # answer a mail exchanger in another domain, and additionally the IP # address of this mail exchanger. # # If accepted uncritically, the resolver stands the chance of accepting # data from an untrusted source. Care must be taken to only accept # data if it is known that the originator is authoritative for that # data. # # One very simple way to achieve this is to only accept data if it is # part of the domain we asked the question for. What if you ask a root server for the A record of a.root-servers.net.? (Let's forget that most of the root servers are "illegitimate" authoritative servers for that zone.) The root server is also authoritative for root-servers.net. and will choose to respond with data from that zone. The server doesn't know what zone the query is being "shot" at, so it can't tune the answer to be a referral from the root to dotNET (net.). Queries aren't sent to domains, they are sent to servers. Answers are generated from zone data available at a server. Perhaps what should be recommended is that a server should answer from only one zone at a time and provide the "proof" that is is authoritative for the zone providing the source for the answer. # 7. Combined difficulty A question on these numbers # A realistic minimal DNS answer consists of around 80 bytes, including # IP headers, making the packet rate above correspond to a respectable # burst of 416Mb/s. #... # These numbers change when a window of a full second is assumed, #... # This reduces the needed bandwidth to 42 Mb/s. # # If in addition the attacker is granted more than a single chance and # allowed up to 60 minutes of work on a domain with a time to live of # 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake # data accepted. There are bandwidths needed to attack (cache poison) ONE resolver for ONE RRset or at most ONE domain name, right? I.e., you can't easily pull off a widespread cache poisoning with only this amount of bandwidth. # 9. Countermeasures # If a resolver sends out multiple equivalent questions to any # authoritative server, before receiving an answer, all MUST have # identical ID, source address and source port. Not a MUST, when I wrote some probing software I purposefully altered the ID so that I could detect which query (1st, 2nd, Nth) was being answered. # Resolvers SHOULD favour authoritative nameservers with which a trust # relation has been established; Stub-resolvers SHOULD be able to use # TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their # recursive resolver. Or SIG(0) or some other message authentication method or point-to-point links or other security precautions taken on the LAN or ... i.e., an open ended list of mechanisms are available and in use. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Mail archives, backups. Sometimes I think the true beneficiaries of standards work are the suppliers of disk drives. -- to unsubscribe send a message to namedroppers-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 Mar 11 09:03:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B4A3A6B03; Tue, 11 Mar 2008 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg4FQsfw4btj; Tue, 11 Mar 2008 09:02:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAA193A6AF9; Tue, 11 Mar 2008 09:02:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ6oK-000L19-QF for namedroppers-data@psg.com; Tue, 11 Mar 2008 15:54:40 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ6oD-000Kwc-45 for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 15:54:37 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id AEC78C2DA7; Tue, 11 Mar 2008 15:54:31 +0000 (GMT) Date: Tue, 11 Mar 2008 15:54:29 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , namedroppers@ops.ietf.org cc: ed.lewis@neustar.biz, Alex Bligh Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt Message-ID: In-Reply-To: References: <20080218210001.AB0E13A6876@core3.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --On 11 March 2008 10:55:55 -0400 Edward Lewis wrote: ># 5. It is the first answer to match the previous four conditions. > > I"m not sure if this is a statement of historic fact, current recommended > behavior, or a proposed set of rules. So my comments might just slide > off the table. > > I think #1 isn't a "given" rule, as there is another proto-draft > distributed to try to make it so. > > I disagree with #5. In one scenario, the "last" answer to match is the > best - that is, if the true responder is "further away" than the source > of a stuffed answer. (Such as a DNS spoofer on the same wireless LAN the > client is on.) > > All in all, there's no hard and fast rule about whether it is the "first" > or "last" that is most credible or trustworthy. As DNS resolvers are not yet clairvoyant, they have no way of knowing whether additional answers will arrive after the one they have received. Unless the resolver waits under all circumstances for further answers (with some timeout) and uses some heuristic to determine which will be valid, or waits under certain circumstances, they default is as by logically elimination the one described above. If you are suggesting allowing the possibility of waiting, how about "No answer has arrived before this one which as met the four conditions and has been accepted by the resolver" (as 'accepted' appears to mean 'has been treated as valid). This leaves the possibility open to the resolver to 'not make a decision' whilst it waits or gathers further information. ># 5. Birthday attacks ># ># The so called birthday paradox means that a group of 22 people ># suffices to have a more than even chance of having two or more ># members of the group share a birthday. > > Such a statement of fact should be supported by a reference to a proof, > or include a proof. > > Doesn't the number 22 have to do with the fact that there are just 366 > possible dates? I think it's actually 23, and is normally calculated on a 365 day year. If this is really necessary, how about adding: "This is a special case of a collision problem: where x independent random variables each have having n possible values, the probability of all such variables having distinct values is: / 0 (where x>n) | p(n,x) =| n! | 1 - ---------- (where x<=n) | x \ n . (n-x)! For large n,x this approximates to a normal distribution, i.e. 2 - x / (2.n) p(n,x) ~= 1 - e Therefore, to avoid a collision with probability p, using the above approximation, the number of variables x must be such that __________________ / ( 1 ) x < / 2 . n . ln ( --- ) V ( 1-p ) In this case p is the acceptable probability of a collision, and n the number of possible tuples making the query distinct and undiscoverable by the attacker." I suspect however, that this is not necessary. Alex -- to unsubscribe send a message to namedroppers-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 Mar 11 09:20:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627483A6E58; Tue, 11 Mar 2008 09:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DSL=1.129, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1Ff4pzHWHov; Tue, 11 Mar 2008 09:19:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D6173A6946; Tue, 11 Mar 2008 09:19:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ72h-000Ogd-D6 for namedroppers-data@psg.com; Tue, 11 Mar 2008 16:09:31 +0000 Received: from [216.194.124.237] (helo=execdsl.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ72O-000OeC-RB for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 16:09:17 +0000 Received: from [66.92.164.104] (HELO [192.168.168.16]) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 16405163; Tue, 11 Mar 2008 09:07:30 -0700 In-Reply-To: References: <20080218210001.AB0E13A6876@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67A3E592-46CE-4EED-B8A1-33877C567941@shinkuro.com> Cc: Steve Crocker , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Steve Crocker Subject: birthday attacks Date: Tue, 11 Mar 2008 12:09:10 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.753) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I'm not entirely sure why there's a discussion of birthday attacks because I haven't been following this thread closely, but I can clarify the math on birthday attacks. See below. On Mar 11, 2008, at 10:55 AM, Edward Lewis wrote: > > > # 5. Birthday attacks > # > # The so called birthday paradox means that a group of 22 people > # suffices to have a more than even chance of having two or more > # members of the group share a birthday. > > Such a statement of fact should be supported by a reference to a > proof, or include a proof. > > Doesn't the number 22 have to do with the fact that there are just > 366 possible dates? As noted, a randomly selected group of about 23 people there's a 50% probability that two or more people will share the same birthday (month and year). The number does indeed depend on the number of possibilities. For a group of k people, the probability of no duplication is P(k) = (366 - 0)/366 * (366 - 1)/366 * (366 - 2)/366 ... (366 - k +1)/ 366 When k is 23, the probability crosses below the 50% mark. (This assumes all dates are equally probable. Feb 29 is not equally probable, so this shifts the probabilities slightly.) One application of the birthday problem which is very important is the potential for collision of hashes. The SHA-1 hash is 160 bits, which means the population is 2^160, or about 1.46*10^48. This is obviously a much bigger number than 366, and the method of calculating the 50% probability point shown above isn't practical. With a little bit of math -- available in suitable textbooks or on request -- there is an excellent approximation. The 50% balance point is approx 1.17 * sqrt(N). The sqrt term has the effect of cutting the number of bits in half, so for SHA-1, when there is a total of roughly 2^80 messages, there will be approximately a 50% probability that two more messages will have the same hash. Repeating the caveat, this calculation depends on uniform probabilities. If the probabilities are skewed, the number needed for possible clash drops. Steve -- to unsubscribe send a message to namedroppers-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 Mar 11 09:25:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2FE3A6E38; Tue, 11 Mar 2008 09:25: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 u9nm4Hpoc1n8; Tue, 11 Mar 2008 09:24:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65B023A6A43; Tue, 11 Mar 2008 09:24:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ7C2-0000Ls-Cw for namedroppers-data@psg.com; Tue, 11 Mar 2008 16:19:10 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ7Bv-0000Kj-3q for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 16:19:04 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id D2AC6C2DA5; Tue, 11 Mar 2008 16:18:59 +0000 (GMT) Date: Tue, 11 Mar 2008 16:18:56 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , Edward Lewis , namedroppers@ops.ietf.org cc: ed.lewis@neustar.biz, Alex Bligh Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt Message-ID: <3CEA3F17F699082956CA6AB7@Ximines.local> In-Reply-To: References: <20080218210001.AB0E13A6876@core3.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --On 11 March 2008 15:54:29 +0000 Alex Bligh wrote: > "This is a special case of a collision problem: where x independent random > variables each have having n possible values Not clear enough: try "where x independent random variables in a discrete uniform distribution each having n possible values". Alex -- to unsubscribe send a message to namedroppers-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 Mar 11 10:03:23 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5C53A69DB; Tue, 11 Mar 2008 10:03: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 yw7cmS3rhifv; Tue, 11 Mar 2008 10:03:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E39703A6D19; Tue, 11 Mar 2008 10:03:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ7m8-0008ps-Fw for namedroppers-data@psg.com; Tue, 11 Mar 2008 16:56:28 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ7m4-0008p3-UB for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 16:56:26 +0000 Received: from [130.129.23.164] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2BGu1NL076925; Tue, 11 Mar 2008 12:56:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080218210001.AB0E13A6876@core3.amsl.com> Date: Tue, 11 Mar 2008 12:52:45 -0400 To: Alex Bligh From: Edward Lewis Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 15:54 +0000 3/11/08, Alex Bligh wrote: >As DNS resolvers are not yet clairvoyant, they have no way of knowing >whether additional answers will arrive after the one they have received. >Unless the resolver waits under all circumstances for further answers >(with some timeout) and uses some heuristic to determine which will >be valid, or waits under certain circumstances, Exactly... >the(y) default is as >by logically elimination the one described above. Which I claim is an implementer taking the easy way out. >If you are suggesting allowing the possibility of waiting, how about >"No answer has arrived before this one which as met the four conditions >and has been accepted by the resolver" (as 'accepted' appears to mean >'has been treated as valid). This leaves the possibility open to the >resolver to 'not make a decision' whilst it waits or gathers further >information. It's like this, once you get a good answer, you are done. When you get an answer that proves to be bad, instead of declaring defeat, see if another has fallen into the in basket. You "destroy" the in-basket when you have a success or you give up (=hit the timeout). If you destroy the in-basket without getting a good answer, you declare defeat. (Regarding the birthday attack comment) >I suspect however, that this is not necessary. My first suggestion is to include a reference that covers what it is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with success. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 11 10:44:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729603A6A94; Tue, 11 Mar 2008 10:44: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 go8ES8ws0S4O; Tue, 11 Mar 2008 10:44:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FC783A6D61; Tue, 11 Mar 2008 10:44:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ8Nu-000HCb-3W for namedroppers-data@psg.com; Tue, 11 Mar 2008 17:35:30 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ8Nq-000HBn-OG for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 17:35:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5D83B11434 for ; Tue, 11 Mar 2008 17:35:26 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 11 Mar 2008 17:35:26 +0000 Message-ID: <57450.1205256926@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion i said in the dnsext meeting just now that we should delay wglc on dns-forgery-resilience until dns-0x20 can join it, be referenced by it, and the two progress together. furthermore: isc also has a proposed addition to dns-forgery-resilience, having to do with rtt banding and/or other forms of authority server mixing. i'd like to see this proposed and discussed during the delay while waiting for dns-0x20 to catch up. to wit: the tuple used to match non-servfail responses to outstanding requests includes query id, authority server address, question name, question type, and question class. 0x20 is a way to improve the question name's uniqueness. dan bernstein already showed us how to improve the query id's uniqueness. question class and type aren't subject to this improvement. but, authority server address uniqueness can be improved. i would like dns-forgery-resilience to show all possible improvements to the uniqueness of this tuple. more from: joao, jinmei, explorer, and marka were last seen talking about rtt banding; i propose that one of them follow up this message with "isc's" current thoughts on the topic of improving authority server address uniqueness. -- to unsubscribe send a message to namedroppers-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 Mar 11 12:00:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8911128C39B; Tue, 11 Mar 2008 12:00:03 -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=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-K9gj+cDjIr; Tue, 11 Mar 2008 11:59:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 916B03A6D47; Tue, 11 Mar 2008 11:59:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ9Zo-00085K-TH for namedroppers-data@psg.com; Tue, 11 Mar 2008 18:51:52 +0000 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZ9Yp-0007rR-IK for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 18:51:23 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id znEd1Y0020FhH24A60Zg00; Tue, 11 Mar 2008 18:50:09 +0000 Received: from MIKES-LAPTOM.comcast.net ([130.129.82.1]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id zuqf1Y00X01iiJi8U00000; Tue, 11 Mar 2008 18:50:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=Nr2l7gmHL8wA:10 a=2p8ekNPvueS4Eo4-NFgA:9 a=NOr_0gWuX7QZ5tFmpxMENl9hVN0A:4 a=K6OZBpTtl3cA:10 a=Y6qChIQXU1wA:10 a=eZLSmJVMEtUA:10 a=PFeSso3lQp6kZMDtttEA:9 a=G9Ozy4BxAfLylzWdjCB6mI96SxkA:4 a=37WNUvjkh6kA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Mar 2008 14:50:41 -0400 To: namedroppers@ops.ietf.org From: Michael StJohns Subject: CD bit setting from intermediate resolvers... Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_420037406==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: --=====================_420037406==.ALT Content-Type: text/plain; charset="us-ascii" Restarting the discussion post the DNSEXT meeting in Philadelphia: 4035 Doesn't explicitly state the CD bit must be set on upstream queries from an intermediate resolver if the CD bit is set in the client query. (The language is ambiguous, but seems to just require the resolver side of the intermediate server pass the records it has without checking). My first suggestion was that the intermediate resolver ALWAYS set the CD bit on output but after more thought I posted the following: The text from my last note on this topic dated 19 Nov 2007 "OK - thinking about it, I think its even more complex than this. I think the CD bit gets set in only those upstream queries where the resolver has a configured trust anchor superior to the query. (.e.g .COM for queries to sub1.example.com) Let's say your local validating resolver has a trust anchor for "example.com" but not ".com" Let's say the next upstream resolver has a trust anchor for .com. If the local resolver sets the CD bit on queries in foo.com the client could get data in foo.com even if the data were invalid at the upstream resolver even though the upstream resolver should have protected the local resolver." I think the final language is something like: "Set the CD bit on output if you got the CD bit on input. If the CD bit is NOT set on input, set it on output if and only if this intermediate resolver has a trust anchor covering this query." AND "An intermediate resolver MUST generate an upstream query for any received query where the query has the CD bit set IF there is cached data for the query (or its supporting data - e.g. NS, RRSIG, DNSKEY) and that data was not the result of a previous CD-bit set query." There may also be some interactions with DLV and DLV anchors - but figuring out those hurts my head. Mike --=====================_420037406==.ALT Content-Type: text/html; charset="us-ascii" Restarting the discussion post the DNSEXT meeting in Philadelphia:

4035 Doesn't explicitly state the CD bit must be set on upstream queries from an intermediate resolver if the CD bit is set in the client query.  (The language is ambiguous, but seems to just require the resolver side of the intermediate server pass the records it has without checking).

My first suggestion was that the intermediate resolver ALWAYS set the CD bit on output but after more thought I posted the following:

The text from my last note on this topic dated 19 Nov 2007


"OK - thinking about it, I think its even more complex than
this.  I think the CD bit gets set in only those upstream queries
where the resolver has a configured trust anchor superior to the
query.  (.e.g .COM for queries to sub1.example.com)

Let's say your local validating resolver has a trust anchor for
"example.com" but not ".com"  Let's say the next
upstream resolver has a trust anchor for .com.   If the local
resolver sets the CD bit on queries in foo.com the client could get data
in foo.com even if the data were invalid at the upstream resolver even
though the upstream resolver should have protected the local
resolver."
I think the final language is something like:

"Set the CD bit on output if you got the CD bit on input.
If the CD bit is NOT set on input, set it on output if and only if this intermediate resolver has a trust anchor covering this query."

AND

"An intermediate resolver MUST generate an upstream query for any received query where the query  has the CD bit set IF there is cached data  for the query (or its supporting data - e.g. NS, RRSIG, DNSKEY) and that data was not the result of a previous CD-bit set query."



There may also be some interactions with DLV and DLV anchors - but figuring out those hurts my head.

Mike
--=====================_420037406==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 12:34:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180373A69DB; Tue, 11 Mar 2008 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkAB4zn2A0ax; Tue, 11 Mar 2008 12:33:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 225043A6827; Tue, 11 Mar 2008 12:33:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZA4v-000EuQ-B3 for namedroppers-data@psg.com; Tue, 11 Mar 2008 19:24:01 +0000 Received: from [85.17.178.135] (helo=spalding.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZA4S-000Epd-Il for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 19:23:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spalding.dds.nl (Postfix) with ESMTP id 25D966280F9 for ; Tue, 11 Mar 2008 20:23:31 +0100 (CET) Received: from spalding.dds.nl ([127.0.0.1]) by localhost (spalding.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26242-03 for ; Tue, 11 Mar 2008 20:23:25 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spalding.dds.nl (Postfix) with ESMTP id D1C406280EF for ; Tue, 11 Mar 2008 20:23:22 +0100 (CET) Message-ID: <47D6DC2A.3080105@nlnetlabs.nl> Date: Tue, 11 Mar 2008 20:23:22 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Namedroppers Subject: dnssec-bis item, include SOA X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/6201/Tue Mar 11 17:44:55 2008 on spalding.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There was confusion during DNSEXT about what I proposed. And what the trouble is. As Mark said, the trouble is some replies can be ambiguous. I have not seen this in practice, but stumbled on it while implementing a validator. Very much in the spirit of RFC2308. But RFC2308 does not include DNSSEC of course. The presence of NSEC/NSEC3 records in the authority section does not relieve the replier of the obligation to include a SOA record for the receiver to determine the proper negative response type. The NSEC/NSEC3 records only provide authentication. All major implementations (esp DNSSEC aware) perform brilliantly on this, as far as I know, I only thought that it could be documented more clearly. Hence the dnssec-bis suggestion. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH1twqkDLqNwOhpPgRAsbRAJ4w8OHp+6Ys7ud35BDDJlH/jJ5N+ACfd4QC J3vL1Cs69gdSK+77BEeS9yQ= =QuK5 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 12:48:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8588F3A68AD; Tue, 11 Mar 2008 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 ln30hxthR0Jo; Tue, 11 Mar 2008 12:48:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0B8C3A6C07; Tue, 11 Mar 2008 12:48:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZAHi-000HoQ-Gr for namedroppers-data@psg.com; Tue, 11 Mar 2008 19:37:14 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZAHI-000Hk5-RF for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 19:36:52 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 4AA15327A78 for ; Tue, 11 Mar 2008 12:36:48 -0700 (PDT) Received: from dhcp-13bb.ietf71.ietf.org (dhcp-13bb.ietf71.ietf.org [130.129.19.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id C6762327A5A for ; Tue, 11 Mar 2008 12:36:47 -0700 (PDT) From: Michael Graff To: namedroppers@ops.ietf.org Subject: Comments on dns-cookies draft vs. amplification attacks Date: Tue, 11 Mar 2008 09:36:42 -0500 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803110936.42523.michael_graff@isc.org> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion My comments are with section 2.1 of the rev 3 draft. I like the cookies in the resolver-created queries, and their echo in the auth server-created responses. This allows a resolver to add as many entropy bits to the query id as desired to protect from out-of-band attacks. However, I disagree that having the auth server check and maintain state about known resolvers is of practical use. The reason it is there from discussion with Donald Eastlake was that it would prevent DDoS attacks where auth servers are used as amplification attacks. I do not believe the added complexity warrants this, as it is not, IMHO, effective. It will protect resolvers from DDoS attacks of the amplification variety, but it will not protect (say) www.google.com, which is unlikely to send queries to auth servers, and therefore will never have negotiated a cookie with an auth server. Thus, unless auth servers refuse to answer clients without a valid cookie, meaning people have fully and universally implemented dns-cookies, only recursive resolvers are actually protected from flood attacks. If dns-cookies were to move forward, I'd rather see it as a "edns0 echo" and make it purely client-driven, and have the server simply reply with whatever the client included. The complexity of how this value is generated on the client, how the server maintains this state, etc. should all be removed, and only a maximum length be recommended. --Michael -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 16:58:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDB03A6882; Tue, 11 Mar 2008 16:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4e4teALiQec; Tue, 11 Mar 2008 16:58:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A58728C1F4; Tue, 11 Mar 2008 16:57:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZEAe-000HhO-6Q for namedroppers-data@psg.com; Tue, 11 Mar 2008 23:46:12 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZEAW-000HfY-7v for namedroppers@ops.ietf.org; Tue, 11 Mar 2008 23:46:10 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JZEAQ-0002Tb-Pe; Wed, 12 Mar 2008 00:45:58 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id DE17740DE; Wed, 12 Mar 2008 00:46:03 +0100 (CET) Date: Wed, 12 Mar 2008 00:46:03 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Message-ID: <20080311234603.GB4562@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57450.1205256926@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Tue, Mar 11, 2008 at 05:35:26PM +0000, Paul Vixie wrote: > i said in the dnsext meeting just now that we should delay wglc on > dns-forgery-resilience until dns-0x20 can join it, be referenced by > it, and the two progress together. I appreciate this effort, but I'm also sceptical enough to think it would be wise to release forgery-resilience first, and have 0x20 update is. I've seen the amount of resistance forgery-resilience has caused in some circles, I think it should stand on its own. This is not to say I'm against 0x20, btw - it looks promising. But from a practical standpoint, I'd prefer to have forgery-resilience passed, and have 0x20 be an update to it (in addition to specifying 0x20 of course). I refer the esteemed workgroup participants to rfc 1925, paragraph 2, sub 5 - even though it doesn't strictly apply. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 20:22:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA0028C494; Tue, 11 Mar 2008 20:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MLHGHL-SCbX; Tue, 11 Mar 2008 20:22:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AE4D3A6897; Tue, 11 Mar 2008 20:22:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZHOt-0007qE-Fd for namedroppers-data@psg.com; Wed, 12 Mar 2008 03:13:07 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZHOq-0007pG-Cq for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 03:13:06 +0000 Received: from [10.150.132.56] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2C3Cppb084177; Tue, 11 Mar 2008 23:12:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <69903.1204047792@sa.vix.com> References: <69903.1204047792@sa.vix.com> Date: Tue, 11 Mar 2008 23:12:44 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: dns-0x20.txt Cc: namedroppers@ops.ietf.org, dagon@cc.gatech.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion An off-hand comment, this doesn't do a whole lot for the reverse map. (Unless I am missing something.) It doesn't hurt though. Probably a mention in the security section on that topic. At 17:43 +0000 2/26/08, Paul Vixie wrote: >i think i've missed the cutoff for new -00 drafts, but, this is topical and >i'd like to discuss it anyway, even if it can't be on the philly agenda. > > Abstract > > The small (16-bit) size of the DNS transaction ID has made it a > frequent target for forgery, with the unhappy result of many cache > pollution events throughout Internet history. Even with perfectly > and unpredictably random transaction ID's, random and birthday > attacks are still theoretically feasible. This document describes a > method by which an initiator can improve transaction identity using > the 0x20 bit in DNS labels. The method described here has already > been implemented, and is running in production. > >for more, go to . > > >-- >to 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 +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 11 20:43:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EB128C4B5; Tue, 11 Mar 2008 20:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNfNUtuIdVi1; Tue, 11 Mar 2008 20:43:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 708EC28C493; Tue, 11 Mar 2008 20:42:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZHi3-000BQB-1h for namedroppers-data@psg.com; Wed, 12 Mar 2008 03:32:55 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZHhz-000BPT-Aa for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 03:32:53 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2C3WlBU084335 for ; Tue, 11 Mar 2008 23:32:47 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200803120332.m2C3WlBU084335@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Mar 2008 23:31:54 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNS is mandatory text Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion During the namedroppers meeting I made the proposal that the current ENDS0bis draft include words that made EDNS0 mandatory. The sense of the room was that this was reasonable, even though it will cause some problems. I (personally) have the feeling this is a question of short intense pain vs long dull pain. So I propose that the next version of EDNS0bis contain something like: (feel free to word smith) ENDS is required ENDS was specified in 1999 been on the wire since then, with minimal adverse effects. As number of uses of DNS require larger answers than can be easily fit in 512 byte answers, it makes sense to require modern DNS software to implement EDNS0. Thus Authorative servers, Recursive Resolvers, Stub-resolver and middle-ware boxes speaking DNS in any form MUST implement ENDS0 and MUST support buffer size of at least 2K. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 20:49:46 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14CD3A67AB; Tue, 11 Mar 2008 20:49: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 dg6almg-1Z91; Tue, 11 Mar 2008 20:49:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C16B628C3C2; Tue, 11 Mar 2008 20:49:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZHrL-000DIZ-N8 for namedroppers-data@psg.com; Wed, 12 Mar 2008 03:42:31 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZHrI-000DHw-Cr for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 03:42:30 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2C3gJCj006008; Wed, 12 Mar 2008 05:42:19 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2C3gJa7006004; Wed, 12 Mar 2008 05:42:19 +0200 Date: Wed, 12 Mar 2008 05:42:18 +0200 (EET) From: Pekka Savola To: bert hubert cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: <20080311234603.GB4562@outpost.ds9a.nl> Message-ID: References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 22:43:31 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, 12 Mar 2008, bert hubert wrote: > I appreciate this effort, but I'm also sceptical enough to think it would be > wise to release forgery-resilience first, and have 0x20 update is. > > I've seen the amount of resistance forgery-resilience has caused in some > circles, I think it should stand on its own. The usual time the IETF seems to need to iron out most glaring specification issues and wear down any resistance is 2-3years (+- 1 year). There was already some resistance and/or skepticisim at the meeting, so a timeline like this (unless author was very active in building a strong consensus behind the document) seems realistic. I agree it's better to ship forgery-resilience now and having 0x20 update it later, if necessary, seems like the right thing to do. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 Mar 11 21:13:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499823A6823; Tue, 11 Mar 2008 21:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq+EG1gPs1PM; Tue, 11 Mar 2008 21:13:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6195F3A67AB; Tue, 11 Mar 2008 21:13:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZIDD-000Hat-Kj for namedroppers-data@psg.com; Wed, 12 Mar 2008 04:05:07 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZIDA-000HaL-Qz for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 04:05:06 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2C44rIc084647; Wed, 12 Mar 2008 00:04:54 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200803120404.m2C44rIc084647@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Mar 2008 00:04:01 -0400 To: Edward Lewis , Paul Vixie From: Olafur Gudmundsson Subject: Re: dns-0x20.txt Cc: namedroppers@ops.ietf.org, dagon@cc.gatech.edu In-Reply-To: References: <69903.1204047792@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion You get 7 (ip6.arpa) or 10 (in-addr.arpa) bits which is more than irs.gov (6) gets :-) Olafur At 23:12 11/03/2008, Edward Lewis wrote: >An off-hand comment, this doesn't do a whole lot for the reverse >map. (Unless I am missing something.) It doesn't hurt >though. Probably a mention in the security section on that topic. > > >At 17:43 +0000 2/26/08, Paul Vixie wrote: >>i think i've missed the cutoff for new -00 drafts, but, this is topical and >>i'd like to discuss it anyway, even if it can't be on the philly agenda. >> >> Abstract >> >> The small (16-bit) size of the DNS transaction ID has made it a >> frequent target for forgery, with the unhappy result of many cache >> pollution events throughout Internet history. Even with perfectly >> and unpredictably random transaction ID's, random and birthday >> attacks are still theoretically feasible. This document describes a >> method by which an initiator can improve transaction identity using >> the 0x20 bit in DNS labels. The method described here has already >> been implemented, and is running in production. >> >>for more, go to . >> >> >>-- >>to 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 +1-571-434-5468 >NeuStar > >Never confuse activity with progress. Activity pays more. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 04:27:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9BD3A6E01; Wed, 12 Mar 2008 04:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHAToN8Gx5Xt; Wed, 12 Mar 2008 04:27:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24C2328C651; Wed, 12 Mar 2008 04:27:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZOvU-000DCO-4f for namedroppers-data@psg.com; Wed, 12 Mar 2008 11:15:16 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZOvH-000D9b-PD for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 11:15:05 +0000 Received: from [10.150.134.156] (72-255-22-99.client.stsn.net [72.255.22.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id 639471367A7; Wed, 12 Mar 2008 07:15:01 -0400 (EDT) Cc: Edward Lewis , Paul Vixie , namedroppers@ops.ietf.org, dagon@cc.gatech.edu Message-Id: <3AC42AB6-9A5C-4D36-810B-4EE6D566D257@verisign.com> From: "Blacka, David" To: Olafur Gudmundsson In-Reply-To: <200803120404.m2C44rIc084647@ogud.com> Content-Type: multipart/signed; boundary=Apple-Mail-2--619965873; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: dns-0x20.txt Date: Wed, 12 Mar 2008 07:15:00 -0400 References: <69903.1204047792@sa.vix.com> <200803120404.m2C44rIc084647@ogud.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Apple-Mail-2--619965873 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 12, 2008, at 12:04 AM, Olafur Gudmundsson wrote: > You get 7 (ip6.arpa) or 10 (in-addr.arpa) bits > which is more than irs.gov (6) gets :-) I count 6 bits in ip6.arpa, unless you've figured out how to capitalize '6' ;-) > At 23:12 11/03/2008, Edward Lewis wrote: >> An off-hand comment, this doesn't do a whole lot for the reverse >> map. (Unless I am missing something.) It doesn't hurt though. >> Probably a mention in the security section on that topic. >> -- David Blacka Sr. Engineer VeriSign Infrastructure Product Engineering --Apple-Mail-2--619965873 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILiDCCA6Yw ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb if1JwnUEA5el1JaB2CNB8DCCBBYwggN/oAMCAQICECsUEtKYtH+GOnwD9TrUy/0wDQYJKoZIhvcN AQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt cGxveWVlIENBMB4XDTA3MDMyODAwMDAwMFoXDTA4MDMyNzIzNTk1OVowajERMA8GA1UEChMIVkVS SVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRh dmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOdIMJv8eXZfXcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w6/WlLoR4I2jd8Qa2C9+G8wjf LV3BX8HqZ/TQP8TQHP16HxOc46930G+izuJJ+K80R7ANcGC3ccU4sM4KNWGAM9vzdnnkRGrOJdt+ X4JNmoTLw0lCh7SKUtHJjO/a2C6VAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAw TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VF bXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJ bmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4g KGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wVylpyf5iqU+snpdgvGq1S C/ORihQmXlcTppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdODnoJYYBFkpVi86ai43AAsJ2GQ 7Snqs0DmvzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135KCB/JxDGCA3UwggNxAgEBMIHBMIGs MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBD QQIQKxQS0pi0f4Y6fAP1OtTL/TAJBgUrDgMCGgUAoIICCTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODAzMTIxMTE1MDFaMCMGCSqGSIb3DQEJBDEWBBT4XoS0bJh9 +tV4/LQ1oJjIPl3RmjCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJt cyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJp U2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhArFBLSmLR/hjp8A/U61Mv9MA0GCSqGSIb3DQEBAQUA BIGALGgeKzet4QhvWcqqYimCBZw1hUzvv/OWPQdBfLw8jD1rsExWbGCftC1ucjcOTvYrYuSIF0O5 +sjkULbWHmie6ZQyxL9GljljqP/SPASFy8YBWu0MqQE9ygwk6C4b3DMkHtAqKWXT+g4axMKHcIar 1Rhe+76Jxz75bEbw9fafcb0AAAAAAAA= --Apple-Mail-2--619965873-- -- to unsubscribe send a message to namedroppers-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 Mar 12 04:34:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D61028C5EE; Wed, 12 Mar 2008 04:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=1.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 Ih6vY8Sa-Zyd; Wed, 12 Mar 2008 04:34:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9746428C5F9; Wed, 12 Mar 2008 04:34:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZP5F-000FWH-1v for namedroppers-data@psg.com; Wed, 12 Mar 2008 11:25:21 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZP4U-000FJy-U6 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 11:24:49 +0000 Received: from [10.150.133.79] (72-255-97-193.client.stsn.net [72.255.97.193]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2CBOGOW019678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2008 12:24:18 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Cc: bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: From: Olaf Kolkman To: Pekka Savola In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-37--619416095" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Date: Wed, 12 Mar 2008 07:24:10 -0400 References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.919.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 12 Mar 2008 12:24:19 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-37--619416095 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 11, 2008, at 11:42 PM, Pekka Savola wrote: > > The usual time the IETF seems to need to iron out most glaring > specification issues and wear down any resistance is 2-3years (+- 1 > year). But there are success stories of specifications that went from I-D to RFC in less time than a year. This is a simple specification. Folk have been reviewing and implementing it. If the IETF needs 2-3 years to process a specification like 0x20 than... sigh... As far as I understand there are some technical open issues but not much, it should be easy to iron those out. I would expect that a next revision is in such a state that it can be last called. This would involve some pressure from the editor and some pressure from the chair. It could well be that 0x20 will not reach consensus because people will never appreciate the beauty of its ugliness (Anybody saw the Marcel Duchamp gallery in the Museum yesterday?) but that is something that can be determined in less than 2-3 years. I think it would be good if the docs where merged but my strategy would be to last call the docs separately so that once it is clear they are both mature do the merging. --Olaf --Apple-Mail-37--619416095 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) Comment: This message is locally signed. iEYEARECAAYFAkfXvVoACgkQtN/ca3YJIocU3QCg53851g3ARf72nsrtX5k+72tr r2YAn2HdRrSlQTUUmdyaC1pWprXgRddL =j2qp -----END PGP SIGNATURE----- --Apple-Mail-37--619416095-- -- to unsubscribe send a message to namedroppers-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 Mar 12 05:00:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4103F28C634; Wed, 12 Mar 2008 05:00:19 -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 TtupjvHlAP+a; Wed, 12 Mar 2008 05:00:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4833B28C652; Wed, 12 Mar 2008 05:00:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZPRW-000Kmp-MI for namedroppers-data@psg.com; Wed, 12 Mar 2008 11:48:22 +0000 Received: from [199.6.1.65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZPRF-000KfD-5u for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 11:48:08 +0000 Received: from farside.isc.org (farside.isc.org [204.152.187.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id CB1BD4AC29 for ; Wed, 12 Mar 2008 11:47:26 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id D7799E60AA for ; Wed, 12 Mar 2008 11:46: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.2/8.14.1) with ESMTP id m2CBjvvR041985; Wed, 12 Mar 2008 22:45:57 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803121145.m2CBjvvR041985@drugs.dv.isc.org> To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org, dagon@cc.gatech.edu From: Mark Andrews Subject: Re: dns-0x20.txt In-reply-to: Your message of "Tue, 11 Mar 2008 23:12:44 EDT." Date: Wed, 12 Mar 2008 22:45:57 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > An off-hand comment, this doesn't do a whole lot for the reverse map. > (Unless I am missing something.) It doesn't hurt though. Probably a > mention in the security section on that topic. Which reverse map? It helps in ip6.arpa. Just another reason to go to IPv6. :-) Mark > At 17:43 +0000 2/26/08, Paul Vixie wrote: > >i think i've missed the cutoff for new -00 drafts, but, this is topical and > >i'd like to discuss it anyway, even if it can't be on the philly agenda. > > > > Abstract > > > > The small (16-bit) size of the DNS transaction ID has made it a > > frequent target for forgery, with the unhappy result of many cache > > pollution events throughout Internet history. Even with perfectly > > and unpredictably random transaction ID's, random and birthday > > attacks are still theoretically feasible. This document describes a > > method by which an initiator can improve transaction identity using > > the 0x20 bit in DNS labels. The method described here has already > > been implemented, and is running in production. > > > >for more, go to . > > > > > >-- > >to 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 +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > -- > to 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: Mark_Andrews@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 Mar 12 05:15:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC1D28C65E; Wed, 12 Mar 2008 05:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Nzx0Nk1eaKI; Wed, 12 Mar 2008 05:15:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FD9228C665; Wed, 12 Mar 2008 05:15:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZPk1-000PIB-1g for namedroppers-data@psg.com; Wed, 12 Mar 2008 12:07:29 +0000 Received: from [199.6.1.65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZPjM-000P91-9s for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 12:07:08 +0000 Received: from farside.isc.org (farside.isc.org [204.152.187.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id DD0F24AC29 for ; Wed, 12 Mar 2008 12:05:26 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id A47BAE60AD for ; Wed, 12 Mar 2008 12:04: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.2/8.14.1) with ESMTP id m2CC3vEK042459; Wed, 12 Mar 2008 23:03:57 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803121203.m2CC3vEK042459@drugs.dv.isc.org> To: "Blacka, David" Cc: Olafur Gudmundsson , Edward Lewis , Paul Vixie , namedroppers@ops.ietf.org, dagon@cc.gatech.edu From: Mark Andrews Subject: Re: dns-0x20.txt In-reply-to: Your message of "Wed, 12 Mar 2008 07:15:00 EDT." <3AC42AB6-9A5C-4D36-810B-4EE6D566D257@verisign.com> Date: Wed, 12 Mar 2008 23:03:57 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > --Apple-Mail-2--619965873 > Content-Type: text/plain; > charset=US-ASCII; > format=flowed; > delsp=yes > Content-Transfer-Encoding: 7bit > > > On Mar 12, 2008, at 12:04 AM, Olafur Gudmundsson wrote: > > > You get 7 (ip6.arpa) or 10 (in-addr.arpa) bits > > which is more than irs.gov (6) gets :-) > > I count 6 bits in ip6.arpa, unless you've figured out how to > capitalize '6' ;-) But you will almost certainly get some extra bits in the nibbles. 2001:df8:0:112:216:6fff:fe46:b75d 6+9 for my address here. Assuming a uniform distribution you would get 6+19 bits. Mark > > At 23:12 11/03/2008, Edward Lewis wrote: > >> An off-hand comment, this doesn't do a whole lot for the reverse > >> map. (Unless I am missing something.) It doesn't hurt though. > >> Probably a mention in the security section on that topic. > >> > > -- > David Blacka > Sr. Engineer VeriSign Infrastructure Product Engineering > > > --Apple-Mail-2--619965873 > Content-Disposition: attachment; > filename=smime.p7s > Content-Type: application/pkcs7-signature; > name=smime.p7s > Content-Transfer-Encoding: base64 > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILiDCCA6Yw > ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT > MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy > eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln > biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz > dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl > cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV > c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty > IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG > 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 > wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 > JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE > BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF > AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt > MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB > BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL > Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH > bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq > hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu > IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz > Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz > IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV > BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD > VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v > cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G > CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z > OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP > hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi > MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD > VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG > CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG > J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB > gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o > Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb > if1JwnUEA5el1JaB2CNB8DCCBBYwggN/oAMCAQICECsUEtKYtH+GOnwD9TrUy/0wDQYJKoZIhvcN > AQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz > dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 > dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt > cGxveWVlIENBMB4XDTA3MDMyODAwMDAwMFoXDTA4MDMyNzIzNTk1OVowajERMA8GA1UEChMIVkVS > SVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRh > dmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0A > MIGJAoGBAOdIMJv8eXZfXcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w6/WlLoR4I2jd8Qa2C9+G8wjf > LV3BX8HqZ/TQP8TQHP16HxOc46930G+izuJJ+K80R7ANcGC3ccU4sM4KNWGAM9vzdnnkRGrOJdt+ > X4JNmoTLw0lCh7SKUtHJjO/a2C6VAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAw > TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VF > bXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl > cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYc > aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJ > bmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4g > KGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr > BgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wVylpyf5iqU+snpdgvGq1S > C/ORihQmXlcTppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdODnoJYYBFkpVi86ai43AAsJ2GQ > 7Snqs0DmvzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135KCB/JxDGCA3UwggNxAgEBMIHBMIGs > MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y > azFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp > Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBD > QQIQKxQS0pi0f4Y6fAP1OtTL/TAJBgUrDgMCGgUAoIICCTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN > AQcBMBwGCSqGSIb3DQEJBTEPFw0wODAzMTIxMTE1MDFaMCMGCSqGSIb3DQEJBDEWBBT4XoS0bJh9 > +tV4/LQ1oJjIPl3RmjCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg > SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 > YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl > MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TCB > 1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL > ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJt > cyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJp > U2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhArFBLSmLR/hjp8A/U61Mv9MA0GCSqGSIb3DQEBAQUA > BIGALGgeKzet4QhvWcqqYimCBZw1hUzvv/OWPQdBfLw8jD1rsExWbGCftC1ucjcOTvYrYuSIF0O5 > +sjkULbWHmie6ZQyxL9GljljqP/SPASFy8YBWu0MqQE9ygwk6C4b3DMkHtAqKWXT+g4axMKHcIar > 1Rhe+76Jxz75bEbw9fafcb0AAAAAAAA= > > --Apple-Mail-2--619965873-- > > -- > to 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: Mark_Andrews@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 jobs@hathway.net Wed Mar 12 05:21:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382FD28C671 for ; Wed, 12 Mar 2008 05:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc+QIVxQIPxr for ; Wed, 12 Mar 2008 05:21:19 -0700 (PDT) Received: from saraswati.hathway.com (saraswati.hathway.com [202.88.156.6]) by core3.amsl.com (Postfix) with ESMTP id DF75128C66F for ; Wed, 12 Mar 2008 05:21:18 -0700 (PDT) Received: from hathway.com ([127.0.0.1]) by saraswati.hathway.com (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0JXM005JDAJE9I@saraswati.hathway.com> for dnsext-archive@ietf.org; Wed, 12 Mar 2008 17:56:02 +0530 (IST) Received: from [81.199.225.45] by saraswati.hathway.com (mshttpd); Wed, 12 Mar 2008 13:26:02 +0100 Date: Wed, 12 Mar 2008 13:26:02 +0100 From: jobs@hathway.net Subject: Your Email Has Won!!! (CONGRATULATION BATCH: 109/91300/EML) Reply-to: smithparker44@yahoo.co.uk Message-id: <105be710a901.10a901105be7@hathway.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal To: undisclosed-recipients:; EURO MILLIONS Watford, Head Office and Regional Centre Euro Millions, Tolpits Lane, Watford, Herts, WD18 9RN REF NO: EML/ 56-TF-8890776 BATCH: 109/91300/EML We are pleased to inform you as one of today's winners of the EUROMILLIONS MEGAJACKPOT LOTTERY.You have therefore been approved for a lum sum pay out of 420.000 Pounds in cash.You are to contact the claims department by email within 24hours on receipt of the email. You are to contact the claims department by email with the necessary information below to enable him start with the processing of your winning. [FULL NAME OF WINNER]------------------- [NATIONALITY]------------------------------ [PRESENT LOCATION]------------------------- [DATE OOF BIRTH]---------------------------- [SEX]--------------------------------- [OCCUPATION]------------------------------ [WINNING EMAIL]--------------------------- [TEL & FAX]------------------------------ PAYMENT OPTION ; Please Indicate with {x}Your option of Payment 1)Courier Delivery 2)Bank Wire Transfer Contact Claims Department,Euromillions via details below for more details. Mr.Parker Smith EUROMILLIONS United Kingdom Email:smithparker44@yahoo.co.uk From jobs@hathway.net Wed Mar 12 05:22:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B077528C68F for ; Wed, 12 Mar 2008 05:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV-GQ5WhU-M5 for ; Wed, 12 Mar 2008 05:22:40 -0700 (PDT) Received: from saraswati.hathway.com (saraswati.hathway.com [202.88.156.6]) by core3.amsl.com (Postfix) with ESMTP id CAD7028C6B1 for ; Wed, 12 Mar 2008 05:22:12 -0700 (PDT) Received: from hathway.com ([127.0.0.1]) by saraswati.hathway.com (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0JXM005JDAJE9I@saraswati.hathway.com> for dnsext-archive@lists.ietf.org; Wed, 12 Mar 2008 17:56:02 +0530 (IST) Received: from [81.199.225.45] by saraswati.hathway.com (mshttpd); Wed, 12 Mar 2008 13:26:02 +0100 Date: Wed, 12 Mar 2008 13:26:02 +0100 From: jobs@hathway.net Subject: Your Email Has Won!!! (CONGRATULATION BATCH: 109/91300/EML) Reply-to: smithparker44@yahoo.co.uk Message-id: <105be710a901.10a901105be7@hathway.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal To: undisclosed-recipients:; EURO MILLIONS Watford, Head Office and Regional Centre Euro Millions, Tolpits Lane, Watford, Herts, WD18 9RN REF NO: EML/ 56-TF-8890776 BATCH: 109/91300/EML We are pleased to inform you as one of today's winners of the EUROMILLIONS MEGAJACKPOT LOTTERY.You have therefore been approved for a lum sum pay out of 420.000 Pounds in cash.You are to contact the claims department by email within 24hours on receipt of the email. You are to contact the claims department by email with the necessary information below to enable him start with the processing of your winning. [FULL NAME OF WINNER]------------------- [NATIONALITY]------------------------------ [PRESENT LOCATION]------------------------- [DATE OOF BIRTH]---------------------------- [SEX]--------------------------------- [OCCUPATION]------------------------------ [WINNING EMAIL]--------------------------- [TEL & FAX]------------------------------ PAYMENT OPTION ; Please Indicate with {x}Your option of Payment 1)Courier Delivery 2)Bank Wire Transfer Contact Claims Department,Euromillions via details below for more details. Mr.Parker Smith EUROMILLIONS United Kingdom Email:smithparker44@yahoo.co.uk From owner-namedroppers@ops.ietf.org Wed Mar 12 06:00:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7A33A6E46; Wed, 12 Mar 2008 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmXrLl26drwk; Wed, 12 Mar 2008 06:00:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F02D328C6F7; Wed, 12 Mar 2008 05:59:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZQRF-0008g9-4u for namedroppers-data@psg.com; Wed, 12 Mar 2008 12:52:09 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZQR8-0008f9-6H for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 12:52:07 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2CCpnsI018704; Wed, 12 Mar 2008 14:51:49 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2CCpm6u018700; Wed, 12 Mar 2008 14:51:49 +0200 Date: Wed, 12 Mar 2008 14:51:48 +0200 (EET) From: Pekka Savola To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text In-Reply-To: <200803120332.m2C3WlBU084335@ogud.com> Message-ID: References: <200803120332.m2C3WlBU084335@ogud.com> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 22:43:31 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Tue, 11 Mar 2008, Olafur Gudmundsson wrote: > ENDS was specified in 1999 been on the wire since then, with minimal > adverse effects. As number of uses of DNS require larger answers > than can be easily fit in 512 byte answers, it makes sense to > require modern DNS software to implement EDNS0. Thus Authorative > servers, Recursive Resolvers, Stub-resolver and middle-ware boxes > speaking DNS in any form MUST implement ENDS0 and MUST support > buffer size of at least 2K. So-- if a DNS implementation does not claim to implement RFC2671 (or its successor), which RFC is the implementation incompliant with? IMHO, text inside RFC X that RFC X is mandatory has only limited power. Vendors usually describe which features they support by listing the RFC numbers (possibly with exceptions if they don't implement all the features of the spec) and I-D names and numbers. If we want to mandate EDNS0 to be part of every compliant DNS implementation, I believe we should put that requirement in the upcoming profile or other BCP/standards track document (which in turn the vendor could claim to implement or not). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 Mar 12 06:11:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762CB28C6F4; Wed, 12 Mar 2008 06:11: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 lQc565v+ybvf; Wed, 12 Mar 2008 06:11:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5465228C745; Wed, 12 Mar 2008 06:11:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZQXn-000AES-Tt for namedroppers-data@psg.com; Wed, 12 Mar 2008 12:58:55 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZQXj-000ADZ-AA for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 12:58:53 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2CCwbSI018904; Wed, 12 Mar 2008 14:58:37 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2CCwb9h018901; Wed, 12 Mar 2008 14:58:37 +0200 Date: Wed, 12 Mar 2008 14:58:37 +0200 (EET) From: Pekka Savola To: Olaf Kolkman cc: bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Message-ID: References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 22:43:31 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, 12 Mar 2008, Olaf Kolkman wrote: > On Mar 11, 2008, at 11:42 PM, Pekka Savola wrote: > >> >> The usual time the IETF seems to need to iron out most glaring >> specification issues and wear down any resistance is 2-3years (+- 1 year). > > But there are success stories of specifications that went from I-D to RFC in > less time than a year. Unfortunately those seem to be the exceptions that prove the rule.. :-) For example consider the dnsop-reflectors-are-evil document, which was supposedto be on fast-track but has been 2 months short of 2 years now? :-) > This is a simple specification. Folk have been reviewing and implementing it. > If the IETF needs 2-3 years to process a specification like 0x20 than... > sigh... ... > I think it would be good if the docs where merged but my strategy would be > to last call the docs separately so that once it is clear they are both > mature do the merging. But I agree a *LOT* of this depends on the WG chairs, authors and how strong consensus there is (and how much they are willing to compromise and spend energy to build) behind the document. I could agree to your suggestion that we try to move quickly with 0x20 provided that, as you suggested, that the decision to tie the fates of documents together is made at a later phase, and we don't significantly slow down the progress of forgery-resilience for this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 Mar 12 06:53:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9EE3A6ACF; Wed, 12 Mar 2008 06:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=1.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 HoChzWk-xPmU; Wed, 12 Mar 2008 06:53:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74B773A6804; Wed, 12 Mar 2008 06:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZRFd-000Kc8-9d for namedroppers-data@psg.com; Wed, 12 Mar 2008 13:44:13 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZRFW-000KaB-V2 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 13:44:11 +0000 Received: from dhcp-12b8.ietf71.ietf.org (dhcp-12b8.ietf71.ietf.org [130.129.18.184]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2CDhtSA032124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2008 14:43:56 +0100 (CET) (envelope-from olaf@nlnetlabs.nl) Cc: bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> From: Olaf Kolkman To: Pekka Savola In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-39--611032933" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Date: Wed, 12 Mar 2008 09:43:53 -0400 References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.919.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 12 Mar 2008 14:43:57 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-39--611032933 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 12, 2008, at 8:58 AM, Pekka Savola wrote: > and we don't significantly slow down the progress of forgery- > resilience for this. I was thinking that the reverse might actually happen, forgery slowing down 0x20 ;-) --Olaf --Apple-Mail-39--611032933 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) Comment: This message is locally signed. iEYEARECAAYFAkfX3hkACgkQtN/ca3YJIodf7gCg14bAtgeRu9DT5bSRGkQpeBFN YiUAoNlt7/oZmZkI+oBGQGjgfvmSIrIb =02rf -----END PGP SIGNATURE----- --Apple-Mail-39--611032933-- -- to unsubscribe send a message to namedroppers-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 Mar 12 07:14:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5F528C264; Wed, 12 Mar 2008 07:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWn1rcbxJQic; Wed, 12 Mar 2008 07:14:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17E943A6A15; Wed, 12 Mar 2008 07:14:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZRb4-000Pvg-Qe for namedroppers-data@psg.com; Wed, 12 Mar 2008 14:06:22 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZRat-000PrO-4o for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 14:06:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BB9C811434 for ; Wed, 12 Mar 2008 14:06:10 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 14:58:37 +0200." References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 14:06:10 +0000 Message-ID: <11334.1205330770@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > On Wed, 12 Mar 2008, Olaf Kolkman wrote: > > This is a simple specification. Folk have been reviewing and implementing > > it. If the IETF needs 2-3 years to process a specification like 0x20 > > than... sigh... RFC 2671 itself went from i-d to RFC in less than a year. it CAN be done. > > I think it would be good if the docs where merged but my strategy would > > be to last call the docs separately so that once it is clear they are > > both mature do the merging. i didn't propose merging, and i don't think you mean merging. i proposed, and i think you mean, adding a dependency inside forgery-resilience, pointing at 0x20. now, if forgery-resilience specifies is an FYI or BCP, it can have a pointer to 0x20 in its current i-d form, and be edited down the track if 0x20 gets an RFC number before forgery-resilience gets an RFC number. but if forgery-resilience is going to be an STD, then it can't reference 0x20 until 0x20 has an RFC number. bert's counterproposal is that 0x20 proceed independently, and that it update forgery-resilience. i'm OK with that, and with the corresponding proposal for rtt banding (write a new draft and have it update forgery-resilience). i would have preferred a single RFC issued one time containing everything we knew at the moment. forgery-resilience is in a sense already out of date, but if there's value in publishing it even knowing that it's already out of date, then by all means, let's publish it. > From: Pekka Savola ... > But I agree a *LOT* of this depends on the WG chairs, authors and how > strong consensus there is (and how much they are willing to compromise and > spend energy to build) behind the document. > > I could agree to your suggestion that we try to move quickly with 0x20 > provided that, as you suggested, that the decision to tie the fates of > documents together is made at a later phase, and we don't significantly > slow down the progress of forgery-resilience for this. 0x20 only contains one protocol change. i don't think it's controversial, or to put it another way, i think we already have consensus on it. in my opinion we could WGLC 0x20 right now (assuming i submitted it to the ietf draftbot, which i havn't yet since i missed the deadline). here's the one thing in 0x20 that makes it have to be an STD vs. an FYI or BCP: 5.2. It is strongly urged that the DNS specification be amended to require that the question section from the request MUST BE copied, exactly, bit for bit, into the question section of the response. The DNS specification is silent on the matter of altering 0x20 bits in the question name when copying it from the request to the response, so, this change is "within the spirit." A change to the specification is necessary because while such bit for bit copying "happens to be" the universal practice today, we must warn all future responder implementors that the 0x20 bits, while not significant for name matching, are now in use as a "covert channel" by the requestor, for the purpose of increasing the identity of transactions. noting that stuart cheshire has privately proposed to me an improvement of the wording at http://sa.vix.com/~vixie/dns-0x20.txt, since a number of folks at the dnsext meeting thought 0x20 would break binary labels, or alter the meaning of labels by modifying characters that weren't ascii letters. i'll make that change and submit the text to the draftbot as soon as ietf week is ended. is there really any controversy around 0x20, that make it ineligible for an almost instant WGLC? -- to unsubscribe send a message to namedroppers-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 Mar 12 07:25:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E36B28C30C; Wed, 12 Mar 2008 07:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61J2AN0TMVwD; Wed, 12 Mar 2008 07:25:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 724D83A6BE4; Wed, 12 Mar 2008 07:25:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZRjz-0001sg-W1 for namedroppers-data@psg.com; Wed, 12 Mar 2008 14:15:35 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZRjs-0001r8-3c for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 14:15:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C065911436 for ; Wed, 12 Mar 2008 14:15:27 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 09:43:53 -0400." <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 14:15:27 +0000 Message-ID: <11864.1205331327@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > and we don't significantly slow down the progress of forgery- > > resilience for this. > > I was thinking that the reverse might actually happen, forgery slowing > down 0x20 ;-) i was not proposing that 0x20 reference or depend upon forgery-resilience, so this is a can't-happen. the dark horse here is rtt banding. if we don't adopt that change to forgery-resilience, then we can WGLC both 0x20 and forgery-resilience next monday when the ietf meeting is over. -- to unsubscribe send a message to namedroppers-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 Mar 12 07:45:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9503A6A40; Wed, 12 Mar 2008 07:45: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=[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 N2nm-nm2I0Nx; Wed, 12 Mar 2008 07:45:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6FD93A6C35; Wed, 12 Mar 2008 07:45:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZS76-00070P-99 for namedroppers-data@psg.com; Wed, 12 Mar 2008 14:39:28 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZS6t-0006xx-Tz for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 14:39:21 +0000 Received: from [130.129.23.164] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2CEd9XX090619; Wed, 12 Mar 2008 10:39:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200803121203.m2CC3vEK042459@drugs.dv.isc.org> References: <200803121203.m2CC3vEK042459@drugs.dv.isc.org> Date: Wed, 12 Mar 2008 10:38:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: dns-0x20.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 23:03 +1100 3/12/08, Mark Andrews wrote: > 2001:df8:0:112:216:6fff:fe46:b75d IPv6 reverse map? I was thinking more about the parts of the reverse map that matter, like IPv4 and ENUM. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 12 07:45:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FED228C0E7; Wed, 12 Mar 2008 07:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7J1TAQ9z9Iu; Wed, 12 Mar 2008 07:45:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CF2F3A6C35; Wed, 12 Mar 2008 07:45:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZS5f-0006gg-Ns for namedroppers-data@psg.com; Wed, 12 Mar 2008 14:37:59 +0000 Received: from [216.82.250.131] (helo=mail128.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZS5Y-0006f0-Ug for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 14:37:57 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1205332667!19222078!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 13929 invoked from network); 12 Mar 2008 14:37:47 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-15.tower-128.messagelabs.com with SMTP; 12 Mar 2008 14:37:47 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2CEbkkX009656 for ; Wed, 12 Mar 2008 07:37:46 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2CEbjri024852 for ; Wed, 12 Mar 2008 09:37:46 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2CEbiZ7024841 for ; Wed, 12 Mar 2008 09:37:45 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS is mandatory text Date: Wed, 12 Mar 2008 10:37:42 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003996B67@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS is mandatory text Thread-Index: AciEQtnZIsj4Z6ptQbapda2UDYWv7wAC7OhA References: <200803120332.m2C3WlBU084335@ogud.com> From: "Eastlake III Donald-LDE008" To: "Pekka Savola" , "Olafur Gudmundsson" Cc: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Put it both places. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Pekka Savola Sent: Wednesday, March 12, 2008 8:52 AM To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text On Tue, 11 Mar 2008, Olafur Gudmundsson wrote: > ENDS was specified in 1999 been on the wire since then, with minimal=20 > adverse effects. As number of uses of DNS require larger answers=20 > than can be easily fit in 512 byte answers, it makes sense to=20 > require modern DNS software to implement EDNS0. Thus Authorative=20 > servers, Recursive Resolvers, Stub-resolver and middle-ware boxes=20 > speaking DNS in any form MUST implement ENDS0 and MUST support=20 > buffer size of at least 2K. So-- if a DNS implementation does not claim to implement RFC2671 (or=20 its successor), which RFC is the implementation incompliant with? IMHO, text inside RFC X that RFC X is mandatory has only limited=20 power. Vendors usually describe which features they support by=20 listing the RFC numbers (possibly with exceptions if they don't=20 implement all the features of the spec) and I-D names and numbers. If we want to mandate EDNS0 to be part of every compliant DNS=20 implementation, I believe we should put that requirement in the=20 upcoming profile or other BCP/standards track document (which in turn=20 the vendor could claim to implement or not). --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 Mar 12 07:55:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B572128C30D; Wed, 12 Mar 2008 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfRx7+DRSjKE; Wed, 12 Mar 2008 07:54:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9A2428C57E; Wed, 12 Mar 2008 07:54:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZSEU-0008mS-BK for namedroppers-data@psg.com; Wed, 12 Mar 2008 14:47:06 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZSEI-0008cY-LP for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 14:47:04 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JZSEF-0004AF-Fv; Wed, 12 Mar 2008 15:46:51 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D87C44413; Wed, 12 Mar 2008 15:46:55 +0100 (CET) Date: Wed, 12 Mar 2008 15:46:55 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Message-ID: <20080312144655.GD10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> <11864.1205331327@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11864.1205331327@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 02:15:27PM +0000, Paul Vixie wrote: > i was not proposing that 0x20 reference or depend upon forgery-resilience, > so this is a can't-happen. the dark horse here is rtt banding. if we don't > adopt that change to forgery-resilience, then we can WGLC both 0x20 and > forgery-resilience next monday when the ietf meeting is over. Fwiw, I've done some rtt measurements in the past based on PowerDNS, it turns out that at least my favorite operating system (Linux 2.6) plays fast and loose with UDP timings, quite often sending a packet later than it admitted, leading to a very rapid response. This led to my 9ms ADSL connection reporting 5ms response times in a small fraction of queries. I'm not exactly sure what 'rtt banding' is, but I estimate it won't play well with such badly reported timings. And unfortunately, computers (and network drivers, and nics) positively suck for sub-10ms measurements. Even if we call Linux buggy in this respect, it remains a challenge. So I'm all in favour of last call for at least forgery-resilience soon. I'm working over the last batch of minor nits reported, but those all appear to be typographical or rephrasing of things. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 08:24:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294FA28C658; Wed, 12 Mar 2008 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbszgeZePaAh; Wed, 12 Mar 2008 08:24:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B3CA28C6D0; Wed, 12 Mar 2008 08:24:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZSdY-000FZy-OF for namedroppers-data@psg.com; Wed, 12 Mar 2008 15:13:00 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZSdN-000FWf-T3 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 15:12:55 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JZSdA-0000Ir-6d for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 16:12:36 +0100 Received: from fweimer by bfk.de with local id 1JZSdC-00007I-1w for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 16:12:38 +0100 To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding References: <57450.1205256926@sa.vix.com> From: Florian Weimer Date: Wed, 12 Mar 2008 16:12:38 +0100 In-Reply-To: <57450.1205256926@sa.vix.com> (Paul Vixie's message of "Tue, 11 Mar 2008 17:35:26 +0000") Message-ID: <82myp42cyh.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: DNSEXT discussion * Paul Vixie: > i said in the dnsext meeting just now that we should delay wglc on > dns-forgery-resilience until dns-0x20 can join it, be referenced by > it, and the two progress together. I don't think this is a good idea. If there's an attempt to derail one of those drafts, it affects both, so let's keep them as separate as possible. The 0x20 material is probably quite controversial, and BCP 79 issues may still turn up. 0x20 seems to need far more testing than it got so far (Windows, DNS load balancers, popular middleboxen come to my mind). If 0x20 picks up authority server address distribution, it will turn into a significantly more complex beast, 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 -- to unsubscribe send a message to namedroppers-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 Mar 12 08:59:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233A53A6E9D; Wed, 12 Mar 2008 08:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7plk4yhXD-v; Wed, 12 Mar 2008 08:59:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF6EA28C1EC; Wed, 12 Mar 2008 08:59:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTCn-000PpN-1p for namedroppers-data@psg.com; Wed, 12 Mar 2008 15:49:25 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTBL-000PAZ-Kz for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 15:48:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 384A611425 for ; Wed, 12 Mar 2008 15:47:55 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 15:46:55 +0100." <20080312144655.GD10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> <11864.1205331327@sa.vix.com> <20080312144655.GD10313@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 15:47:55 +0000 Message-ID: <15397.1205336875@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I'm not exactly sure what 'rtt banding' is, but I estimate it won't play > well with such badly reported timings. And unfortunately, computers (and > network drivers, and nics) positively suck for sub-10ms measurements. Even if > we call Linux buggy in this respect, it remains a challenge. rest assured, the rtt banding discussion i overheard accounts for this kind of slop. most operating systems can't accurately measure things shorter than a tick, and some can't come within 10ms. "horseshows, hand grenades, and 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 Wed Mar 12 09:10:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE2F3A6ED1; Wed, 12 Mar 2008 09:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHiZaGkeqJJL; Wed, 12 Mar 2008 09:10:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B70C03A6EC7; Wed, 12 Mar 2008 09:10:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTQm-0003b5-Mi for namedroppers-data@psg.com; Wed, 12 Mar 2008 16:03:52 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTMR-0002KN-Cl for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 16:00:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 12FFB11425 for ; Wed, 12 Mar 2008 15:59:23 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 16:12:38 +0100." <82myp42cyh.fsf@mid.bfk.de> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 15:59:23 +0000 Message-ID: <16130.1205337563@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > ... The 0x20 material is probably quite controversial, and > BCP 79 issues may still turn up. do tell. i havn't seen or heard any controversy yet, just misunderstandings because the draft's text is sloppy or inadequate, and folks saying it's ugly, and folks saying why waste effort on this if we believe in dnssec long term. > 0x20 seems to need far more testing than it got so far (Windows, DNS > load balancers, popular middleboxen come to my mind). i know of very few places where a caching recursive nameserver speaks through middleboxes when reaching authority servers. 0x20 is definitely not middlebox safe, which is why i don't recommend it for stub resolver use. more testing would be welcome -- i've been running it on my own nameservers for a couple weeks now and have yet to trigger the name-mismatch syslog even after millions of upstream transactions. but i don't have a load balancer. what's needed is a BIND9 patch that lots of people can test in lots of topologies. > If 0x20 picks up authority server address distribution, it will turn into a > significantly more complex beast, too. authority server address distribution will not be part of the dns-0x20 draft, it can either become a section in forgery-resilience, or become its own draft. -- to unsubscribe send a message to namedroppers-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 Mar 12 09:34:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EA93A6D65; Wed, 12 Mar 2008 09:34: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 fzZxUcQvm7FP; Wed, 12 Mar 2008 09:34:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 171753A6935; Wed, 12 Mar 2008 09:34:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTi8-0008kD-6d for namedroppers-data@psg.com; Wed, 12 Mar 2008 16:21:48 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZThu-0008ft-72 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 16:21:39 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2CGLTTP091739 for ; Wed, 12 Mar 2008 12:21:29 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2CGLTpT091738 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 12:21:29 -0400 (EDT) (envelope-from namedroppers) Received: from [143.215.128.120] (helo=fritz.cc.gt.atl.ga.us) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZSZr-000EpC-2l for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 15:09:15 +0000 Received: from fritz.cc.gt.atl.ga.us (localhost.cc.gt.atl.ga.us [127.0.0.1]) by fritz.cc.gt.atl.ga.us (Postfix) with ESMTP id B6F2445045; Wed, 12 Mar 2008 11:11:28 -0400 (EDT) Received: (from dagon@localhost) by fritz.cc.gt.atl.ga.us (8.13.8/8.13.8/Submit) id m2CFBQvj063086; Wed, 12 Mar 2008 11:11:26 -0400 (EDT) (envelope-from dagon) Date: Wed, 12 Mar 2008 11:11:26 -0400 From: David Dagon To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org, dagon@cc.gatech.edu Subject: Re: dns-0x20.txt Message-ID: <20080312151126.GC25631@fritz.cc.gt.atl.ga.us> References: <69903.1204047792@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tue, Mar 11, 2008 at 11:12:44PM -0400, Edward Lewis wrote: > An off-hand comment, this doesn't do a whole lot for the reverse map. > (Unless I am missing something.) It doesn't hurt though. Probably a > mention in the security section on that topic. Thanks for this note. My original thinking focused on plain vanilla IN A poisoning, but attacking the reverse of course has uses for .rhosts mischief and gaming anti-spam rule engines. I've been measuring the average distribution of [A-Za-z] in A, NS, MX, etc., to see how much entropy DNS-0x20 gains, more or less. To this, I'll add the fixed values for reverse. Thanks for the suggestion. You're correct, the benefits can be modest--just a few bits in the worst case. However, the upside of course is that each [A-Za-z] character in a label increases the search space for poisoning based on random guessing. [Insert here the usual disclaimer about attackers-doing-better-than-guessing and weak sources of random numbers, etc.] If one uses both the ID field and port field, < 2^{32} (if reserved ports are excluded), each additional 0x20 bit doubles the search space for the attacker. (Again, this assumes an equally strong random source is used for all three sources of entropy.) The question "When is there enough entropy to be safe?" always has a subjective answer, and I think we'd all like something much larger than 2^{40ish}. Exponential growth is punishing above a threshold and DNS-0x20, while not the cure, does get one closer. We do have the incongruous result where "important" domains (or however we describe them) are "weaker" (or however we characterize it) than less important domains. But for every "Entropy(licensing.disney.com) >> Entropy(irs.gov)" example, you'll find several .museum domains that are better off than .tv domains because of DNS-0x20. And so maybe there's some justice after all. :) Re: the lack of harm: I'm not aware of any applications monitoring recursive-to-authority traffic that would be negatively affected by 0x20 flipping. (And if such IDS or mark protection equipment triggered on anomalous variations in upper/lower case, I think we can say they made bad assumptions.) I am interested in hearing otherwise, if anyone comes across an example. -- David Dagon /"\ "When cryptography dagon@cc.gatech.edu \ / ASCII RIBBON CAMPAIGN is outlawed, bayl Ph.D. Student X AGAINST HTML MAIL bhgynjf jvyy unir Georgia Inst. of Tech. / \ cevinpl." -- to unsubscribe send a message to namedroppers-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 Mar 12 09:45:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590C83A6E9F; Wed, 12 Mar 2008 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQKB+SOERQAy; Wed, 12 Mar 2008 09:45:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F8DD3A6E98; Wed, 12 Mar 2008 09:45:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTye-000DF8-2a for namedroppers-data@psg.com; Wed, 12 Mar 2008 16:38:52 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZTy7-000D1L-FL for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 16:38:29 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JZTy4-0006Yz-As; Wed, 12 Mar 2008 17:38:16 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5A33A468C; Wed, 12 Mar 2008 17:38:21 +0100 (CET) Date: Wed, 12 Mar 2008 17:38:21 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Message-ID: <20080312163821.GG10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16130.1205337563@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On a related note, since when do we try to standardise or even mandate untested behaviour? 'port hopping' and the various other techniques described in forgery-resilience have been in wide use for 5 years or more. I'm actually wondering what is in the drinking water in Phildelphia that we are suddenly being so psyched up about standardising dns-0x20! I'm going to do the last call for forgery-resilience soon, and I'd love to look at dns-0x20 and rtt-banding and whatnot afterwards. But please let's not try to get ahead of ourselves. Bert (who usually does not top quote) On Wed, Mar 12, 2008 at 03:59:23PM +0000, Paul Vixie wrote: > > ... The 0x20 material is probably quite controversial, and > > BCP 79 issues may still turn up. > > do tell. i havn't seen or heard any controversy yet, just misunderstandings > because the draft's text is sloppy or inadequate, and folks saying it's ugly, > and folks saying why waste effort on this if we believe in dnssec long term. > > > 0x20 seems to need far more testing than it got so far (Windows, DNS > > load balancers, popular middleboxen come to my mind). > > i know of very few places where a caching recursive nameserver speaks through > middleboxes when reaching authority servers. 0x20 is definitely not middlebox > safe, which is why i don't recommend it for stub resolver use. more testing > would be welcome -- i've been running it on my own nameservers for a couple > weeks now and have yet to trigger the name-mismatch syslog even after millions > of upstream transactions. but i don't have a load balancer. what's needed is > a BIND9 patch that lots of people can test in lots of topologies. > > > If 0x20 picks up authority server address distribution, it will turn into a > > significantly more complex beast, too. > > authority server address distribution will not be part of the dns-0x20 draft, > it can either become a section in forgery-resilience, or become its own draft. > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > !DSPAM:47d805af176382039411530! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 10:11:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8085728C439; Wed, 12 Mar 2008 10:11:38 -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.326, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJilxHjBghMj; Wed, 12 Mar 2008 10:11:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F2B33A6ED2; Wed, 12 Mar 2008 10:11:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZUJq-000L6g-K0 for namedroppers-data@psg.com; Wed, 12 Mar 2008 17:00:46 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZUJg-000L55-6L for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 17:00:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DB8D811425 for ; Wed, 12 Mar 2008 17:00:35 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 17:38:21 +0100." <20080312163821.GG10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 17:00:35 +0000 Message-ID: <18872.1205341235@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > On a related note, since when do we try to standardise or even mandate > untested behaviour? this isn't untested behaviour. > 'port hopping' and the various other techniques described in > forgery-resilience have been in wide use for 5 years or more. are you proposing that we let 0x20 cook for a few months or years, then? > I'm actually wondering what is in the drinking water in Phildelphia that we > are suddenly being so psyched up about standardising dns-0x20! it happens to work. if we don't get the standard clarified, then a new implementation will be free to downcase (for example) the question name when copying from the request to the response. thus there is a need for speed, and a demonstration of safety. > I'm going to do the last call for forgery-resilience soon, and I'd love to > look at dns-0x20 and rtt-banding and whatnot afterwards. > > But please let's not try to get ahead of ourselves. how far behind ourselves would you feel comfortable being? re: > > ... more testing would be welcome -- i've been running it on my own > > nameservers for a couple weeks now and have yet to trigger the > > name-mismatch syslog even after millions of upstream transactions. ... -- to unsubscribe send a message to namedroppers-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 Mar 12 10:20:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2917C28C68D; Wed, 12 Mar 2008 10:20:40 -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 2Qw+Yv1WFl4z; Wed, 12 Mar 2008 10:20:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4B6128C439; Wed, 12 Mar 2008 10:20:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZUX0-000PGl-4q for namedroppers-data@psg.com; Wed, 12 Mar 2008 17:14:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZUWs-000PC5-Oc for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 17:14:20 +0000 Received: from [130.129.23.164] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2CHDojU092509; Wed, 12 Mar 2008 13:13:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3870C46029D1F945B1472F170D2D979003996B67@de01exm64.ds.mot.com> References: <200803120332.m2C3WlBU084335@ogud.com> <3870C46029D1F945B1472F170D2D979003996B67@de01exm64.ds.mot.com> Date: Wed, 12 Mar 2008 13:13:44 -0400 To: "Eastlake III Donald-LDE008" From: Edward Lewis Subject: RE: DNS is mandatory text Cc: "Pekka Savola" , "Olafur Gudmundsson" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I have a general problem with statements like "XYZ is mandatory." Especially in contrast with the mantra "the IETF has no protocol police." What if a DNS implementation (which could be just a simple case of an application generating a query message and reading a response) doesn't have EDNS0 in it? Will the IETF send in some kind of legal enforcement team to prevent the code from being labelled DNS in any way? I can understand devising an extension to the DNS protocol or proscribing a means of putting DNS to use for a specific purpose that assumes that EDNS0 is available and in use. I would see that happening by the extension/proscription including an applicability clause saying that "EDNS0 [RFC blah] is required." But I can't support a blanket "from here on out, EDNS0 has to be in place." There are turnkey uses of the DNS protocol that do not need and never will need EDNS0, writing a rule that causes these systems to have to implement EDNS0 is not beneficial. For general purpose implementations (I am trying to define that in the AXFR document) it is a good idea to have EDNS0 included. But this is where the IETF has to realize that it does not enforce it's own requirements. Barring a complete rewrite of the DNS specification, there should remain a separate document defining EDNS0. Any profile document ought to include ENDS0 as an essential feature of a general purpose implementation and recommend all other implementations either implement it or be aware that EDNS0 is defined. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 12 10:27:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A7328C439; Wed, 12 Mar 2008 10:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.116, 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 yQX2PF8Gd8FH; Wed, 12 Mar 2008 10:27:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AA7628C6AB; Wed, 12 Mar 2008 10:27:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZUco-0000o1-9l for namedroppers-data@psg.com; Wed, 12 Mar 2008 17:20:22 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZUce-0000hq-Lx for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 17:20:16 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id DFFE432E65; Wed, 12 Mar 2008 18:20:06 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 5C3F51576FE; Wed, 12 Mar 2008 13:19:29 -0400 (EDT) Date: Wed, 12 Mar 2008 13:19:30 -0400 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt Message-ID: <20080312171930.GA9404@laperouse.bortzmeyer.org> References: <69903.1204047792@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Tue, Mar 11, 2008 at 11:12:44PM -0400, Edward Lewis wrote a message of 39 lines which said: > this doesn't do a whole lot for the reverse map. It is much worse for all-digital domains (they are allowed in ".fr"). Should ICANN delegate numeric TLD, 1.666.42 would not be protected by 0x20 :-) -- to unsubscribe send a message to namedroppers-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 Mar 12 10:55:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821E63A682F; Wed, 12 Mar 2008 10:55:14 -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.112, 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 N0Y2x-VGlEeE; Wed, 12 Mar 2008 10:55:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBDE53A6F02; Wed, 12 Mar 2008 10:55:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZV2s-0009Re-2g for namedroppers-data@psg.com; Wed, 12 Mar 2008 17:47:18 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZV2o-0009O3-3Z for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 17:47:16 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 6E4C331D2D; Wed, 12 Mar 2008 18:47:12 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 350A61576FE; Wed, 12 Mar 2008 13:42:28 -0400 (EDT) Date: Wed, 12 Mar 2008 13:42:29 -0400 From: Stephane Bortzmeyer To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text Message-ID: <20080312174229.GA11561@laperouse.bortzmeyer.org> References: <200803120332.m2C3WlBU084335@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803120332.m2C3WlBU084335@ogud.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Tue, Mar 11, 2008 at 11:31:54PM -0400, Olafur Gudmundsson wrote a message of 32 lines which said: > MUST support buffer size of at least 2K. It is larger than the typical "Internet" MTU of 1.5K. Is it an issue? Why 2K? -- to unsubscribe send a message to namedroppers-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 Mar 12 10:56:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0531F3A6BDD; Wed, 12 Mar 2008 10:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQtuR8q2zi0l; Wed, 12 Mar 2008 10:56:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07F3D3A69B3; Wed, 12 Mar 2008 10:56:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZV5W-000A6f-6E for namedroppers-data@psg.com; Wed, 12 Mar 2008 17:50:02 +0000 Received: from [204.152.189.134] (helo=mail.virtualized.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZV5L-000A3t-E8 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 17:49:56 +0000 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id m2CH8xmE086439; Wed, 12 Mar 2008 09:08:59 -0800 (PST) (envelope-from drc@virtualized.org) Cc: namedroppers@ops.ietf.org Message-Id: <9B35308A-22E3-4624-B550-ABA2D3280F6B@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <11334.1205330770@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Date: Wed, 12 Mar 2008 10:49:38 -0700 References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <11334.1205330770@sa.vix.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > since a number of folks > at the dnsext meeting thought 0x20 would break binary labels, Sorry? Who cares? Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 10:57:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B273A6841; Wed, 12 Mar 2008 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 2UZYpK6xfVYr; Wed, 12 Mar 2008 10:57:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8078A3A6940; Wed, 12 Mar 2008 10:56:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZV2f-0009N2-Uw for namedroppers-data@psg.com; Wed, 12 Mar 2008 17:47:05 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZV2Y-0009LV-C0 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 17:47:01 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JZV2V-0008C9-A3; Wed, 12 Mar 2008 18:46:55 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 61E064110; Wed, 12 Mar 2008 18:47:00 +0100 (CET) Date: Wed, 12 Mar 2008 18:47:00 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Message-ID: <20080312174700.GI10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18872.1205341235@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 05:00:35PM +0000, Paul Vixie wrote: > > On a related note, since when do we try to standardise or even mandate > > untested behaviour? > > this isn't untested behaviour. I appreciate the testing you've performed, but from bitter experience I know how much corner cases hide on the internet. Many of which might not be appearant from even millions of transactions. > > 'port hopping' and the various other techniques described in > > forgery-resilience have been in wide use for 5 years or more. > > are you proposing that we let 0x20 cook for a few months or years, then? Indeed I am, especially if we want not just to describe it (which does not take an RFC), but say people SHOULD use it. Years might be too much, but months are definitely too little. There isn't even a public implementation as far as I know. It is fine to add the rules you describe that make sure that dns-0x20 can work, of course. But please do not conjoin this with the boring words of dns-forgery-resilience :-) Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 11:20:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41FE28C1A2; Wed, 12 Mar 2008 11:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, J_CHICKENPOX_64=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 tlfCA4u3iC8O; Wed, 12 Mar 2008 11:20:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECB333A6E02; Wed, 12 Mar 2008 11:20:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZVOk-000GrJ-Gy for namedroppers-data@psg.com; Wed, 12 Mar 2008 18:09:54 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZVOd-000Gq5-IG for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 18:09:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3C4C311425; Wed, 12 Mar 2008 18:09:47 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 18:47:00 +0100." <20080312174700.GI10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 18:09:47 +0000 Message-ID: <21844.1205345387@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > this isn't untested behaviour. > > I appreciate the testing you've performed, but from bitter experience I know > how much corner cases hide on the internet. Many of which might not be > appearant from even millions of transactions. if there is a problem in some corner, and we don't encounter it frequently, then it will be a bit like "delegation-only" -- once the mass of the installed base stopped accepting anything except delegations from all TLD's except a few that were known at the time, it became impossible for new non-delegation-only TLDs to come into existence, unless they wanted to fight a long uphill battle. so, practically speaking, the fact that i've not run into any non-copiers in a few million upstream transactions, means that further testing is illuminative but not decisive. > There isn't even a public implementation as far as I know. i think unbound has it in SVN now. here's the code i used in my own implementation. a patch for BIND9 will be shortly forthcoming, i'm told. /* Return some random bits, pulling them through an in-process entropy pool. */ u_int my_random(int bits) { static u_long randbuf; /* up to next 32 random bits */ static int randbuf_len; /* bits remaining in randbuf */ static int recrypt; /* reseed with true random bits then */ u_long mask; u_int ret; if (bits >= NBBY * (int)sizeof(u_int)) { assert(bits <= NBBY * (int)sizeof(u_int)); mask = (u_int)-1; } else { assert(bits >= 0); mask = (1 << bits) - 1; } if (randbuf_len < bits) { if (--recrypt <= 0) { recrypt = 10000; srandomdev(); } randbuf = random(); randbuf_len = NBBY * (int)sizeof(u_int); } randbuf_len -= bits; ret = randbuf & mask; randbuf >>= bits; return (ret); } /* Implement Dagon-style DNS name randomization. */ void randomize_dns_name(u_char *nname) { int llen; while ((llen = *nname++) != 0) { int i; for (i = 0; i < llen; i++) { int ch = *nname; if (isascii(ch) && isalpha(ch)) { if (my_random(1)) ch |= 0x20; else ch &= ~0x20; *nname = ch; } nname++; } } } > It is fine to add the rules you describe that make sure that dns-0x20 can > work, of course. that being the only important part (since it changes the protocol description and has to be done speedily), i don't understand exactly what you'd like to see delayed. > But please do not conjoin this with the boring words of > dns-forgery-resilience :-) perhaps if dns-forgery-resilience were renamed to dns-queryport-churn then i would not feel a need to load it up with references to other methods for dns forgery resilience. -- to unsubscribe send a message to namedroppers-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 Mar 12 11:23:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C003A6EDB; Wed, 12 Mar 2008 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S31nW4nDjz+E; Wed, 12 Mar 2008 11:23:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C97F73A6E44; Wed, 12 Mar 2008 11:23:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZVUb-000I2C-JA for namedroppers-data@psg.com; Wed, 12 Mar 2008 18:15:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZVUX-000I1K-Lg for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 18:15:55 +0000 Received: from [130.129.23.164] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2CIFlUm093227; Wed, 12 Mar 2008 14:15:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <57450.1205256926@sa.vix.com> References: <57450.1205256926@sa.vix.com> Date: Wed, 12 Mar 2008 14:09:17 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 17:35 +0000 3/11/08, Paul Vixie wrote: >i said in the dnsext meeting just now that we should delay wglc on >dns-forgery-resilience until dns-0x20 can join it, be referenced by >it, and the two progress together. My impression of 0x20 is that it 1) Merely requires a strengthening (spec-wise) of something that seems obvious and seems to be done widely/universally 2) Protects a lot but not everything (e.g., numeric/non-binary labels) 3) Is something that needn't be defined in a standard (much the same way resolvers choose authoritative servers. So I don't agree that we should retard progress on forgery-resilience to tie it with 0x20. We should have something that "clarifies" (if you will) the role of the Question section in a reply. We could entertain a document that describes "the use of capitalization pattern of a qname in message uniqueness". -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 12 12:07:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA1B28C83F; Wed, 12 Mar 2008 12:07:09 -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 7UKOOYibQKA2; Wed, 12 Mar 2008 12:07:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1220E28C893; Wed, 12 Mar 2008 12:04:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZW8I-0001fX-Fe for namedroppers-data@psg.com; Wed, 12 Mar 2008 18:56:58 +0000 Received: from [204.152.189.134] (helo=mail.virtualized.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZW83-0001Z2-Sh for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 18:56:45 +0000 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id m2CIFomE086637; Wed, 12 Mar 2008 10:15:50 -0800 (PST) (envelope-from drc@virtualized.org) Cc: namedroppers@ops.ietf.org Message-Id: <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> From: David Conrad To: Stephane Bortzmeyer In-Reply-To: <20080312171930.GA9404@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: dns-0x20.txt Date: Wed, 12 Mar 2008 11:56:29 -0700 References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > It is much worse for all-digital domains (they are allowed in > ".fr"). Should ICANN delegate numeric TLD, 1.666.42 would not be > protected by 0x20 :-) I believe ICANN has come out saying that all-numeric TLDs would be bad. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 12:14:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192703A6A4D; Wed, 12 Mar 2008 12:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_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 NSSrm-DxSemg; Wed, 12 Mar 2008 12:14:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 007973A67AF; Wed, 12 Mar 2008 12:14:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZWIs-0004T4-QR for namedroppers-data@psg.com; Wed, 12 Mar 2008 19:07:54 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZWIl-0004RC-0V for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 19:07:49 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 764B831D31; Wed, 12 Mar 2008 20:07:45 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id C41121576FE; Wed, 12 Mar 2008 15:07:30 -0400 (EDT) Date: Wed, 12 Mar 2008 15:07:30 -0400 From: Stephane Bortzmeyer To: David Conrad Cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt Message-ID: <20080312190730.GA19272@laperouse.bortzmeyer.org> References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 11:56:29AM -0700, David Conrad wrote a message of 8 lines which said: > I believe ICANN has come out saying that all-numeric TLDs would be > bad. http://www.icann.org/topics/dns-stability-draft-paper-06feb08.pdf > In order to prevent confusion with IPv4 addresses which are > expressed as numeric labels separated by dots (e.g. 192.168.1.1) > ICANN expects to disallow proposed TLDs containing only numeric > characters. Such a prohibition will avoid a TLD typed into a browser > from being resolved as an IP address. Which proves that ICANN, in its wisdom, foresaw the 0X20 trick :-) -- to unsubscribe send a message to namedroppers-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 Mar 12 13:00:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF163A6E99; Wed, 12 Mar 2008 13:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[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 bDEri2p1+fwe; Wed, 12 Mar 2008 13:00:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB9FB3A6B54; Wed, 12 Mar 2008 13:00:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZWyG-000EM0-CN for namedroppers-data@psg.com; Wed, 12 Mar 2008 19:50:40 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZWy3-000EK9-7l for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 19:50:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m2CJnADZ027835; Wed, 12 Mar 2008 19:49:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m2CJn5pW027834; Wed, 12 Mar 2008 19:49:05 GMT Date: Wed, 12 Mar 2008 19:49:05 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt Message-ID: <20080312194905.GA27798@vacation.karoshi.com.> References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 11:56:29AM -0700, David Conrad wrote: > >It is much worse for all-digital domains (they are allowed in > >".fr"). Should ICANN delegate numeric TLD, 1.666.42 would not be > >protected by 0x20 :-) > > I believe ICANN has come out saying that all-numeric TLDs would be bad. > > Regards, > -drc and do you think that ICANN might have the same advice, regardless of encoding? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 13:12:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97D53A6C0B; Wed, 12 Mar 2008 13:12:39 -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.039, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD2LlUU0-fCs; Wed, 12 Mar 2008 13:12:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 473AB3A6905; Wed, 12 Mar 2008 13:12:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZX9q-000HWi-0Z for namedroppers-data@psg.com; Wed, 12 Mar 2008 20:02:38 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZX9k-000HVo-8q for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 20:02:35 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JZX9f-0002W3-Nd; Wed, 12 Mar 2008 21:02:27 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C30FF4424; Wed, 12 Mar 2008 21:02:32 +0100 (CET) Date: Wed, 12 Mar 2008 21:02:32 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Message-ID: <20080312200232.GK10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21844.1205345387@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 06:09:47PM +0000, Paul Vixie wrote: > if there is a problem in some corner, and we don't encounter it frequently, > then it will be a bit like "delegation-only" -- once the mass of the installed Ok, I've implemented dns-0x20 in the powerdns recursor as well, but I'm seeing some side effects I worry about. Just before sending out a question packet, I twiddle the 0x20 bit randomly, and I now operate case sensitively on processing responses. However, the output of 'dig' is now weird. ;; QUESTION SECTION: ;www.lwn.net. IN A ;; ANSWER SECTION: www.lwN.nET. 28798 IN CNAME lwN.nET. lwN.nET. 1198 IN A 66.216.68.48 I've added 'backmapping' so if I see the result of my mangling, I copy back in the original untwiddled name, resulting in something like: ;; QUESTION SECTION: ;www.lwn.net. IN A ;; ANSWER SECTION: www.lwn.net. 28798 IN CNAME lwN.nET. lwN.nET. 1198 IN A 66.216.68.48 Should we map back everything we twiddled? Or should we trust stub resolvers to be case insensitive? > so, practically speaking, the fact that i've not run into any non-copiers in > a few million upstream transactions, means that further testing is illuminative > but not decisive. I have over two billion queries and supposedly correct answers here I can test with, which would generate more confidence. But I still worry about client side issues - I don't have a representative test for those. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 13:34:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19D028C417; Wed, 12 Mar 2008 13:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePO3N0v7FpcD; Wed, 12 Mar 2008 13:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C62663A6A3A; Wed, 12 Mar 2008 13:34:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXW3-000OcA-E6 for namedroppers-data@psg.com; Wed, 12 Mar 2008 20:25:35 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXVn-000OXI-9X for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 20:25:24 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 004A511425 for ; Wed, 12 Mar 2008 20:25:19 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 21:02:32 +0100." <20080312200232.GK10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> <20080312200232.GK10313@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 20:25:18 +0000 Message-ID: <27090.1205353518@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Ok, I've implemented dns-0x20 in the powerdns recursor as well, but I'm > seeing some side effects I worry about. > ... > I've added 'backmapping' so if I see the result of my mangling, I copy back > in the original untwiddled name, resulting in something like: > > ;; QUESTION SECTION: > ;www.lwn.net. IN A > > ;; ANSWER SECTION: > www.lwn.net. 28798 IN CNAME lwN.nET. > lwN.nET. 1198 IN A 66.216.68.48 for me that comes out as ;; QUESTION SECTION: ;www.lwn.net. IN A ;; ANSWER SECTION: www.lwn.net. 28588 IN CNAME lwn.net. lwn.net. 988 IN A 66.216.68.48 because i "backmap" before decompressing, per a suggestion from wouters, which was incorporated into http://sa.vix.com/~vixie/dns-0x20.txt a week or so ago and looks like this: 5.4. Requestors should take care to remember the original question name, so that following successful verification of the 0x20-randomized question name, the original can be copied into the response message before the other sections are uncompressed. This is because compression pointers in the answer, authority, and additional section often point back to the question section, with the ugly result of copying the 0x20-randomized bits into the cache, and into subsequent responses which include data from the cache. > Should we map back everything we twiddled? Or should we trust stub resolvers > to be case insensitive? i don't think we should replace any part of the response except the question name. if the responder copies, than uses pointers, and in their copy they use the upper/lowercaseness of the question name rather than the zone content, then i think we're too far afield and we have to just let some ugly things happen. > But I still worry about client side issues - I don't have a representative > test for those. my stub resolvers aren't seeing these 0x20 bits, thanks to wouters' idea. -- to unsubscribe send a message to namedroppers-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 Mar 12 13:39:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894133A6E1C; Wed, 12 Mar 2008 13:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=0.820, 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 DUaxcS+Rw9a4; Wed, 12 Mar 2008 13:39:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50C6A28C86B; Wed, 12 Mar 2008 13:38:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXbj-0000U8-H5 for namedroppers-data@psg.com; Wed, 12 Mar 2008 20:31:27 +0000 Received: from [204.152.189.134] (helo=mail.virtualized.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXba-0000RK-5n for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 20:31:22 +0000 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id m2CJoUmE086868; Wed, 12 Mar 2008 11:50:31 -0800 (PST) (envelope-from drc@virtualized.org) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: bmanning@vacation.karoshi.com In-Reply-To: <20080312194905.GA27798@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 v919.2) Subject: Re: dns-0x20.txt Date: Wed, 12 Mar 2008 13:31:11 -0700 References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion >> I believe ICANN has come out saying that all-numeric TLDs would be >> bad. >> > and do you think that ICANN might have the same advice, > regardless of encoding? Not sure exactly what you mean, but I'd say numeric TLDs are just a bad idea. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 13:51:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E71C3A6C02; Wed, 12 Mar 2008 13:51:48 -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 aLiM2Qki9pFz; Wed, 12 Mar 2008 13:51:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB6DC3A69B3; Wed, 12 Mar 2008 13:51:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXor-000481-AH for namedroppers-data@psg.com; Wed, 12 Mar 2008 20:45:01 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXon-00046e-7a for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 20:44:59 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2CKhbiC016229; Thu, 13 Mar 2008 03:43:38 +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 m2CKhOuO009176; Thu, 13 Mar 2008 03:43:35 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: <11334.1205330770@sa.vix.com> References: <11334.1205330770@sa.vix.com> <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 2008 03:43:24 +0700 Message-ID: <6689.1205354604@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Wed, 12 Mar 2008 14:06:10 +0000 From: Paul Vixie Message-ID: <11334.1205330770@sa.vix.com> | 0x20 only contains one protocol change. | i don't think it's controversial, or You mean the protocol change? That is, requiring unchanged question section in the reply? That's fine, it's what I always kind of assumed was required anyway. But the way you're proposing on using that? While it is very clever, even cute, it is also downright evil. The a==A stuff that's in the DNS is truly annoying, it should never have been done (though I understand why it was), and it would be nice to be able to make it go away at some far distant future point of time. Doing this case flipping trick, and actually having implementations use it in the wild would mean we could never rid ourselves of that botch to the protocol. Further, this trick doesn't help at all for the single most important DNS lookup that's ever done - the query for the root nameservers. Manage to forge a reply to that one and none of the others matter. If anything, by making others harder to forge replies for, but leaving this one untouched, you'd be shifting attacks more in that direction, which I don't think would be a useful result. Last, it results in just plain ugly replies - in the context of AXFR I saw some mention of name case preservation, and how label compression can make a mess of this. I think it was marka who said that it's only in the context of AXFR that anyone ever complains about this. I beg to differ - this bugs me no end on ordinary queries, and you're proposing making it worse... Please put this trick in the "look ma, no hands" category - treat it as something to marvel at, laugh at, and avoid like the plague. kre ps: a better thing to be spending time on might be to redefine the DNS packet format, and fix lots of the issues that we currently have that are caused by this - I suspect it can be done in a way (kind of like EDNS0) whereby the query format would appear compatible with basic old DNS, but would signal advanced capability - once that's done, the reply can be whatever will work best - this could fix multiple queries in one packet, add as many ID bits as could ever be useful, and whatever else needs doing. -- to unsubscribe send a message to namedroppers-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 Mar 12 13:53:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E6E3A6BE4; Wed, 12 Mar 2008 13:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, SARE_RECV_SKANOVA=0.66] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEQ80CZwpHp8; Wed, 12 Mar 2008 13:53:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 922453A6BD1; Wed, 12 Mar 2008 13:53:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXoe-000455-8I for namedroppers-data@psg.com; Wed, 12 Mar 2008 20:44:48 +0000 Received: from [2a01:280:1:1:208:2ff:fe25:3979] (helo=bardisk.kthnoc.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXoW-00043o-Et for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 20:44:42 +0000 Received: from rasmus.kthnoc.net (h80n9c1o253.bredband.skanova.com [81.230.44.80]) (authenticated bits=0) by bardisk.kthnoc.net (8.14.1/8.13.6) with ESMTP id m2CKiTsS065928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 21:44:31 +0100 (CET) (envelope-from mansaxel@kthnoc.net) Date: Wed, 12 Mar 2008 19:02:43 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text Message-ID: <6D8BC8C8C396B565270BA236@90273E0ED7A6C4458FE339F4> In-Reply-To: <200803120332.m2C3WlBU084335@ogud.com> References: <200803120332.m2C3WlBU084335@ogud.com> X-Mailer: Mulberry/4.0.9b1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1771BCCEEA927B48A713==========" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --==========1771BCCEEA927B48A713========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On tisdag, tisdag 11 mar 2008 23.31.54 -0400 Olafur Gudmundsson wrote: > >=20 > During the namedroppers meeting I made the proposal that the current > ENDS0bis draft include words that made EDNS0 mandatory. > The sense of the room was that this was reasonable, even though it will > cause some problems. > I (personally) have the feeling this is a question of short intense pain > vs long dull pain. I think this is a good idea. The interop issues when stuff (like firewalls) don't grok EDNS0 and don't correctly signal this (making smooth downgrade impossible) are irritating enough. It might only be usable as a larger mallet on vendors, but that is sufficient for me.=20 > So I propose that the next version of EDNS0bis contain something like: > (feel free to word smith) >=20 >=20 > ENDS is required > > ENDS was specified in 1999 been on the wire since then, with minimal > adverse effects. > As number of uses of DNS require larger answers than can be easily fit in > 512 byte answers, it makes sense to require modern DNS software to > implement > EDNS0. > Thus Authorative servers, Recursive Resolvers, Stub-resolver and > middle-ware > boxes speaking DNS in any form MUST implement ENDS0 and MUST support > buffer > size of at least 2K. EDNS was specified in 1999 [RFC2671] and has been used frequently since then, with minimal adverse effects. As the number of uses for DNS requiring larger messages not fitting in the 512 byte pre-EDNS message size increases, it makes sense to require modern DNS software, in name servers, full-service resolvers and stub resolvers, as well as middle-boxes, to implement EDNS version 0, and to support and advertise a buffer size of at least 2 Kibibytes.=20 --=20 M=C3=A5ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE VICARIOUSLY experience some reason to LIVE!! --==========1771BCCEEA927B48A713========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFH2BrD02/pMZDM1cURArz9AJ0Wj+h9ezWv/koNfxYKzqrdXzHfQQCfZ7/T /tX8sZdDuP2sGcuEeeGQcS4= =KP2s -----END PGP SIGNATURE----- --==========1771BCCEEA927B48A713==========-- -- to unsubscribe send a message to namedroppers-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 Mar 12 13:57:41 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D223A69B3; Wed, 12 Mar 2008 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 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 echetewJvqYm; Wed, 12 Mar 2008 13:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B02673A6C8D; Wed, 12 Mar 2008 13:57:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXsZ-0005Mr-Pn for namedroppers-data@psg.com; Wed, 12 Mar 2008 20:48:51 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZXsW-0005M0-Rp for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 20:48:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8853111429 for ; Wed, 12 Mar 2008 20:48:48 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Wed, 12 Mar 2008 13:31:11 MST." References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 20:48:48 +0000 Message-ID: <28294.1205354928@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > ..., but I'd say numeric TLDs are just a bad idea. in the grand scheme of things i fear .EXE more than i fear .123, though. (which is just more proof, as if we needed any, that DNS's presentation layer is weakly defined and poorly implemented.) -- to unsubscribe send a message to namedroppers-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 Mar 12 14:26:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EB428C439; Wed, 12 Mar 2008 14:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.218, 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 S3k1B1zUNE87; Wed, 12 Mar 2008 14:26:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 974FF3A6A3A; Wed, 12 Mar 2008 14:26:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZYM7-000F74-6U for namedroppers-data@psg.com; Wed, 12 Mar 2008 21:19:23 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZYM1-000EuA-8w for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 21:19:19 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2CLHb28002368; Thu, 13 Mar 2008 04:17:44 +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 m2CLHkMv012471; Thu, 13 Mar 2008 04:17:58 +0700 (ICT) From: Robert Elz To: bert hubert cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: <20080312200232.GK10313@outpost.ds9a.nl> References: <20080312200232.GK10313@outpost.ds9a.nl> <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 2008 04:17:46 +0700 Message-ID: <12595.1205356666@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Wed, 12 Mar 2008 21:02:32 +0100 From: bert hubert Message-ID: <20080312200232.GK10313@outpost.ds9a.nl> | Should we map back everything we twiddled? Or should we trust stub resolvers | to be case insensitive? I don't think you should be doing this at all (as my previous message probably made clear), but if you have to, twiddle the question back as soon as you get (and have validated) the reply - before you expand the labels in other sections. kre -- to unsubscribe send a message to namedroppers-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 Mar 12 14:35:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC673A69EC; Wed, 12 Mar 2008 14:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 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 flHZEVPVmkah; Wed, 12 Mar 2008 14:35:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E14443A686A; Wed, 12 Mar 2008 14:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZYVZ-000HTr-D0 for namedroppers-data@psg.com; Wed, 12 Mar 2008 21:29:09 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZYVU-000HTB-LG for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 21:29:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CAC4C1142F; Wed, 12 Mar 2008 21:29:03 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Robert Elz cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Thu, 13 Mar 2008 03:43:24 +0700." <6689.1205354604@epsilon.noi.kre.to> References: <11334.1205330770@sa.vix.com> <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <6689.1205354604@epsilon.noi.kre.to> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 21:29:03 +0000 Message-ID: <29775.1205357343@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > From: Robert Elz > > From: Paul Vixie > > | 0x20 only contains one protocol change. > | i don't think it's controversial, or > > You mean the protocol change? That is, requiring unchanged question > section in the reply? yes. > That's fine, it's what I always kind of assumed was required anyway. that's good news. anybody else got a contrary opinion? ed suggested making that one bit of text into its own draft and progressing it directly. anybody opposed to that? > But the way you're proposing on using that? While it is very clever, even > cute, it is also downright evil. The a==A stuff that's in the DNS is truly > annoying, it should never have been done (though I understand why it was), > and it would be nice to be able to make it go away at some far distant > future point of time. > > Doing this case flipping trick, and actually having implementations use it > in the wild would mean we could never rid ourselves of that botch to the > protocol. there's no way to make this go away, ever, except with a new label type, whose definition will/would presumably be made to preclude this kind of evilness. > Further, this trick doesn't help at all for the single most important DNS > lookup that's ever done - the query for the root nameservers. Manage to > forge a reply to that one and none of the others matter. If anything, by > making others harder to forge replies for, but leaving this one untouched, > you'd be shifting attacks more in that direction, which I don't think would > be a useful result. of course. likewise hp.com is less secure than dec.com and so on. bad idea, bad design. except that it's better than nothing. to get actual security we should deploy Secure DNS aka DNSSEC. especially we should sign the root zone and distribute the key widely. > Last, it results in just plain ugly replies - in the context of AXFR I saw > some mention of name case preservation, and how label compression can make a > mess of this. I think it was marka who said that it's only in the context > of AXFR that anyone ever complains about this. I beg to differ - this bugs > me no end on ordinary queries, and you're proposing making it worse... since we seem to agree that copying the question is what everybody does and what everybody should keep doing and what should be clarified in the spec, then you appear to be arguing that responses ought not use this copied question as a compression pointer target. sounds fine to me, if i'm reading you correctly. perhaps an "unless it would lead to truncation that would not occur if the question section copied from the query were available as a compression pointer target" exemption, though in an increasingly EDNS0 world i'm not sure we need to worry much about this as much. if we uptake ed's suggestion (progress the responder-must-copy clarification separately) then perhaps that draft would be a good place to recommend the no-question-pointers logic as well. (trying to conserver RFC numbers here.) > Please put this trick in the "look ma, no hands" category - treat it as > something to marvel at, laugh at, and avoid like the plague. we can't. i'm already marvelling, i'm already laughing, but i'm not avoiding, and my lack of avoidance is completely within the spec. if a dns initiator implementor can improve security with this trick, and remain within spec, you can expect that some, if not many or all, will do so. as a practical matter, this cat was never in any bag. there's no basis on which to forbid this, nor any enforcement powers. further, and this is the part i brought up in the philly meeting yesterday, we just got our asses handed to us by amit klein, wrt PRNG state prediction. how many more times would we like this kind of thing to happen? should we wait until the next round of PRNG predictability attacks are described, before we decide whether and how to improve transaction level unpredictability? waiting for DNSSEC means waiting for the U S Government to decide whether to sign the root and who should hold the key. maybe that's tomorrow, maybe it's in 2012. we have a tuple . bernstein showed us how and why to randomize reqport. klein and many others have showed us how and why to randomize qid. rtt banding is one way to randomize the respaddr. more than one upstream-facing reqaddr may be required at some point, chosen at random. the 0x20 bletcherous seething hack from hell randomizes the qname. having just been through another qid scare, and not knowing when to expect DNSSEC for root and .COM (assuming we decide what has to be done about the CD bit, and that we deploy MSJ's key rollover, and NSEC3 proves to be deployable, and assuming USG sets ICANN free next year, and assuming ICANN uses its new freedom to sign the root zone, and assuming verisign can make a business case for signing .COM, and so on)... i want to see every randomizable element of the tuple actually get randomized. > kre vix > ps: a better thing to be spending time on might be to redefine the DNS > packet format, and fix lots of the issues that we currently have that are > caused by this - I suspect it can be done in a way (kind of like EDNS0) > whereby the query format would appear compatible with basic old DNS, but > would signal advanced capability - once that's done, the reply can be > whatever will work best - this could fix multiple queries in one packet, add > as many ID bits as could ever be useful, and whatever else needs doing. i'm not reading that kind of ambition among the audience at this stage. there may be a later stage, but right now i predict that we'll fight, mostly, as we stand. -- to unsubscribe send a message to namedroppers-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 Mar 12 15:02:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA2C3A6A68; Wed, 12 Mar 2008 15:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nonpKnQy+Tc8; Wed, 12 Mar 2008 15:02:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8428428C6CE; Wed, 12 Mar 2008 15:02:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZYuL-000OgM-Eu for namedroppers-data@psg.com; Wed, 12 Mar 2008 21:54:45 +0000 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZYuH-000OfB-N9 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 21:54:43 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id D90C7564002; Wed, 12 Mar 2008 22:54:40 +0100 (CET) Received: from stipula.dds.nl ([127.0.0.1]) by localhost (stipula.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05725-01; Wed, 12 Mar 2008 22:54:38 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stipula.dds.nl (Postfix) with ESMTP id C2338564008; Wed, 12 Mar 2008 22:54:36 +0100 (CET) Message-ID: <47D8511C.7080006@nlnetlabs.nl> Date: Wed, 12 Mar 2008 22:54:36 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Paul Vixie CC: Robert Elz , namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding References: <11334.1205330770@sa.vix.com> <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <6689.1205354604@epsilon.noi.kre.to> <29775.1205357343@sa.vix.com> In-Reply-To: <29775.1205357343@sa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/6219/Wed Mar 12 21:58:52 2008 on stipula.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: |> some mention of name case preservation, and how label compression can make a |> mess of this. | since we seem to agree that copying the question is what everybody does and | what everybody should keep doing and what should be clarified in the spec, | then you appear to be arguing that responses ought not use this copied | question as a compression pointer target. sounds fine to me, if i'm reading | you correctly. perhaps an "unless it would lead to truncation that would not | occur if the question section copied from the query were available as a | compression pointer target" exemption, though in an increasingly EDNS0 world | i'm not sure we need to worry much about this as much. | | if we uptake ed's suggestion (progress the responder-must-copy clarification | separately) then perhaps that draft would be a good place to recommend the | no-question-pointers logic as well. (trying to conserver RFC numbers here.) I would be against no-question-pointers text. It is perfectly ok for a (authority, cache) server to compress to the question section. The server can determine if it wants to do so (and if that smashes case). If you feel the need for text: Please note that the copied query name can differ in upper and lower case, and therefore its use as a compression target depends on the servers choices regarding compression. Advancing 'copy the question section into the reply bit-for-bit' is fine with me. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH2FEbkDLqNwOhpPgRAvIWAJ4qfRbklCPUILLMKeFfab73g34hJgCfSjQx EvcLkpUm6bwol7KuUvelxK0= =YyVA -----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 Mar 12 15:08:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E2F3A6B73; Wed, 12 Mar 2008 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.734 X-Spam-Level: X-Spam-Status: No, score=-3.734 tagged_above=-999 required=5 tests=[AWL=0.703, 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 XBS9shSaAY-p; Wed, 12 Mar 2008 15:08:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 767703A6A29; Wed, 12 Mar 2008 15:08:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZZ1Z-0000jG-04 for namedroppers-data@psg.com; Wed, 12 Mar 2008 22:02:13 +0000 Received: from [204.152.189.134] (helo=mail.virtualized.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZZ1V-0000iZ-5e for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 22:02:11 +0000 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id m2CLLLmE087078; Wed, 12 Mar 2008 13:21:21 -0800 (PST) (envelope-from drc@virtualized.org) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Paul Vixie In-Reply-To: <28294.1205354928@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: top-level domains (was Re: dns-0x20.txt) Date: Wed, 12 Mar 2008 15:02:01 -0700 References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> <28294.1205354928@sa.vix.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mar 12, 2008, at 1:48 PM, Paul Vixie wrote: >> ..., but I'd say numeric TLDs are just a bad idea. > > in the grand scheme of things i fear .EXE more than i fear .123, > though. So you must be terrified of .COM (and .PL and .SH and .INFO and ...). A fully numeric hostname is fundamentally ambiguous if top-level domains are allowed to be all-numeric -- it would make a parser writer's life much more complicated (not to mention breaking pretty much all existing software that does hostname lookups). I'm not sure I see why a domain name that happens to correspond to a file extension is that scary. Clicking on http://youranidiot.exe is far less scary to me that clicking on http:/// youranidiot.exe. What am I missing? Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 15:26:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E9628C7C5; Wed, 12 Mar 2008 15:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP09Tbdtgb6R; Wed, 12 Mar 2008 15:26:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 817F028C76E; Wed, 12 Mar 2008 15:26:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZZHH-0004S3-9V for namedroppers-data@psg.com; Wed, 12 Mar 2008 22:18:27 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZZHE-0004RV-NP for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 22:18:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5D02511425 for ; Wed, 12 Mar 2008 22:18:24 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: top-level domains (was Re: dns-0x20.txt) In-Reply-To: Your message of "Wed, 12 Mar 2008 15:02:01 MST." References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> <28294.1205354928@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 12 Mar 2008 22:18:24 +0000 Message-ID: <31621.1205360304@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > So you must be terrified of .COM (and .PL and .SH and .INFO and ...). no > ... > What am I missing? the most unreliable and insecure element in any computing system, and especially distributed computing systems, is the human. humans won't nec'ily click on something with .INFO on the end but they will, without hesitation, click on something with .EXE on the end of its name. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 15:44:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2B93A6A87; Wed, 12 Mar 2008 15:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVNO4bEihn0I; Wed, 12 Mar 2008 15:44:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CD3E3A6AAC; Wed, 12 Mar 2008 15:44:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZZZE-00086D-Rv for namedroppers-data@psg.com; Wed, 12 Mar 2008 22:37:00 +0000 Received: from [2001:df8:0:16:216:6fff:fe46:b75d] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZZYu-00071X-G7 for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 22:36:59 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m2CMTkHu003031; Thu, 13 Mar 2008 09:29:46 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803122229.m2CMTkHu003031@drugs.dv.isc.org> To: David Conrad Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: top-level domains (was Re: dns-0x20.txt) In-reply-to: Your message of "Wed, 12 Mar 2008 15:02:01 PDT." Date: Thu, 13 Mar 2008 09:29:46 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > On Mar 12, 2008, at 1:48 PM, Paul Vixie wrote: > >> ..., but I'd say numeric TLDs are just a bad idea. > > > > in the grand scheme of things i fear .EXE more than i fear .123, > > though. > > So you must be terrified of .COM (and .PL and .SH and .INFO and ...). > > A fully numeric hostname is fundamentally ambiguous if top-level > domains are allowed to be all-numeric -- it would make a parser > writer's life much more complicated (not to mention breaking pretty > much all existing software that does hostname lookups). I'm not sure > I see why a domain name that happens to correspond to a file extension > is that scary. Clicking on http://youranidiot.exe is far less scary > to me that clicking on http:/// > youranidiot.exe. > > What am I missing? It's also banned by RFC 1123. > > Regards, > -drc > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@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 Mar 12 16:51:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C80928C6E9; Wed, 12 Mar 2008 16:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=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 KWVAwv47QzAx; Wed, 12 Mar 2008 16:51:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5197028C6E8; Wed, 12 Mar 2008 16:51:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZab1-000PcK-Kr for namedroppers-data@psg.com; Wed, 12 Mar 2008 23:42:55 +0000 Received: from [204.152.189.134] (helo=mail.virtualized.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZaay-000PbX-RU for namedroppers@ops.ietf.org; Wed, 12 Mar 2008 23:42:54 +0000 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id m2CN1xmE087283; Wed, 12 Mar 2008 15:02:00 -0800 (PST) (envelope-from drc@virtualized.org) Cc: namedroppers@ops.ietf.org Message-Id: <78226D66-9641-47EE-A912-1EB967F1757B@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <31621.1205360304@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: top-level domains (was Re: dns-0x20.txt) Date: Wed, 12 Mar 2008 16:42:25 -0700 References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> <28294.1205354928@sa.vix.com> <31621.1205360304@sa.vix.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mar 12, 2008, at 3:18 PM, Paul Vixie wrote: >> So you must be terrified of .COM (and .PL and .SH and .INFO and ...). > > no But with the exception of .INFO, all of those extensions are executable on one system or another. Where do you (or rather, ICANN) draw the line? > the most unreliable and insecure element in any computing system, and > especially distributed computing systems, is the human. Of course. > humans won't > nec'ily click on something with .INFO on the end but they will, > without > hesitation, click on something with .EXE on the end of its name. Sorry, still confused. Users today click on "click here to have your machine compromised". I'm confused how the allocation of a host in a top-level domain that corresponds to an executable file extension increases the risk, particularly since browser hostname namespace and file name namespace are completely disjoint (even in IE). This isn't rhetorical: people have blasted ICANN because they have not disallowed EXE as a possible top-level domain. I don't understand the threat model that is exposed by the allocation of that TLD (if were to come to pass which I doubt). Namedroppers is probably not the best forum to be discussing this, so if anyone can clue me in as to why this would doom the Internet (so to speak), please tell me privately. Thanks, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 17:16:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916BF3A6AD1; Wed, 12 Mar 2008 17:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[AWL=0.984, 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 ZNGCKhVglk4Z; Wed, 12 Mar 2008 17:16:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FBA73A67B3; Wed, 12 Mar 2008 17:16:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZazw-0007hG-TW for namedroppers-data@psg.com; Thu, 13 Mar 2008 00:08:40 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZazs-0007g4-A2 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 00:08:39 +0000 Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZazn-000Kwc-6m; Thu, 13 Mar 2008 00:08:32 +0000 Cc: Paul Vixie , namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: David Conrad In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: top-level domains (was Re: dns-0x20.txt) Date: Wed, 12 Mar 2008 20:08:28 -0400 References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> <28294.1205354928@sa.vix.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 12-Mar-2008, at 18:02, David Conrad wrote: > A fully numeric hostname is fundamentally ambiguous if top-level > domains are allowed to be all-numeric -- it would make a parser > writer's life much more complicated (not to mention breaking pretty > much all existing software that does hostname lookups). s/complicated/intractable/, at least in extreme cases. $ORIGIN 4. 199.212.90 A 199.212.90.6 When faced with the string of characters "199.212.90.4", should the result be the IP address 199.212.90.4, or the A record corresponding to the DNS name "199.212.90.4", i.e. 199.212.90.6? I suppose it's fair to say that anybody who configured such a thing and ran into trouble probably already has feet full of holes. The reverse tree would look fun, though ;-) $ORIGIN 90.212.199.in-addr.arpa. ;4 unassigned, kind of, maybe 6 PTR 199.212.90.4. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 17:22:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A119528C49F; Wed, 12 Mar 2008 17:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.178 X-Spam-Level: X-Spam-Status: No, score=0.178 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 Gtbr6+WATo9u; Wed, 12 Mar 2008 17:22:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C28D73A6B05; Wed, 12 Mar 2008 17:22:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZb6j-0009BF-Sv for namedroppers-data@psg.com; Thu, 13 Mar 2008 00:15:41 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZb6h-0009AL-06 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 00:15:40 +0000 Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZb6b-000Kxi-VA; Thu, 13 Mar 2008 00:15:34 +0000 Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: Pekka Savola 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 v919.2) Subject: Re: DNS is mandatory text Date: Wed, 12 Mar 2008 20:15:32 -0400 References: <200803120332.m2C3WlBU084335@ogud.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 12-Mar-2008, at 08:51, Pekka Savola wrote: > If we want to mandate EDNS0 to be part of every compliant DNS > implementation, I believe we should put that requirement in the > upcoming profile or other BCP/standards track document (which in > turn the vendor could claim to implement or not). I actually like the idea of making the statement in the EDNS0bis document, and marking that document as "standards track; updates RFC 1035". That way people who claim to support 1034/1035 (or who undertake to provide such support) might be guided towards the light. Including the sentiment in the profile document also seems sensible, however. As to the original question, it seems sensible to me that DNS software and services MUST support EDNS0, insofar as an IETF MUST ever has any meaning outside the scope of standards development. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 20:03:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FD73A6801; Wed, 12 Mar 2008 20:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=0.191, 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 9lhYnGjkYmkl; Wed, 12 Mar 2008 20:03:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83C583A68E1; Wed, 12 Mar 2008 20:03:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdaX-000KQY-Bf for namedroppers-data@psg.com; Thu, 13 Mar 2008 02:54:37 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdaS-000KPI-Fs for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 02:54:35 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2D2qtdC006036; Thu, 13 Mar 2008 09:52:56 +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 m2D2r0Zs004244; Thu, 13 Mar 2008 09:53:02 +0700 (ICT) From: Robert Elz To: Joe Abley cc: David Conrad , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: top-level domains (was Re: dns-0x20.txt) In-Reply-To: References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> <28294.1205354928@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 2008 09:53:00 +0700 Message-ID: <5096.1205376780@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Wed, 12 Mar 2008 20:08:28 -0400 From: Joe Abley Message-ID: | s/complicated/intractable/, at least in extreme cases. Only if you assume no tool redesign. But that's already required for v6, where addresses can look more like names (especially when used in contexts where ':' is legal syntax, eg: URL's). All you're saying is that if all numeric TLDs existed (which isn't very likely at all) then applications would need a UI method to allow the user to specify "this is an address" as distinct from "this is a name", and would need to avoid the "see what it smells like" test they currently do (often without thought, hidden in the name->address translation routine). The 1123 ban on all numeric TLDs isn't because they're evil or impossible or anything like that, it was just a nod to the practical realities of the implementations of the day (and still.) It could be altered with sufficient (ie: decades) of advance notice, if there was ever a good enough reason to do so. Its the latter hurdle that seems like the bigger issue. kre -- to unsubscribe send a message to namedroppers-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 Mar 12 20:04:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0808F3A68C6; Wed, 12 Mar 2008 20:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 UIYe5XB-9Y+z; Wed, 12 Mar 2008 20:04:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 599193A692F; Wed, 12 Mar 2008 20:04:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdZb-000KFt-LB for namedroppers-data@psg.com; Thu, 13 Mar 2008 02:53:39 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdZY-000KF8-Uv for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 02:53:38 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4525732E7A; Thu, 13 Mar 2008 03:53:34 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id D74061576FE; Wed, 12 Mar 2008 22:46:32 -0400 (EDT) Date: Wed, 12 Mar 2008 22:46:32 -0400 From: Stephane Bortzmeyer To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: top-level domains (was Re: dns-0x20.txt) Message-ID: <20080313024632.GA10132@laperouse.bortzmeyer.org> References: <200803122229.m2CMTkHu003031@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803122229.m2CMTkHu003031@drugs.dv.isc.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Thu, Mar 13, 2008 at 09:29:46AM +1100, Mark Andrews wrote a message of 40 lines which said: > It's also banned by RFC 1123. Chapter and verse, please. There is just a difficult-to-parse sentence in section 2.1. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 20:06:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6B53A68E1; Wed, 12 Mar 2008 20:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 Cs3KhHpWiMx2; Wed, 12 Mar 2008 20:06:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16D1C3A68C6; Wed, 12 Mar 2008 20:06:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdgR-000M3I-IH for namedroppers-data@psg.com; Thu, 13 Mar 2008 03:00:43 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdgN-000M2A-Sr for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 03:00:41 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A11D832E7A; Thu, 13 Mar 2008 04:00:37 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id D93B31576FE; Wed, 12 Mar 2008 22:54:21 -0400 (EDT) Date: Wed, 12 Mar 2008 22:54:21 -0400 From: Stephane Bortzmeyer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Message-ID: <20080313025421.GB10132@laperouse.bortzmeyer.org> References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <11334.1205330770@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11334.1205330770@sa.vix.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 02:06:10PM +0000, Paul Vixie wrote a message of 70 lines which said: > is there really any controversy around 0x20, that make it ineligible for an > almost instant WGLC? Call me a sissie but, for me, a two-weeks test at one site is not enough, taking into account that it is a (potentially) incompatible protocol change and that there is a wide variety of DNS stuff in the wild. -- to unsubscribe send a message to namedroppers-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 Mar 12 20:09:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD15D3A6953; Wed, 12 Mar 2008 20:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=0.170, 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 AlTbMDI2yCzv; Wed, 12 Mar 2008 20:09:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 414713A67FF; Wed, 12 Mar 2008 20:09:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdiI-000MPv-Rw for namedroppers-data@psg.com; Thu, 13 Mar 2008 03:02:38 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZdiF-000MLh-4i for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 03:02:37 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2D31ETC022646; Thu, 13 Mar 2008 10:01:14 +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 m2D31api005160; Thu, 13 Mar 2008 10:01:36 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: <29775.1205357343@sa.vix.com> References: <29775.1205357343@sa.vix.com> <11334.1205330770@sa.vix.com> <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <6689.1205354604@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 2008 10:01:36 +0700 Message-ID: <4308.1205377296@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Wed, 12 Mar 2008 21:29:03 +0000 From: Paul Vixie Message-ID: <29775.1205357343@sa.vix.com> | there's no way to make this go away, ever, except with a new label type, | whose definition will/would presumably be made to preclude this kind of | evilness. Not true, there's nothing in the DNS currently (before your draft) which is depending upon this "feature" - sure, implementations have to handle it, but nothing is relying upon its existance (not in the DNS itself). Thus, it can be changed. It would take a very long time, and a process of smaller steps, but it could be done. It cannot be if we start to actually rely upon it however, so that's what I'd suggest should not be done. | of course. likewise hp.com is less secure than dec.com and so on. | bad idea, bad design. except that it's better than nothing. I actually disagree. I think it is worse than nothing, as it points the attacks at the worst possible place - that is, it motivates attacking the place where most damage would be caused. | since we seem to agree that copying the question is what everybody does and | what everybody should keep doing and what should be clarified in the spec, | then you appear to be arguing that responses ought not use this copied | question as a compression pointer target. No. Though I wouldn't object to one that didn't. | we can't. i'm already marvelling, i'm already laughing | but i'm not avoiding, and my lack of avoidance is completely within | the spec. The place to start on eliminating (ascii only) case independance would be to issue a spec that requires resolvers to always look up the exact name passed (no case conversions, ever.) Aside from your hack, that's what resolvers (that I know of) do now anyway, so perhaps we should start with that, today. Then you'd no longer be within spec... kre -- to unsubscribe send a message to namedroppers-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 Mar 12 20:34:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BC728C747; Wed, 12 Mar 2008 20:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 hB0orQiAU-19; Wed, 12 Mar 2008 20:34:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4236628C749; Wed, 12 Mar 2008 20:34:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZe5j-0003ey-By for namedroppers-data@psg.com; Thu, 13 Mar 2008 03:26:51 +0000 Received: from [199.6.1.65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZe5f-0003eL-Tb for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 03:26:49 +0000 Received: from farside.isc.org (farside.isc.org [204.152.187.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 641B44AC92 for ; Thu, 13 Mar 2008 03:25:48 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id ADF73E60AD for ; Thu, 13 Mar 2008 03:18:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m2CMTkHu003031; Thu, 13 Mar 2008 09:29:46 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803122229.m2CMTkHu003031@drugs.dv.isc.org> To: David Conrad Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: top-level domains (was Re: dns-0x20.txt) In-reply-to: Your message of "Wed, 12 Mar 2008 15:02:01 PDT." Date: Thu, 13 Mar 2008 09:29:46 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > On Mar 12, 2008, at 1:48 PM, Paul Vixie wrote: > >> ..., but I'd say numeric TLDs are just a bad idea. > > > > in the grand scheme of things i fear .EXE more than i fear .123, > > though. > > So you must be terrified of .COM (and .PL and .SH and .INFO and ...). > > A fully numeric hostname is fundamentally ambiguous if top-level > domains are allowed to be all-numeric -- it would make a parser > writer's life much more complicated (not to mention breaking pretty > much all existing software that does hostname lookups). I'm not sure > I see why a domain name that happens to correspond to a file extension > is that scary. Clicking on http://youranidiot.exe is far less scary > to me that clicking on http:/// > youranidiot.exe. > > What am I missing? It's also banned by RFC 1123. > > Regards, > -drc > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 03:41:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D6328C729; Thu, 13 Mar 2008 03:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1, 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 hI+i+JkxcLe9; Thu, 13 Mar 2008 03:41:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2CB0128C748; Thu, 13 Mar 2008 03:41:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZkeR-000IbA-5e for namedroppers-data@psg.com; Thu, 13 Mar 2008 10:27:07 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZkeL-000IYa-An for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 10:27:05 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JZkeF-0008En-50 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 11:26:55 +0100 Received: from fweimer by bfk.de with local id 1JZkeG-0001SZ-NK for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 11:26:56 +0100 To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> From: Florian Weimer Date: Thu, 13 Mar 2008 11:26:56 +0100 In-Reply-To: <16130.1205337563@sa.vix.com> (Paul Vixie's message of "Wed, 12 Mar 2008 15:59:23 +0000") Message-ID: <82r6eeyl5b.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: DNSEXT discussion * Paul Vixie: >> ... The 0x20 material is probably quite controversial, and >> BCP 79 issues may still turn up. > > do tell. i havn't seen or heard any controversy yet, People have begun putting out press statements opposing 0x20. I hope you aren't too surprised. > just misunderstandings because the draft's text is sloppy or > inadequate, and folks saying it's ugly, and folks saying why waste > effort on this if we believe in dnssec long term. I like the idea, and I think it might work reasonably well, but it's technically a backwards-incompatible protocol change. Anyway, I would welcome almost *anything* which improves DNS security and is deployable in the short term. Extrapolating from the bits of data I've got, I estimate that we will see large-scale attempts at cache poisoning at a few major ISPs in two or three years. Even if those attacks do not succeed in injecting bad data, the denial of service aspect alone is worrisome. > i know of very few places where a caching recursive nameserver > speaks through middleboxes when reaching authority servers. It's a policy issue in a few places, I assume. Everything has to pass through firewalls and stuff. People would run BGP across the IPS if it they only could connect their WAN links to the IPS. 8-P > 0x20 is definitely not middlebox safe, which is why i don't > recommend it for stub resolver use. And how is this not a show-stopper for a global configuration switch in the name server, when you can't know the location of middleboxes? On the other hand, these middleboxes need to be fixed for DNSSEC as well, so this needs to be worked out anyway. But I'm very much in favor of anything that gets us out of the current state, which is so firmly focused on discouraging innovation. --=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 Mar 13 03:43:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24CD3A6D87; Thu, 13 Mar 2008 03:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.859 X-Spam-Level: X-Spam-Status: No, score=0.859 tagged_above=-999 required=5 tests=[AWL=0.109, 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 yX-mJuYhfk0i; Thu, 13 Mar 2008 03:42:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 074E928C79B; Thu, 13 Mar 2008 03:42:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZkjn-000KpJ-JA for namedroppers-data@psg.com; Thu, 13 Mar 2008 10:32:39 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZkja-000Kkw-Fa for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 10:32:33 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JZkjW-00008v-2q; Thu, 13 Mar 2008 11:32:22 +0100 Received: from fweimer by bfk.de with local id 1JZkjX-0003HT-Rg; Thu, 13 Mar 2008 11:32:23 +0100 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding References: <57450.1205256926@sa.vix.com> From: Florian Weimer Date: Thu, 13 Mar 2008 11:32:23 +0100 In-Reply-To: (Edward Lewis's message of "Wed, 12 Mar 2008 14:09:17 -0400") Message-ID: <82iqzqykw8.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: DNSEXT discussion * Edward Lewis: > 3) Is something that needn't be defined in a standard (much the same > way resolvers choose authoritative servers. Huh? Even if they are not suitable implementation guidance, standards are an important help while deciding how to fix things that do not work as expected. If there's a standard that requires case preservation, it's difficult to argue that case normalization is kosher. --=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 Mar 13 04:01:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE7A3A6DFE; Thu, 13 Mar 2008 04:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.832 X-Spam-Level: X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[AWL=0.082, 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 WoUGfBytBVFE; Thu, 13 Mar 2008 04:01:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF4343A6DB3; Thu, 13 Mar 2008 04:01:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZl4C-0003dY-KJ for namedroppers-data@psg.com; Thu, 13 Mar 2008 10:53:44 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZl42-0003Vo-1s for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 10:53:43 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JZl3v-0001Kj-8w; Thu, 13 Mar 2008 11:53:27 +0100 Received: from fweimer by bfk.de with local id 1JZl3x-0001r5-1a; Thu, 13 Mar 2008 11:53:29 +0100 To: David Dagon Cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt References: <69903.1204047792@sa.vix.com> <20080312151126.GC25631@fritz.cc.gt.atl.ga.us> From: Florian Weimer Date: Thu, 13 Mar 2008 11:53:28 +0100 In-Reply-To: <20080312151126.GC25631@fritz.cc.gt.atl.ga.us> (David Dagon's message of "Wed, 12 Mar 2008 11:11:26 -0400") Message-ID: <827ig6yjx3.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: DNSEXT discussion * David Dagon: > The question "When is there enough entropy to be safe?" always has a > subjective answer, and I think we'd all like something much larger > than 2^{40ish}. Exponential growth is punishing above a threshold and > DNS-0x20, while not the cure, does get one closer. One interesting thing about those 0x20 bits is that you don't have to worry about uniqueness, so you can use a real PRNG to generate them, instead of the likely-vulnerable LCG cruft that is found in most resolvers. > Re: the lack of harm: I'm not aware of any applications monitoring > recursive-to-authority traffic that would be negatively affected by > 0x20 flipping. I imagine that there are in-line devices that perform case normalization because the 0x20 bits can be seen as a covert channel. I hope to do some tests next week (or probably the week after that, to avoid influencing otther measurements) to see if such devices are in front of any authoritative servers. --=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 Mar 13 06:29:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6243A6856; Thu, 13 Mar 2008 06:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8Zp8Why4O8g; Thu, 13 Mar 2008 06:29:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 178DD28C72D; Thu, 13 Mar 2008 06:29:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZnJh-000Loq-6j for namedroppers-data@psg.com; Thu, 13 Mar 2008 13:17:53 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZnJU-000Lmf-38 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 13:17:47 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [213.154.224.58]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2DDHVGd053542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 14:17:35 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47D9296B.60806@nlnetlabs.nl> Date: Thu, 13 Mar 2008 14:17:31 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Namedroppers CC: Bert Hubert , remco@virtu.nl Subject: dnsext-forgery-resilience-02 X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 13 Mar 2008 14:17:35 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A review of draft-ietf-dnsext-forgery-resilience-02.txt Overall, the direction of the document is a good thing. And security is increased by following recommendations. But the tone, and wording I do not agree with, and are used too broadly (see below). I think this document is better off as a BCP or for-your-information document, than as a standards track. It recommends best use for getting forgery resilience, without specifying protocol elements. Therefore, from the Abstract, the third paragraph should be removed. (By describing ... updates RFC 1034). section 2 says ~ It should be noted that the most commonly used resolver currently ~ does not perform as well as possible in this respect, making this ~ document of urgent importance. Look, bashing some implementation is not very nice. If you want someone to implement, ask them. Reword to 'most resolvers do not perform well'. section 3 says ~ 5. It is the first answer to match the previous four conditions. I think point 5 should be removed. There are no rules preventing you from accepting a later response, and I do not want this document to make one. Section 4.3 Matching the source address of the authentic answer This is an obvious place to mention the banding-RTT idea. I cannot provide text for it, because I do know know it fully yet. So, I would appreciate text about the RTT banding here to fixup! 4.5 says ~ Once any packet has matched the previous four conditions, no further ~ answers should be accepted. Again, I do not think a rule against listening for multiple answers should be advocated, it is even against the spirit of this document (forgery resilience). Reword to Most resolvers accept the first packet to match the conditions, and no further answers are accepted. 4.5 also says ~ This means that the third party has a limited time in which to inject ~ its spoofed answer, typically in the order of at most 100ms. Should say that the time you have depends on the speed with which the authority server is responding. This means also that by choosing a faster authority server the time window for a spoof attack is decreased. And this is at odds with the rtt-banding idea (I think). I think this conceptual tradeoff needs to be documented. 5. Birthday attacks, says ~ An attacker can benefit from this exact phenomenon if it can force ~ the target resolver to have multiple outstanding questions at any one ~ time for the same domain to the same authoritative server. Shouldn't those be the same questions? Or does this also hold when there are multiple, different questions outstanding at one time for the same zone to the same authoritative server? 9. Countermeasures, says ~ Additionally, resolver implementations MUST have the ability to: I believe these are recommendations for resilience. I disagree with MUST. Change to 'are more resilient if they have the ability to:' and says ~ (53, or > 1024) of ports that is as large as possible; as large as possible is not good. Grabbing every possible port is a denial of service attack on the server itself, for having ports for other purposes. I.e. with 65000 outstanding queries, this is not a good recommendation. Instead, recommend that a larger range of ports results in more spoof resilience. And the tradeoff with other port usage can then be made. It says: ~ o Assure that its choices of port and ID cannot be predicted by an ~ attacker having knowledge of its (pseudo-)random generator. I do not believe an implementation can have an ability to assure its ID choices cannot be predicted. Including a rng-breaking test into the resolver implementation is not helpful. Instead recommend to use a (pseudo)random generator to generate ID and port choices that is hard to predict. It says ~ If a resolver sends out multiple equivalent questions to any ~ authoritative server, before receiving an answer, all MUST have ~ identical ID, source address and source port. Again, I disagree with the MUST. For example; not reply at all is received. Then the next day another same query comes in from a client - and a new outgoing query is sent to the server - this can reuse the same ID, but can also be a new random ID. It is senseless to keep track of the IDs for all failed queries for which there has been no answer. Also MUST language is inappropriate I think. The protocol is not harmed. Make a recommendation for resilience: Having multiple queries outstanding at the same time to a server with different IDs is not good for resiliency. The recommendation is to not have this happen, the same ID can be used. Then follow two uses of SHOULD. I disagree with SHOULD. Instead make a recommendation for resiliency. It is more resilient to use an authoritative server with a trust relationship. It is more resilient for stub resolvers to use TSIG or IPSEC when communicating with their recursive resolver. 10. security considerations. I think that this document is almost completely useless when DNSSEC is deployed. It may save some calculation by being able to throw away spoofed packets, but the spoofing is not a DoS risk at this point. Therefore, the benefit is minimal, in the sense that response time in the presence of spoofing is better. As such, the urgency when DNSSEC is in use of all the above suggestions is also low. This is another reason why uppercase MUST and SHOULD is not appropriate in this document. It says ~ A resolver that does not implement the recommendations outlined above ~ can easily be forced to accept Well, this is a function of implementation, but also the operational choices by the operator that configures the resolver, i.e. if it is implemented but turned off. As such, maybe an operational recommendation is better. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH2SlrkDLqNwOhpPgRAv4wAJ4hx6lu5UeJQWYrg+9Ob60Kz5lSgwCdEP7R Gecf3r3bMqneuQxoV9iBKy4= =cS5M -----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 Mar 13 06:51:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55AB3A6E6B; Thu, 13 Mar 2008 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN1cGgAxoXOK; Thu, 13 Mar 2008 06:51:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B6653A6E35; Thu, 13 Mar 2008 06:50:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZndW-0000oP-4q for namedroppers-data@psg.com; Thu, 13 Mar 2008 13:38:22 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZncO-0000WR-4d for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 13:37:24 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2DDb1wU023913; Thu, 13 Mar 2008 15:37:01 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2DDb1BB023909; Thu, 13 Mar 2008 15:37:01 +0200 Date: Thu, 13 Mar 2008 15:37:01 +0200 (EET) From: Pekka Savola To: =?ISO-8859-15?Q?M=E5ns_Nilsson?= cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text In-Reply-To: <6D8BC8C8C396B565270BA236@90273E0ED7A6C4458FE339F4> Message-ID: References: <200803120332.m2C3WlBU084335@ogud.com> <6D8BC8C8C396B565270BA236@90273E0ED7A6C4458FE339F4> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1229587918-1205415421=:22650" X-Virus-Scanned: ClamAV 0.92.1/6220/Thu Mar 13 00:33:03 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1229587918-1205415421=:22650 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Wed, 12 Mar 2008, Måns Nilsson wrote: >> ENDS0bis draft include words that made EDNS0 mandatory. >> The sense of the room was that this was reasonable, even though it will >> cause some problems. >> I (personally) have the feeling this is a question of short intense pain >> vs long dull pain. > > I think this is a good idea. The interop issues when stuff (like firewalls) > don't grok EDNS0 and don't correctly signal this (making smooth downgrade > impossible) are irritating enough. It might only be usable as a larger > mallet on vendors, but that is sufficient for me. So, would the implication of this be that we don't need to make EDNS0bis to work "in the real world" (i.e., by providing sane fallback mechanisms if someone doesn't support it)? I'm strongly opposed to EDNS0 mandate if the implication would be that DNS protocol does not work in the presence of no or incorrect support. So, if we have a MUST support, we need to have MUST requirements for useful fallback mechanisms to work even in the presence of an incompliant (and legacy) implementations. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1229587918-1205415421=:22650-- -- to unsubscribe send a message to namedroppers-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 Mar 13 06:51:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6337B3A684F; Thu, 13 Mar 2008 06:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 6xycMwSCIjN0; Thu, 13 Mar 2008 06:51:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F05B3A6E5D; Thu, 13 Mar 2008 06:51:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZngO-0001Ve-2o for namedroppers-data@psg.com; Thu, 13 Mar 2008 13:41:20 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZnfZ-0001IJ-7n for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 13:40:42 +0000 Received: from [10.150.135.39] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2DDeG1r009218; Thu, 13 Mar 2008 09:40:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <82iqzqykw8.fsf@mid.bfk.de> References: <57450.1205256926@sa.vix.com> <82iqzqykw8.fsf@mid.bfk.de> Date: Thu, 13 Mar 2008 09:39:38 -0400 To: Florian Weimer From: Edward Lewis Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 11:32 +0100 3/13/08, Florian Weimer wrote: >* Edward Lewis: > >> 3) Is something that needn't be defined in a standard (much the same >> way resolvers choose authoritative servers. > >Huh? Even if they are not suitable implementation guidance, standards >are an important help while deciding how to fix things that do not >work as expected. If there's a standard that requires case >preservation, it's difficult to argue that case normalization is >kosher. IETF standards are written with the goal of achieving interoperability. The element of 0x20 that has a concern about interoperability is addressed in my comment #1. What #3 refers to is how the local side (of the message exchange) twists the bits for it's own benefit, that is not an interoperability related issue. Note that I used the word "standard" and not the word "document" in #3. It would be fine and dandy to see this bit twiddling documented in a BCP or informational document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 13 07:11:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E62C28C833; Thu, 13 Mar 2008 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 0FOVrZTEeODV; Thu, 13 Mar 2008 07:11:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9186928C939; Thu, 13 Mar 2008 07:09:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZnzU-0006EW-A6 for namedroppers-data@psg.com; Thu, 13 Mar 2008 14:01:04 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZnyr-000672-N6 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 14:00:43 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8EC2531D31; Thu, 13 Mar 2008 15:00:23 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 436611575E8; Thu, 13 Mar 2008 09:57:19 -0400 (EDT) Date: Thu, 13 Mar 2008 09:57:19 -0400 From: Stephane Bortzmeyer To: Wouter Wijngaards Cc: Namedroppers , Bert Hubert , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 Message-ID: <20080313135719.GA23918@laperouse.bortzmeyer.org> References: <47D9296B.60806@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D9296B.60806@nlnetlabs.nl> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Thu, Mar 13, 2008 at 02:17:31PM +0100, Wouter Wijngaards wrote a message of 138 lines which said: > It says: > ~ o Assure that its choices of port and ID cannot be predicted by an > ~ attacker having knowledge of its (pseudo-)random generator. > I do not believe an implementation can have an ability to assure its ID > choices cannot be predicted. Including a rng-breaking test into the > resolver implementation is not helpful. Instead recommend to use a > (pseudo)random generator to generate ID and port choices that is hard to > predict. That's what the first versions of the draft were saying (I suggested also to add a reference to RFC 4086) and I believe the general consensus was that it was bad to recommend a technique, (pseudo-)random generation, instead of a goal, unpredictability. Check the archives. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 07:12:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8954228C808; Thu, 13 Mar 2008 07:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK8x0Twn8VdR; Thu, 13 Mar 2008 07:12:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFCE528C7E0; Thu, 13 Mar 2008 07:10:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZo1j-0006n3-FZ for namedroppers-data@psg.com; Thu, 13 Mar 2008 14:03:23 +0000 Received: from [2a01:280:1:1:208:2ff:fe25:3979] (helo=bardisk.kthnoc.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZo1N-0006fm-Gd for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 14:03:14 +0000 Received: from rasmus.kthnoc.net (rasmus.kthnoc.net [192.36.250.140]) (authenticated bits=0) by bardisk.kthnoc.net (8.14.1/8.13.6) with ESMTP id m2DE2oMi001599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 15:02:50 +0100 (CET) (envelope-from mansaxel@kthnoc.net) Date: Thu, 13 Mar 2008 15:02:39 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: Pekka Savola cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text Message-ID: <6B1600909C6BE0AD714DE11B@rasmus.kthnoc.net> In-Reply-To: References: <200803120332.m2C3WlBU084335@ogud.com> <6D8BC8C8C396B565270BA236@90273E0ED7A6C4458FE339F4> X-Mailer: Mulberry/4.0.9b1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========FFF0F791C1C59F65C44A==========" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --==========FFF0F791C1C59F65C44A========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On torsdag, torsdag 13 mar 2008 15.37.01 +0200 Pekka Savola wrote: > So, would the implication of this be that we don't need to make EDNS0bis > to work "in the real world" (i.e., by providing sane fallback mechanisms > if someone doesn't support it)? I do not advocate that legacy stuff should stop sending FORMERR and NOTIMP when they don't grok EDNS.=20 > I'm strongly opposed to EDNS0 mandate if the implication would be that > DNS protocol does not work in the presence of no or incorrect support. I would say that DNS, where we are taking it (DNSSEC etc), works less well without, and thus it would be good to increase the pressure on vendors to supply ENDS capable solutions.=20 =20 > So, if we have a MUST support, we need to have MUST requirements for > useful fallback mechanisms to work even in the presence of an incompliant > (and legacy) implementations. Of course. Even if we wish to, we can't remove all the broken middle boxes out there. But at the hot spots, where such boxes cause the most pain, we could perhaps supply writings to make upgrade resistance softer.=20 --=20 M=C3=A5ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE Look into my eyes and try to forget that you have a Macy's charge card! --==========FFF0F791C1C59F65C44A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFH2TP/02/pMZDM1cURAhDBAJ9W/tr4YHxKMmcpBCSx2tCjrD/9owCfUATF 8FkDHAE1zzL6l3rZC5qZoAc= =BkTz -----END PGP SIGNATURE----- --==========FFF0F791C1C59F65C44A==========-- -- to unsubscribe send a message to namedroppers-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 Mar 13 07:42:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFBD3A6CD1; Thu, 13 Mar 2008 07:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTN4p35juqLs; Thu, 13 Mar 2008 07:42:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DB0D3A6E30; Thu, 13 Mar 2008 07:42:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZoS2-000Dmo-Ds for namedroppers-data@psg.com; Thu, 13 Mar 2008 14:30:34 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZoRV-000DaB-PB for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 14:30:08 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [213.154.224.58]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2DETsis060054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 15:29:54 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47D93A62.90109@nlnetlabs.nl> Date: Thu, 13 Mar 2008 15:29:54 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Namedroppers , Bert Hubert , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 References: <47D9296B.60806@nlnetlabs.nl> <20080313135719.GA23918@laperouse.bortzmeyer.org> In-Reply-To: <20080313135719.GA23918@laperouse.bortzmeyer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 13 Mar 2008 15:29:54 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Bortzmeyer wrote: | On Thu, Mar 13, 2008 at 02:17:31PM +0100, | Wouter Wijngaards wrote | a message of 138 lines which said: | |> It says: |> ~ o Assure that its choices of port and ID cannot be predicted by an |> ~ attacker having knowledge of its (pseudo-)random generator. |> I do not believe an implementation can have an ability to assure its ID |> choices cannot be predicted. Including a rng-breaking test into the |> resolver implementation is not helpful. Instead recommend to use a |> (pseudo)random generator to generate ID and port choices that is hard to |> predict. | | That's what the first versions of the draft were saying (I suggested | also to add a reference to RFC 4086) and I believe the general | consensus was that it was bad to recommend a technique, | (pseudo-)random generation, instead of a goal, unpredictability. Check | the archives. Well I agree with that, but I am saying something else. The draft is saying the implementation must assure that its choices ... Instead, better text is. The implementation is more resilient when the ID and port numbers are more unpredictable. What assurance can an implementation give? Must they be digitally signed by a trusted 3rd party? (that is what I can read in the current draft text). Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH2TpikDLqNwOhpPgRApTbAJsFqNnrCp9cvwEPxPMk/r0jdN952ACeKYho mgTeBpcO7veqTdwY9Z4/Glc= =IB2/ -----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 Mar 13 08:08:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C16E3A6D03; Thu, 13 Mar 2008 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.815 X-Spam-Level: X-Spam-Status: No, score=0.815 tagged_above=-999 required=5 tests=[AWL=0.066, 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 9brAwSl-FFKA; Thu, 13 Mar 2008 08:08:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 118C43A6CB1; Thu, 13 Mar 2008 08:08:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZouX-000Mob-6Q for namedroppers-data@psg.com; Thu, 13 Mar 2008 15:00:01 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZoss-000M8c-GJ for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 14:59:06 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JZosl-0006IU-AY; Thu, 13 Mar 2008 15:58:11 +0100 Received: from fweimer by bfk.de with local id 1JZosn-0007Eb-6U; Thu, 13 Mar 2008 15:58:13 +0100 To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text References: <200803120332.m2C3WlBU084335@ogud.com> From: Florian Weimer Date: Thu, 13 Mar 2008 15:58:13 +0100 In-Reply-To: <200803120332.m2C3WlBU084335@ogud.com> (Olafur Gudmundsson's message of "Tue, 11 Mar 2008 23:31:54 -0400") Message-ID: <823aquwu0q.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: DNSEXT discussion * Olafur Gudmundsson: > As number of uses of DNS require larger answers than can be easily > fit in 512 byte answers, it makes sense to require modern DNS > software to implement EDNS0. Makes sense, I agree. > Thus Authorative servers, Recursive Resolvers, Stub-resolver and > middle-ware boxes speaking DNS in any form MUST implement ENDS0 and > MUST support buffer size of at least 2K. Why 2K? Why not 4K or 1.2K? --=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 Mar 13 11:28:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6EB3A6E59; Thu, 13 Mar 2008 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q06aBwo0c-OO; Thu, 13 Mar 2008 11:28:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AB813A695B; Thu, 13 Mar 2008 11:28:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZry6-000KW4-7c for namedroppers-data@psg.com; Thu, 13 Mar 2008 18:15:54 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZrxz-000KUL-Di for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 18:15:52 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JZrxv-0004k7-Ij; Thu, 13 Mar 2008 19:15:43 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id AA85444EE; Thu, 13 Mar 2008 19:15:48 +0100 (CET) Date: Thu, 13 Mar 2008 19:15:48 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: dns-0x20 mismatches Message-ID: <20080313181548.GS10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21844.1205345387@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Mar 12, 2008 at 06:09:47PM +0000, Paul Vixie wrote: > so, practically speaking, the fact that i've not run into any non-copiers in > a few million upstream transactions, means that further testing is illuminative > but not decisive. I think my test data is a bit broader - after 40000 queries out of my 2 billion or so, I have: 19:06:19 Case mismatch '66.249.93.9' A: 'maPs.l.gOoglE.COM.' != 'maps.l.google.com.' 19:06:19 Case mismatch '66.249.93.9' A: 'MaPS.l.gOOgLE.COM.' != 'maps.l.google.com.' 19:06:20 Case mismatch '211.79.207.26' A: 'MoEVaX.Edu.tW.' != 'moevax.edu.tw.' 19:06:20 Case mismatch '216.102.246.43' AAAA: 'noEmAIL.Com.' != 'noemail.com.' 19:06:29 Case mismatch '64.233.161.9' A: 'ytIMg.l.GOOgLE.cOM.' != 'ytimg.l.google.com.' 19:06:29 Case mismatch '64.233.161.9' A: 'YTIMG.L.goOGle.COm.' != 'ytimg.l.google.com.' 19:06:31 Case mismatch '211.79.207.26' A: '123-240-206-152.CCTV.dyNAMIc.lsc.neT.tw.' != '123-240-206-152.cctv.dynamic.lsc.net.tw.' 19:06:40 Case mismatch '210.17.9.229' AAAA: 'POst.EcCrM.EPaPER.cOm.tw.' != 'post.eccrm.epaper.com.tw.' 19:06:48 Case mismatch '216.254.98.230' AAAA: 'GRanDmOTherSFoODs.Com.' != 'grandmothersfoods.com.' 19:06:51 Case mismatch '210.17.9.229' A: 'tCdNS.seed.net.tW.' != 'tcdns.seed.net.tw.' 19:06:55 Case mismatch '210.17.9.230' MX: 'lABOR.goV.tW.' != 'labor.gov.tw.' 19:06:58 Case mismatch '218.13.50.252' MX: '2299.cOM.' != '2299.com.' 19:07:02 Case mismatch '220.229.225.196' A: 'Dns2.TACOneT.com.tw.' != 'dns2.taconet.com.tw.' 19:07:02 Case mismatch '66.249.93.9' A: 'SB.l.GOogLe.cOM.' != 'sb.l.google.com.' 19:07:04 Case mismatch '63.246.15.134' PTR: '232.23.246.63.In-Addr.arpA.' != '232.23.246.63.in-addr.arpa.' 19:07:12 Case mismatch '216.148.215.122' A: 'aPple.aCcUwEaTher.COM.att-IDNS.nET.' != 'apple.accuweather.com.att-idns.net.' 19:07:28 Case mismatch '70.169.180.26' MX: 'PPrI.orG.' != 'ppri.org.' 19:07:30 Case mismatch '216.102.246.43' MX: 'jumo.COm.' != 'jumo.com.' 19:07:37 Case mismatch '220.229.225.196' A: 'NS1.kGex.COM.tW.' != 'ns1.kgex.com.tw.' 19:07:37 Case mismatch '205.216.134.37' MX: 'hOtmiaiL.cOm.' != 'hotmiail.com.' 19:07:43 Case mismatch '62.212.78.199' PTR: '180.87.212.62.In-adDR.arPa.' != '180.87.212.62.in-addr.arpa.' 19:07:45 Case mismatch '205.216.134.37' MX: 'hOtMIAIl.COM.' != 'hotmiail.com.' 19:07:45 Case mismatch '205.216.134.37' AAAA: 'HoTMIAIL.Com.' != 'hotmiail.com.' 19:07:48 Case mismatch '61.31.216.4' MX: 'PcHomE.cOM.Tw.' != 'pchome.com.tw.' 19:07:59 Case mismatch '66.206.3.3' PTR: '81.245.165.66.In-aDdr.ARPa.' != '81.245.165.66.in-addr.arpa.' 19:08:00 Case mismatch '66.249.93.9' A: 'Gmr-SMtP-In.L.googLe.cOM.' != 'gmr-smtp-in.l.google.com.' 19:08:03 Case mismatch '61.31.216.4' A: 'eNS2.neT-cHInEse.coM.TW.' != 'ens2.net-chinese.com.tw.' 19:08:03 Case mismatch '211.79.207.25' A: 'ENS1.NEt-cHinEsE.COm.tw.' != 'ens1.net-chinese.com.tw.' 19:08:03 Case mismatch '211.79.207.25' A: 'ens1.neT-ChinEse.COM.Tw.' != 'ens1.net-chinese.com.tw.' 19:08:03 Case mismatch '61.31.216.4' A: 'eNs1.neT-chiNesE.cOM.Tw.' != 'ens1.net-chinese.com.tw.' 19:08:13 Case mismatch '211.79.207.25' AAAA: '219-84-181-130-AdSl-TAN.DyNamIC.so-NEt.NET.Tw.' != '219-84-181-130-adsl-tan.dynamic.so-net.net.tw.' 19:08:13 Case mismatch '211.79.207.25' A: '219-84-181-130-aDsL-TAn.DyNAMIC.SO-nEt.NEt.Tw.' != '219-84-181-130-adsl-tan.dynamic.so-net.net.tw.' 19:08:17 Case mismatch '210.17.9.229' A: 'Dns.CONTReL.cOm.tW.' != 'dns.contrel.com.tw.' 19:08:19 Case mismatch '216.102.246.43' AAAA: 'hotRmAil.cOm.' != 'hotrmail.com.' 19:08:34 Case mismatch '208.36.171.11' PTR: '20.131.3.8.In-aDdR.ARpA.' != '20.131.3.8.in-addr.arpa.' 19:08:52 Case mismatch '62.212.78.199' A: 'ns5.LEASeWeB.nl.' != 'ns5.leaseweb.nl.' 19:08:52 Case mismatch '83.149.64.123' PTR: '68.46.17.85.IN-ADDR.ArPA.' != '68.46.17.85.in-addr.arpa.' 19:08:56 Case mismatch '210.17.9.229' A: 'nS2.SpArQ.cOm.tW.' != 'ns2.sparq.com.tw.' 19:09:00 Case mismatch '65.61.138.186' A: 'NeWtOn.cX.' != 'newton.cx.' 19:09:28 Case mismatch '210.17.9.229' A: '219-81-225-106.DYnamIC.TFn.nET.Tw.' != '219-81-225-106.dynamic.tfn.net.tw.' 19:09:34 Case mismatch '202.14.81.3' A: 'SMtp1.aPh.Gov.au.' != 'smtp1.aph.gov.au.' 19:09:44 Case mismatch '211.79.207.25' AAAA: 'MAil6.DNs168.COM.tW.' != 'mail6.dns168.com.tw.' Which means that roughly one in every thousand *client* queries results in a mismatch. Measured as a percentage of resolver queries, this ratio will be higher. I don't think the problems above are insurmountable, the Australian government, the .tw registry and google will probably be reachable, and able to address the issue. But real ISP data does show dns-0x20 is not problem free. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 12:10:37 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4743A6E4F; Thu, 13 Mar 2008 12:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdD+BuuHGQac; Thu, 13 Mar 2008 12:10:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 125F43A6C74; Thu, 13 Mar 2008 12:10:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZsfO-0005nO-Ha for namedroppers-data@psg.com; Thu, 13 Mar 2008 19:00:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZsfD-0005lF-UP for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 19:00:32 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2DJ0KwG012840; Thu, 13 Mar 2008 15:00:21 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200803131900.m2DJ0KwG012840@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2008 14:59:29 -0400 To: Florian Weimer From: Olafur Gudmundsson Subject: Re: DNS is mandatory text Cc: namedroppers@ops.ietf.org In-Reply-To: <823aquwu0q.fsf@mid.bfk.de> References: <200803120332.m2C3WlBU084335@ogud.com> <823aquwu0q.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 10:58 13/03/2008, Florian Weimer wrote: >* Olafur Gudmundsson: > > > As number of uses of DNS require larger answers than can be easily > > fit in 512 byte answers, it makes sense to require modern DNS > > software to implement EDNS0. > >Makes sense, I agree. > > > Thus Authorative servers, Recursive Resolvers, Stub-resolver and > > middle-ware boxes speaking DNS in any form MUST implement ENDS0 and > > MUST support buffer size of at least 2K. > >Why 2K? Why not 4K or 1.2K? No reason, number larger than 1.5K was picked out of the hat. The WG should work out what this number should be. I would be happier with 4K as minimum. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 12:13:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23D83A6CE9; Thu, 13 Mar 2008 12:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JPa2fNrwY13; Thu, 13 Mar 2008 12:13:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA50B3A6C29; Thu, 13 Mar 2008 12:13:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZsmA-0007S4-Us for namedroppers-data@psg.com; Thu, 13 Mar 2008 19:07:38 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZsm1-0007QT-Pu for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 19:07:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D9174114C6; Thu, 13 Mar 2008 19:07:28 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Florian Weimer cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Thu, 13 Mar 2008 11:26:56 +0100." <82r6eeyl5b.fsf@mid.bfk.de> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <82r6eeyl5b.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Mar 2008 19:07:28 +0000 Message-ID: <76636.1205435248@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > >> ... The 0x20 material is probably quite controversial, and > >> BCP 79 issues may still turn up. > > > > do tell. i havn't seen or heard any controversy yet, > > People have begun putting out press statements opposing 0x20. I hope > you aren't too surprised. got URL's? > > 0x20 is definitely not middlebox safe, which is why i don't > > recommend it for stub resolver use. > > And how is this not a show-stopper for a global configuration switch > in the name server, when you can't know the location of middleboxes? if you are a recursive nameserver, then you'd use 0x20 except when talking to a "forwarder". if you are a stub resolver, then you're always talking to a "forwarder". so the rule would be, don't use 0x20 when talking to a forwarder. no special config logic needed. -- to unsubscribe send a message to namedroppers-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 Mar 13 12:25:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E8F3A6981; Thu, 13 Mar 2008 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOyctXY3cVH0; Thu, 13 Mar 2008 12:25:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E78A73A6CF9; Thu, 13 Mar 2008 12:25:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZsvP-0009gZ-Hz for namedroppers-data@psg.com; Thu, 13 Mar 2008 19:17:11 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZsvM-0009fA-7U for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 19:17:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E0558114EB; Thu, 13 Mar 2008 19:17:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Thu, 13 Mar 2008 19:15:48 +0100." <20080313181548.GS10313@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Mar 2008 19:17:07 +0000 Message-ID: <77089.1205435827@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > But real ISP data does show dns-0x20 is not problem free. that's wild. but interesting and useful. -- to unsubscribe send a message to namedroppers-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 Mar 13 13:08:46 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586143A69D5; Thu, 13 Mar 2008 13:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6g7OJHhGgt7; Thu, 13 Mar 2008 13:08:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 675913A6878; Thu, 13 Mar 2008 13:08:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZtbd-000KsA-2f for namedroppers-data@psg.com; Thu, 13 Mar 2008 20:00:49 +0000 Received: from [85.17.178.135] (helo=spalding.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZtbX-000Kr0-6S for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 20:00:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spalding.dds.nl (Postfix) with ESMTP id 2F3A0628AAF; Thu, 13 Mar 2008 21:00:42 +0100 (CET) Received: from spalding.dds.nl ([127.0.0.1]) by localhost (spalding.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16916-04-2; Thu, 13 Mar 2008 21:00:38 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spalding.dds.nl (Postfix) with ESMTP id C4E90628A94; Thu, 13 Mar 2008 21:00:36 +0100 (CET) Message-ID: <47D987E3.5070206@nlnetlabs.nl> Date: Thu, 13 Mar 2008 21:00:35 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: bert hubert CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> In-Reply-To: <20080313181548.GS10313@outpost.ds9a.nl> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90.1, clamav-milter version 0.90.1 on spalding.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bert hubert wrote: | On Wed, Mar 12, 2008 at 06:09:47PM +0000, Paul Vixie wrote: |> so, practically speaking, the fact that i've not run into any non-copiers in |> a few million upstream transactions, means that further testing is illuminative |> but not decisive. | | I think my test data is a bit broader - after 40000 queries out of my 2 | billion or so, I have: | | 19:06:19 Case mismatch '66.249.93.9' A: 'maPs.l.gOoglE.COM.' != 'maps.l.google.com.' I do not understand, are the authoritative servers for maps.l.google.com not copying the query section to the answer? You seem to imply this is working from a stored set of data - how does that include the algorithm used by the authority server? If I dig @a.l.google.com maps.l.gOOgle.com then the reply is perfectly fine for 0x20 use. Also for b to g.l.google.com. Does this mean that google has fixed (or upgraded) their servers between your stored data (at 7PM) and now (21PM) ? | But real ISP data does show dns-0x20 is not problem free. But where is the problem? Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH2YfjkDLqNwOhpPgRAspqAKCA+OIZwNzb6kdF9YgF8nwstOoeZQCglu5o NCYci12zHR1/wIllllAjRFM= =dmyQ -----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 Mar 13 13:18:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CDC3A67AD; Thu, 13 Mar 2008 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DUAHgzc30u8; Thu, 13 Mar 2008 13:18:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94E533A6878; Thu, 13 Mar 2008 13:18:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZtnD-000NKu-5J for namedroppers-data@psg.com; Thu, 13 Mar 2008 20:12:47 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZtn9-000NK2-Nx for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 20:12:44 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EDA95114F7; Thu, 13 Mar 2008 20:12:42 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text In-Reply-To: Your message of "Thu, 13 Mar 2008 14:59:29 -0400." <200803131900.m2DJ0KwG012840@ogud.com> References: <200803120332.m2C3WlBU084335@ogud.com> <823aquwu0q.fsf@mid.bfk.de> <200803131900.m2DJ0KwG012840@ogud.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Mar 2008 20:12:42 +0000 Message-ID: <79186.1205439162@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I would be happier with 4K as minimum. > > Olafur me too. -- to unsubscribe send a message to namedroppers-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 Mar 13 14:23:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0AC3A6A0F; Thu, 13 Mar 2008 14:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLNoBCHVa4kI; Thu, 13 Mar 2008 14:23:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1D3E3A6981; Thu, 13 Mar 2008 14:23:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZuhj-000AEJ-Rd for namedroppers-data@psg.com; Thu, 13 Mar 2008 21:11:11 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZuhg-000ABZ-9P for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 21:11:10 +0000 Received: from [130.129.21.125] (dhcp-157d.ietf71.ietf.org [130.129.21.125]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2DLB1qS095947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 22:11:02 +0100 (CET) (envelope-from jelte@NLnetLabs.nl) Message-ID: <47D99861.50305@NLnetLabs.nl> Date: Thu, 13 Mar 2008 17:10:57 -0400 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "W.C.A. Wijngaards" CC: bert hubert , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <20080312163821.GG10313@outpost.ds9a.nl> <18872.1205341235@sa.vix.com> <20080312174700.GI10313@outpost.ds9a.nl> <21844.1205345387@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> In-Reply-To: <47D987E3.5070206@nlnetlabs.nl> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFDBCFA903FB791CF8ECC2BFE" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 13 Mar 2008 22:11:03 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFDBCFA903FB791CF8ECC2BFE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable W.C.A. Wijngaards wrote: > If I dig @a.l.google.com maps.l.gOOgle.com then the reply is perfectly > fine for 0x20 use. Also for b to g.l.google.com. Does this mean that > google has fixed (or upgraded) their servers between your stored data > (at 7PM) and now (21PM) ? >=20 not always, try a few times: jelte@xod ~ % repeat 5 dig @a.l.google.com maps.l.gOOgle.com | grep \; | grep maps ; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com ;maps.l.gOOgle.com. IN A ; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com ;maps.l.gOOgle.com. IN A ; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com ;maps.l.google.com. IN A ; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com ;maps.l.google.com. IN A ; <<>> DiG 9.4.2 <<>> @a.l.google.com maps.l.gOOgle.com ;maps.l.google.com. IN A jelte@xod ~ % Jelte --------------enigFDBCFA903FB791CF8ECC2BFE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2Zhk4nZCKsdOncURAk73AKCE7Dr3oU/f3aEhFERkK7Isun/LGQCgk0QV bqL4Bw44nWtFigmyE09gyA0= =wPjJ -----END PGP SIGNATURE----- --------------enigFDBCFA903FB791CF8ECC2BFE-- -- to unsubscribe send a message to namedroppers-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 Mar 13 16:05:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13BA3A687E; Thu, 13 Mar 2008 16:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, NORMAL_HTTP_TO_IP=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 H-bu3f3s9eAt; Thu, 13 Mar 2008 16:05:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C7E528C301; Thu, 13 Mar 2008 16:03:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwK8-000BZ3-80 for namedroppers-data@psg.com; Thu, 13 Mar 2008 22:54:56 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwK5-000BXz-3r for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 22:54:54 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=BrianD-2.local) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JZwJr-0002Jd-Ov; Thu, 13 Mar 2008 18:54:39 -0400 Message-ID: <47D9B0BA.9050806@ca.afilias.info> Date: Thu, 13 Mar 2008 18:54:50 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul Vixie CC: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> In-Reply-To: <82019.1205443130@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul Vixie wrote: > indeed. here are some other examples from my own server logs, which i hadn't > been checking in recent days, but which i've beefed up and looked at based on > bert's report here. > > qname mismatch ("5.80.97.67.in-addr.arpa" != "5.80.97.67.In-aDdR.aRPa") > qname mismatch ("ASPMX.L.GOOGLE.COM" != "aspmx.L.gOOGle.CoM") > > most distressing. this means dns-0x20, and the standards change it > recommends, are controversial after all, which means it'll either never be a > standard, or, that it will get turned into a negotiated EDNS option, and that > it'll take some years for DNSEXT and IETF to process it. i'm not even sure > that an FYI could be published in the face of this kind of raw data. > > I'm interested in seeing more details corresponding to the raw data, if that is feasible to obtain. Can you do some fingerprinting on the servers serving up these answers? However, I definitely don't want us to collectively give up too soon... I think the benefits of 0x20 are substantial enough to warrant more investigation on the underlying issue(s), e.g. possibly identifying whether this is a middle-box issue. Are there no modifications to 0x20 that can achieve the good results when literal copying occurs, without breaking things when it doesn't? For instance, resolvers getting back answers that don't match, indicating a lower trust value on the answer, such as by marking the answer as non-authoritative, even if the answer would otherwise have been considered authoritative? Would that modification result in non-breakage, but preferring answers that hono(u)r the 0x20 function? Just wondering... Brian Dickson -- to unsubscribe send a message to namedroppers-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 Mar 13 16:26:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78B828C8C5; Thu, 13 Mar 2008 16:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 484tHZVPBu1Z; Thu, 13 Mar 2008 16:26:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E883B28C962; Thu, 13 Mar 2008 16:26:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwin-000IJ0-Eg for namedroppers-data@psg.com; Thu, 13 Mar 2008 23:20:25 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwik-000II7-2H for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 23:20:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 71BE9114E2; Thu, 13 Mar 2008 23:20:21 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Brian Dickson cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Thu, 13 Mar 2008 18:54:50 -0400." <47D9B0BA.9050806@ca.afilias.info> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Mar 2008 23:20:21 +0000 Message-ID: <86837.1205450421@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > ... means dns-0x20, and the standards change it recommends, are > > controversial after all, which means it'll either never be a standard, ... > > I'm interested in seeing more details corresponding to the raw data, if that > is feasible to obtain. Can you do some fingerprinting on the servers > serving up these answers? i don't think so. some are behind load balancers, and so, do not always answer the wrong way. i suppose that with frequency analysis we could try to guess which one that answers a certain way also fingerprints a certain way. > However, I definitely don't want us to collectively give up too soon... me neither. i think this is going to be a tough luck scenario, with or without IETF standards support for "must always copy". some of us are going to deploy 0x20 and let the pain fall where it may. now that i know it's a load balancing issue i may decide to repeat failed queries once or twice to see if i get a better result. this will look like a ddos to the authorities, especially if a lot of people do it. > I think the benefits of 0x20 are substantial enough to warrant more > investigation on the underlying issue(s), e.g. possibly identifying whether > this is a middle-box issue. agreed. > Are there no modifications to 0x20 that can achieve the good results when > literal copying occurs, without breaking things when it doesn't? no. if you have modality, then the modality becomes the target. > For instance, resolvers getting back answers that don't match, indicating a > lower trust value on the answer, such as by marking the answer as > non-authoritative, even if the answer would otherwise have been considered > authoritative? if someone is able to get you to cache an A RR for www.microsoft.com or maybe asia9.akadns.net and you follow it when chasing delegations or you hand it out when asked a question about it, then you're screwed. credibility levels only matter when deciding whether to replace something in the cache with something you've been offered. they don't help when you have nothing to compare against. > Would that modification result in non-breakage, but preferring answers that > hono(u)r the 0x20 function? > > Just wondering... i think you're right that it's worth studying the servers who downcase or otherwise don't perfectly copy the question section. i also think that a lot of us are going to implement dns-0x20 even without standards support, and that the natural way to be sure that you've hit a bad load balancer is to map the response to a FORMERR and just try other servers. (which is what i was doing, which is why i didn't notice that this was a problem until i saw bert's results.) -- to unsubscribe send a message to namedroppers-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 Mar 13 16:34:04 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335CB28C7C4; Thu, 13 Mar 2008 16:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=1.589, 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 2ZeN71-dCl9R; Thu, 13 Mar 2008 16:34:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A7B33A6BAC; Thu, 13 Mar 2008 16:34:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwqe-000KF3-3l for namedroppers-data@psg.com; Thu, 13 Mar 2008 23:28: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.68 (FreeBSD)) (envelope-from ) id 1JZwqb-000KEY-ET for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 23:28:30 +0000 X-IronPort-AV: E=Sophos;i="4.25,497,1199682000"; d="scan'208";a="1730156" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Mar 2008 19:28:22 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2DNSMpJ029937; Thu, 13 Mar 2008 19:28:22 -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.12.10/8.12.6) with ESMTP id m2DNSH0J013692; Thu, 13 Mar 2008 23:28:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 19:28:17 -0400 Received: from [161.44.65.151] ([161.44.65.151]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 19:28:16 -0400 Message-ID: <47D9B881.4090505@cisco.com> Date: Thu, 13 Mar 2008 19:28:01 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Michael Graff CC: Paul Vixie , Michael Graff , "W.C.A. Wijngaards" , bert hubert , "namedroppers@ops.ietf.org" Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> In-Reply-To: <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2008 23:28:17.0000 (UTC) FILETIME=[EA57BE80:01C88561] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=873; t=1205450902; x=1206314902; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joshl@cisco.com; z=From:=20Josh=20Littlefield=20 |Subject:=20Re=3A=20dns-0x20=20mismatches |Sender:=20 |To:=20Michael=20Graff=20; bh=R/N+AgMvpwS6WkHA0bB7E/4cD/MD7OZko5xdXQG/xpw=; b=A7vv+AGJuZsjU80fSjDqSGCrE/3+M5dphKs4WgQh6zI2OkjrB5eTl7Yfz3 8EnkBlbhTHqa3uK9WqfL2TkenFSgPvNv3R3fiZheM5ffNns8Onrt1cBFbIQI Ndkv3VogSV; Authentication-Results: rtp-dkim-2; header.From=joshl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Michael Graff wrote: > EDNS0 echo option for the win. > > Which is a per query "server please echo these bits" option. If we're going to need EDNS to ask for echoing so that we can support 0x20, or for anything else related to this, why not just use EDNS to carry an extended transaction ID (or cookie) instead? I think the beauty of 0x20 was that it pretty much already worked with no negotiation. Once you need negotiation, you don't need this hack (a term I use with the greatest affection). -josh > > Until dnssec comes out of course. > > --Michael > -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-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 Mar 13 16:37:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C20D3A6CF2; Thu, 13 Mar 2008 16:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUU9AGiv-1iQ; Thu, 13 Mar 2008 16:37:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D353E28C1A6; Thu, 13 Mar 2008 16:37:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwuN-000L85-VY for namedroppers-data@psg.com; Thu, 13 Mar 2008 23:32:23 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwuJ-000L6b-Ca for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 23:32:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F15D3114CA; Thu, 13 Mar 2008 23:32:18 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Michael Graff cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , "namedroppers@ops.ietf.org" Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Thu, 13 Mar 2008 19:17:30 -0400." <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Mar 2008 23:32:18 +0000 Message-ID: <87263.1205451138@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > EDNS0 echo option for the win. > > Which is a per query "server please echo these bits" option. > > Until dnssec comes out of course. what makes anybody think that the load balancers are going to implement this, such that initiator-side state about the responder's cookie will be useful for verifying future transactions against the same responder (where a responder identity is being naively mapped to an ip address?) clearly the time domain of responder identity is exactly one packet. what makes anybody think that this echo option could be uptaken faster than dnssec would be? the advantage to dns-0x20 is that it required only one party, the initiator, to upgrade code in order to enable the new feature. and that's assuming that an attacker can't use truncation as a reason why they didn't include a matching OPT RR and cookie, thus forcing the initiator to assume/hopefor the best while getting reamed. -- to unsubscribe send a message to namedroppers-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 Mar 13 16:43:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38E228C27E; Thu, 13 Mar 2008 16:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0lBiXZT97pK; Thu, 13 Mar 2008 16:43:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D79E3A6BC9; Thu, 13 Mar 2008 16:43:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwzV-000MjJ-8k for namedroppers-data@psg.com; Thu, 13 Mar 2008 23:37:41 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZwzR-000MiT-W6 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 23:37:39 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=BrianD-2.local) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JZwzL-0003dC-72; Thu, 13 Mar 2008 19:37:31 -0400 Message-ID: <47D9BAC5.2020405@ca.afilias.info> Date: Thu, 13 Mar 2008 19:37:41 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul Vixie CC: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> <86837.1205450421@sa.vix.com> In-Reply-To: <86837.1205450421@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul Vixie wrote: >>> ... means dns-0x20, and the standards change it recommends, are >>> controversial after all, which means it'll either never be a standard, ... >>> >> I'm interested in seeing more details corresponding to the raw data, if that >> is feasible to obtain. Can you do some fingerprinting on the servers >> serving up these answers? >> > > i don't think so. some are behind load balancers, and so, do not always > answer the wrong way. i suppose that with frequency analysis we could try > to guess which one that answers a certain way also fingerprints a certain > way. > > What if your fingerprint request was 0x20 twiddled? You should see immediate correlation between identity and non-literal copying. (Apologies to SCO-bashers. ;-)) >> However, I definitely don't want us to collectively give up too soon... >> > > me neither. i think this is going to be a tough luck scenario, with or > without IETF standards support for "must always copy". some of us are going > to deploy 0x20 and let the pain fall where it may. now that i know it's a > load balancing issue i may decide to repeat failed queries once or twice to > see if i get a better result. this will look like a ddos to the authorities, > especially if a lot of people do it. > > >> Are there no modifications to 0x20 that can achieve the good results when >> literal copying occurs, without breaking things when it doesn't? >> > > no. if you have modality, then the modality becomes the target. > > >> For instance, resolvers getting back answers that don't match, indicating a >> lower trust value on the answer, such as by marking the answer as >> non-authoritative, even if the answer would otherwise have been considered >> authoritative? >> > > if someone is able to get you to cache an A RR for www.microsoft.com or maybe > asia9.akadns.net and you follow it when chasing delegations or you hand it out > when asked a question about it, then you're screwed. credibility levels only > matter when deciding whether to replace something in the cache with something > you've been offered. they don't help when you have nothing to compare against. > > I'm thinking more along the lines of, not only return the non-AA result to the client, but to also *not* cache the response (not even the authority section). It has the result of un-amplifying the injection of bad data, by not caching it. Thus, a resolver receiving injected data would only ever give out a single bad answer. It also results in a strong bias towards "good" answers if multiple exposed NS instances differ in their 0x20 status, allowing caching of "good" NS instances preferentially for subsequent RR lookups. (This, in the case where the results come from non-bad-guy sources, that differ in 0x20 results.) Not caching non-0x20 answers makes bad guys have to spend more effort/energy towards 0x20 resolvers than they would towards non 0x20 resolvers. So, resolver operators would have Darwinian pressure to deploy 0x20, at least, since they would both benefit from better quality answers and mostly being protected against bad answers, as well as from being less likely to be potential targets for such injection activity. Bad guys use Occam's Razor as well. You don't have to out-run the bear, if you can out-run your friends. :-) >> Would that modification result in non-breakage, but preferring answers that >> hono(u)r the 0x20 function? >> >> Just wondering... >> > > i think you're right that it's worth studying the servers who downcase or > otherwise don't perfectly copy the question section. i also think that a lot > of us are going to implement dns-0x20 even without standards support, and that > the natural way to be sure that you've hit a bad load balancer is to map the > response to a FORMERR and just try other servers. (which is what i was doing, > which is why i didn't notice that this was a problem until i saw bert's > results.) > Out of curiosity - have you and Bert looked at the zones you're seeing non-0x20-compatible answers, to see if any such zones *always* return the bad answers? I'd be curious to know if the FORMERR technique is known to be good (eventually works) or is known to fail for some (very small percentage of) zones... and if so, what ones have been found and what their fingerprints show. Brian -- to unsubscribe send a message to namedroppers-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 Mar 13 16:50:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC1B3A6809; Thu, 13 Mar 2008 16:50:54 -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=1.866, 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 VYUDHis1uPDH; Thu, 13 Mar 2008 16:50:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F309828C135; Thu, 13 Mar 2008 16:50:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZx6Y-000Oc6-9R for namedroppers-data@psg.com; Thu, 13 Mar 2008 23:44:58 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZx6V-000Oba-82 for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 23:44:56 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 41CCD327A72; Thu, 13 Mar 2008 16:44:54 -0700 (PDT) Received: from [130.129.20.46] (dhcp-142e.ietf71.ietf.org [130.129.20.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 85C6A327A5A; Thu, 13 Mar 2008 16:44:53 -0700 (PDT) References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> <47D9B881.4090505@cisco.com> Message-Id: From: Michael Graff To: Josh Littlefield In-Reply-To: <47D9B881.4090505@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: iPhone Mail (4A102) Mime-Version: 1.0 (iPhone Mail 4A102) Subject: Re: dns-0x20 mismatches Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2008 19:44:18 -0400 Cc: Paul Vixie , Michael Graff , "W.C.A. Wijngaards" , bert hubert , "namedroppers@ops.ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I didn't expect negotiation to occur. Honestly with a seemingly small number of auth servers doing the bad thing finding out what those are would be good. Fixing hopefully one implementation vs changing every server out there is good. --Michael On Mar 13, 2008, at 19:28, Josh Littlefield wrote: > Michael Graff wrote: >> EDNS0 echo option for the win. >> >> Which is a per query "server please echo these bits" option. > > If we're going to need EDNS to ask for echoing so that we can > support 0x20, or for anything else related to this, why not just use > EDNS to carry an extended transaction ID (or cookie) instead? I > think the beauty of 0x20 was that it pretty much already worked with > no negotiation. Once you need negotiation, you don't need this hack > (a term I use with the greatest affection). > > -josh > >> >> Until dnssec comes out of course. >> >> --Michael >> > -- > ===================================================================== > Josh Littlefield Cisco Systems, Inc. > joshl@cisco.com 1414 Massachusetts Avenue > tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-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 Mar 13 17:26:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3559428C15D; Thu, 13 Mar 2008 17:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7V2CobOQUpB; Thu, 13 Mar 2008 17:26:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED7A228C141; Thu, 13 Mar 2008 17:26:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZxcU-0006To-PU for namedroppers-data@psg.com; Fri, 14 Mar 2008 00:17:58 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZxcQ-0006T5-Gw for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 00:17:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 62432114CD; Fri, 14 Mar 2008 00:17:53 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Brian Dickson cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Thu, 13 Mar 2008 19:37:41 -0400." <47D9BAC5.2020405@ca.afilias.info> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> <86837.1205450421@sa.vix.com> <47D9BAC5.2020405@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 00:17:53 +0000 Message-ID: <89233.1205453873@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > >> I'm interested in seeing more details corresponding to the raw data, if > >> that is feasible to obtain. Can you do some fingerprinting on the > >> servers serving up these answers? > > > > i don't think so. some are behind load balancers, and so, do not always > > answer the wrong way. i suppose that with frequency analysis we could try > > to guess which one that answers a certain way also fingerprints a certain > > way. > > What if your fingerprint request was 0x20 twiddled? You should see > immediate correlation between identity and non-literal copying. (Apologies > to SCO-bashers. ;-)) perhaps roy arends of fpdns fame will work up a patch for this use. > > if someone is able to get you to cache an A RR for www.microsoft.com or > > maybe asia9.akadns.net and you follow it when chasing delegations or you > > hand it out when asked a question about it, then you're screwed. > > credibility levels only matter when deciding whether to replace something > > in the cache with something you've been offered. they don't help when you > > have nothing to compare against. > > I'm thinking more along the lines of, not only return the non-AA result to > the client, but to also *not* cache the response (not even the authority > section). then if your client is a recursive server using you as a forwarder, they are poisoned. if they are a web browser who caches their dns results, they are poisoned. (consider a www.paypal.com IN A infection in that light.) > It has the result of un-amplifying the injection of bad data, by not caching > it. Thus, a resolver receiving injected data would only ever give out a > single bad answer. see above. just because you don't cache it doesn't mean it won't be cached. any loophole like this becomes the new target of new attacks. making it rare or difficult doesn't help. > > i think you're right that it's worth studying the servers who downcase or > > otherwise don't perfectly copy the question section. i also think that a > > lot of us are going to implement dns-0x20 even without standards support, > > and that the natural way to be sure that you've hit a bad load balancer is > > to map the response to a FORMERR and just try other servers. (which is > > what i was doing, which is why i didn't notice that this was a problem > > until i saw bert's results.) > > Out of curiosity - have you and Bert looked at the zones you're seeing > non-0x20-compatible answers, to see if any such zones *always* return the > bad answers? at least in the case of google, it's known to be a pulsar. bert and i both posted lists of domains, so any of them can be checked for this behaviour. > I'd be curious to know if the FORMERR technique is known to be good > (eventually works) or is known to fail for some (very small percentage of) > zones... and if so, what ones have been found and what their fingerprints > show. that's a good question. i'll instrument that. somebody get with roy arends on the fpdns patch? -- to unsubscribe send a message to namedroppers-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 Mar 13 17:44:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98AED3A6BCC; Thu, 13 Mar 2008 17:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trlz-V7CegAM; Thu, 13 Mar 2008 17:44:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 611633A6B35; Thu, 13 Mar 2008 17:44:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZxvE-000BiN-Db for namedroppers-data@psg.com; Fri, 14 Mar 2008 00:37:20 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZxvA-000Bgg-OJ for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 00:37:19 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2E0UIn8024961; Fri, 14 Mar 2008 07:30:19 +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 m2E0TbV7001687; Fri, 14 Mar 2008 07:29:48 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: <82019.1205443130@sa.vix.com> References: <82019.1205443130@sa.vix.com> <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Mar 2008 07:29:37 +0700 Message-ID: <798.1205454577@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Thu, 13 Mar 2008 21:18:50 +0000 From: Paul Vixie Message-ID: <82019.1205443130@sa.vix.com> | i apologize to all for the wild goose chase. Don't, that's all useful, and I still believe that the planned change to the spec to require the question section in the answer to be identical to the question section in the query would be a good thing to do. Servers shouldn't be messing with the case of the ascii letters in the query any more than resolvers should, everyone should just be passing through what they're handed. It would also be interesting to find out just why the servers are behaving as they seem to be - clearly a server could be doing something like down-casing all incoming queries to make matching easier, but that would affect all queries, not just some of them. I'd be kind of tempted to guess that what might be happening is the server sending a cached reply (I just answered that question, here is the reply again) - with just the first 4 bytes of the DNS header updated based upon the new query. The "multiple servers at the same address behaving differently" is certainly a plausible guess for google, or hotmail, but it's kind of hard to believe that for some of the other reported cases (eg: I really don't believe that ns1.aph.gov.au (202.14.81.3) is hiding a whole bunch of differing servers.) kre -- to unsubscribe send a message to namedroppers-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 Mar 13 19:25:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3376E3A68B8; Thu, 13 Mar 2008 19:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gz-YbHg9RBt; Thu, 13 Mar 2008 19:25:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2DBC33A6850; Thu, 13 Mar 2008 19:25:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZzUt-000CgY-Vk for namedroppers-data@psg.com; Fri, 14 Mar 2008 02:18:15 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZzUq-000CfC-Uq for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 02:18:14 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2E2HqJd049904; Fri, 14 Mar 2008 03:17:52 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803140217.m2E2HqJd049904@givry.fdupont.fr> From: Francis Dupont To: Michael Graff cc: Paul Vixie , Michael Graff , "W.C.A. Wijngaards" , bert hubert , "namedroppers@ops.ietf.org" Subject: Re: dns-0x20 mismatches In-reply-to: Your message of Thu, 13 Mar 2008 19:17:30 -0400. <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> Date: Fri, 14 Mar 2008 03:17:52 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion In your previous mail you wrote: EDNS0 echo option for the win. Which is a per query "server please echo these bits" option. Until dnssec comes out of course. => it is useful with DNSSEC too because it limits DoS from outside the path attackers. As DNSSEC can imply some expensive crypto ops it could become a good idea to use this (EDNS0 cookie) even with DNSSEC. Thanks Francis.Dupont@fdupont.fr PS: please note a cookie can be stateless, i.e., in place of keeping it the sender can recompute it and check if it gets the same value. -- to unsubscribe send a message to namedroppers-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 Mar 13 21:48:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED263A6F20; Thu, 13 Mar 2008 21:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_84=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 wqvpzaY4lYs6; Thu, 13 Mar 2008 21:48:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 259233A6B72; Thu, 13 Mar 2008 21:48:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1hZ-000INJ-TX for namedroppers-data@psg.com; Fri, 14 Mar 2008 04:39:29 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1hP-000ILs-E8 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 04:39:20 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=BrianD-2.local) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1Ja1hG-0007Ap-Tg; Fri, 14 Mar 2008 00:39:11 -0400 Message-ID: <47DA0178.3080602@ca.afilias.info> Date: Fri, 14 Mar 2008 00:39:20 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul Vixie CC: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> <86837.1205450421@sa.vix.com> <47D9BAC5.2020405@ca.afilias.info> <89233.1205453873@sa.vix.com> In-Reply-To: <89233.1205453873@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul Vixie wrote: >> What if your fingerprint request was 0x20 twiddled? You should see >> immediate correlation between identity and non-literal copying. (Apologies >> to SCO-bashers. ;-)) >> > > perhaps roy arends of fpdns fame will work up a patch for this use. > I checked; doing simple 'dig @${server} ch txt HoStNaMe.bind' (or VeRsIoN.bind) does a quick and dirty test for both the 0x20 sense, and what the box claims to be. YMMV. Brian -- to unsubscribe send a message to namedroppers-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 Mar 13 21:57:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8D83A68A0; Thu, 13 Mar 2008 21:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ursfKYglsXdm; Thu, 13 Mar 2008 21:57:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FCFE28C2CD; Thu, 13 Mar 2008 21:57:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1sD-000KaF-Me for namedroppers-data@psg.com; Fri, 14 Mar 2008 04:50:29 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1sA-000KYb-Kl for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 04:50:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E7FBB11429; Fri, 14 Mar 2008 04:50:25 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Robert Elz cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Fri, 14 Mar 2008 07:29:37 +0700." <798.1205454577@epsilon.noi.kre.to> References: <82019.1205443130@sa.vix.com> <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 04:50:25 +0000 Message-ID: <1674.1205470225@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > | i apologize to all for the wild goose chase. > > Don't, that's all useful, and I still believe that the planned change to the > spec to require the question section in the answer to be identical to the > question section in the query would be a good thing to do. > > Servers shouldn't be messing with the case of the ascii letters in the query > any more than resolvers should, everyone should just be passing through what > they're handed. i appreciate your supportive words here, but the technical truth of the matter is that responders who downcase or otherwise muck with the 0x20 bits of the ASCII letters of question names while copying them from request to response are not, currently or historically, broken. they don't hurt interoperability, they only hurt expansion. the rule they break is postel's on being conservative and liberal at the right time. note, i am perfectly willing to follow ed lewis' advice from a few days ago, and split dns-0x20 into two drafts, one for the standards track that just clarifies the "must always copy" behaviour, and one for the FYI track that talks about randomizing 0x20 bits in a requestor (and comparing them in the responses). if the WG supports the idea of invalidating these non-copying nameservers, then we can still do it. i'm feeling some hopelessness simply because i've been through a couple of ietf protocol wars now, and several times now my positions have been overrun by stormtroops of the lords of entropy. calling something a clarification when it will break something that wasn't broken before, is dangerous work. > It would also be interesting to find out just why the servers are behaving > as they seem to be - clearly a server could be doing something like > down-casing all incoming queries to make matching easier, but that would > affect all queries, not just some of them. i think we're likely to find middleboxes in almost every case, and hardly ever servers. a packet-flossing firewall box might strip out the 0x20 bits of udp/53 as it passes through because its designer thinks it'll otherwise be used as a covert channel by bad guys. (whereas we want it for good guys.) > I'd be kind of tempted to guess that what might be happening is the server > sending a cached reply (I just answered that question, here is the reply > again) - with just the first 4 bytes of the DNS header updated based upon > the new query. honestly, that's what i expected NSD to do, and i was surprised and ecstatic when i saw that they interpreted RFC 1035 in the same way as the rest of us. and so, if someone somewhere is keeping copies of past responses, in the way you say, then it's an implementation whose innards have never been described or bragged about. > The "multiple servers at the same address behaving differently" is certainly > a plausible guess for google, or hotmail, but it's kind of hard to believe > that for some of the other reported cases (eg: I really don't believe that > ns1.aph.gov.au (202.14.81.3) is hiding a whole bunch of differing servers.) i know what you mean. now that i'm logging the stuff properly, i can hand off data to fpdns, if roy arends agrees to patch it so that it uses dns-0x20 and can thus simultaneously fingerprint the implementation and test for "must always copy" within a single transaction (thus avoiding load balancers.) -- to unsubscribe send a message to namedroppers-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 Mar 13 22:02:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77D328C2D9; Thu, 13 Mar 2008 22:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, J_CHICKENPOX_84=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 t3pg7HHl3Mjj; Thu, 13 Mar 2008 22:02:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A76D328C4AF; Thu, 13 Mar 2008 22:02:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1ue-000L4L-7u for namedroppers-data@psg.com; Fri, 14 Mar 2008 04:53:00 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1ub-000L3t-Cq for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 04:52:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D154611429; Fri, 14 Mar 2008 04:52:56 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Brian Dickson cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Fri, 14 Mar 2008 00:39:20 -0400." <47DA0178.3080602@ca.afilias.info> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> <86837.1205450421@sa.vix.com> <47D9BAC5.2020405@ca.afilias.info> <89233.1205453873@sa.vix.com> <47DA0178.3080602@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 04:52:56 +0000 Message-ID: <1730.1205470376@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > perhaps roy arends of fpdns fame will work up a patch for this use. > > I checked; doing simple 'dig @${server} ch txt HoStNaMe.bind' (or > VeRsIoN.bind) does a quick and dirty test for both the 0x20 sense, and what > the box claims to be. i wouldn't treat the results as indicative, since the answer never comes from cache in that case. (and not all servers implement the .BIND tld.) -- to unsubscribe send a message to namedroppers-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 Mar 13 22:05:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88D328C2E0; Thu, 13 Mar 2008 22:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_84=0.6, 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 gb+Ux3qXP+dk; Thu, 13 Mar 2008 22:05:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE2ED28C2ED; Thu, 13 Mar 2008 22:05:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja20d-000MUe-RU for namedroppers-data@psg.com; Fri, 14 Mar 2008 04:59:11 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja20a-000MPl-LT for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 04:59:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DAF8011429; Fri, 14 Mar 2008 04:59:05 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Brian Dickson cc: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Fri, 14 Mar 2008 00:56:59 -0400." <47DA059B.8010607@ca.afilias.info> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> <86837.1205450421@sa.vix.com> <47D9BAC5.2020405@ca.afilias.info> <89233.1205453873@sa.vix.com> <47DA0178.3080602@ca.afilias.info> <1730.1205470376@sa.vix.com> <47DA059B.8010607@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 04:59:05 +0000 Message-ID: <1914.1205470745@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > i wouldn't treat the results as indicative, since the answer never comes > > from cache in that case. (and not all servers implement the .BIND tld.) > > Then, what about doing a TCP connection, do multiple queries over that TCP > session, one for the thing you think will come from the cache, the other for > hostname.bind or server.id or anything else used by fpdns? (We're talking > immediate/short term, like now, as opposed to very near term, as in hacking > fpdns to add in 0x20 support). all that would provably discover is the percentage of authority servers who are not reachable by, or do not answer, tcp. which would be interesting but not instructive to this purpose. -- to unsubscribe send a message to namedroppers-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 Mar 13 22:06:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B10928C2D9; Thu, 13 Mar 2008 22:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_62=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 KwkGrbYZ4L+O; Thu, 13 Mar 2008 22:05:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F10B3A67F2; Thu, 13 Mar 2008 22:05:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1yT-000Lxx-1n for namedroppers-data@psg.com; Fri, 14 Mar 2008 04:56:57 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja1yQ-000LxG-9S for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 04:56:55 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=BrianD-2.local) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1Ja1yL-0007jF-8O; Fri, 14 Mar 2008 00:56:49 -0400 Message-ID: <47DA059B.8010607@ca.afilias.info> Date: Fri, 14 Mar 2008 00:56:59 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul Vixie CC: Michael Graff , "W.C.A. Wijngaards" , bert hubert , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <82019.1205443130@sa.vix.com> <47D9B0BA.9050806@ca.afilias.info> <86837.1205450421@sa.vix.com> <47D9BAC5.2020405@ca.afilias.info> <89233.1205453873@sa.vix.com> <47DA0178.3080602@ca.afilias.info> <1730.1205470376@sa.vix.com> In-Reply-To: <1730.1205470376@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul Vixie wrote: >>> perhaps roy arends of fpdns fame will work up a patch for this use. >>> >> I checked; doing simple 'dig @${server} ch txt HoStNaMe.bind' (or >> VeRsIoN.bind) does a quick and dirty test for both the 0x20 sense, and what >> the box claims to be. >> > > i wouldn't treat the results as indicative, since the answer never comes > from cache in that case. (and not all servers implement the .BIND tld.) > > Then, what about doing a TCP connection, do multiple queries over that TCP session, one for the thing you think will come from the cache, the other for hostname.bind or server.id or anything else used by fpdns? (We're talking immediate/short term, like now, as opposed to very near term, as in hacking fpdns to add in 0x20 support). Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 00:28:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1160528C332; Fri, 14 Mar 2008 00:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, 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 j0yzfyEovCyW; Fri, 14 Mar 2008 00:28:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23E4828C2D3; Fri, 14 Mar 2008 00:28:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja4Cv-0008fp-Nh for namedroppers-data@psg.com; Fri, 14 Mar 2008 07:20:01 +0000 Received: from [2a01:280:1:1:208:2ff:fe25:3979] (helo=bardisk.kthnoc.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja4Cs-0008ee-C2 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 07:20:00 +0000 Received: from rasmus.kthnoc.net (rasmus.kthnoc.net [192.36.250.140]) (authenticated bits=0) by bardisk.kthnoc.net (8.14.1/8.13.6) with ESMTP id m2E7Jssk070521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Mar 2008 08:19:55 +0100 (CET) (envelope-from mansaxel@kthnoc.net) Date: Fri, 14 Mar 2008 07:40:13 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text Message-ID: In-Reply-To: <200803131900.m2DJ0KwG012840@ogud.com> References: <200803120332.m2C3WlBU084335@ogud.com> <823aquwu0q.fsf@mid.bfk.de> <200803131900.m2DJ0KwG012840@ogud.com> X-Mailer: Mulberry/4.0.9b1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========A981458A5DB2FBFE35E0==========" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --==========A981458A5DB2FBFE35E0========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On torsdag, torsdag 13 mar 2008 14.59.29 -0400 Olafur Gudmundsson wrote: > No reason, number larger than 1.5K was picked out of the hat. > The WG should work out what this number should be. > I would be happier with 4K as minimum. After some editing discussion, here is updated text. EDNS was specified in 1999 [RFC2671] and has been used frequently since then, with minimal adverse effects. As the number of uses for DNS requiring larger messages not fitting in the 512 byte pre-EDNS message size increases, it makes sense to require that modern DNS software, in name servers, full-service resolvers and stub resolvers, as well as middle-boxes, MUST implement EDNS version 0, and similiarily, that it MUST support and advertise a buffer size of at least 4 Kibibytes. The figure "4 KiB" is updated according to above. Still subject to WG discussion, of course.=20 --=20 M=C3=A5ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE Everywhere I look I see NEGATIVITY and ASPHALT ... --==========A981458A5DB2FBFE35E0========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFH2h3N02/pMZDM1cURAiueAJ9bjkomNRHLYTM8L/aeQGjlIkEpbQCbBrUG ShiqOlWMNN8BqntqdNKCHl4= =12mU -----END PGP SIGNATURE----- --==========A981458A5DB2FBFE35E0==========-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From RileybarberryGentry@craigslist.org Fri Mar 14 00:36:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6AE28C5FC; Fri, 14 Mar 2008 00:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.09 X-Spam-Level: X-Spam-Status: No, score=-41.09 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_06_12=1.069, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_HEADER_CTYPE_ONLY=0.56, MIME_HTML_ONLY=1.457, MISSING_SUBJECT=1.762, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_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 ul0A08WQiiF6; Fri, 14 Mar 2008 00:36:11 -0700 (PDT) Received: from casa.cantv.net (unknown [201.210.83.128]) by core3.amsl.com (Postfix) with SMTP id 0FA003A6CD1; Fri, 14 Mar 2008 00:36:09 -0700 (PDT) Received: from 15479688418206673.12293880386430332.10963104743156396.19871974414079187 (HELO localhost.localdomain) (16985692574597286.10132878641436845.15462722322394086.15974982818865822) by 12742740421389383.18670624164642904.11549836017348785.16933993319806648 with SMTP; Fri, 14 Mar 2008 03:33:38 +0400 Date: Fri, 14 Mar 2008 03:33:38 +0400 Message-Id: <7IX395EJXVWDA177@craigslist.org> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 742809 X-Header-Versions: Hewlett-Packard.9t3bn6nd4.fk@us.newsgram.hp.com X-FID: 63E37DBC-4022-91AF-B8E3-38CDEA78DCB0 Content-Type: text/html; From: RileybarberryGentry@craigslist.org To: undisclosed-recipients:; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Cc: , , , From: "Ollie Carrillo" Subject: Visa Line of Credit
If you have your own business and require IMMEDIATE ready money to spend ANY way you like or need Extra money to give the business a boost or want A low interest loan - NO STRINGS ATTACHED!
Do not worry about approval... your credit score will not disqualify you!
From owner-namedroppers@ops.ietf.org Fri Mar 14 01:42:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7F728C87B; Fri, 14 Mar 2008 01:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=0.055, 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 UShET1nb1unZ; Fri, 14 Mar 2008 01:42:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C14883A6F21; Fri, 14 Mar 2008 01:42:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja5La-000OMk-ER for namedroppers-data@psg.com; Fri, 14 Mar 2008 08:33:02 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja5LX-000OMA-KF for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 08:33:01 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1Ja5LR-0008GK-Tp; Fri, 14 Mar 2008 09:32:53 +0100 Received: from fweimer by bfk.de with local id 1Ja5LT-0002O0-OU; Fri, 14 Mar 2008 09:32:55 +0100 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <82r6eeyl5b.fsf@mid.bfk.de> <76636.1205435248@sa.vix.com> From: Florian Weimer Date: Fri, 14 Mar 2008 09:32:55 +0100 In-Reply-To: <76636.1205435248@sa.vix.com> (Paul Vixie's message of "Thu, 13 Mar 2008 19:07:28 +0000") Message-ID: <82fxutu2mg.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: DNSEXT discussion * Paul Vixie: >> People have begun putting out press statements opposing 0x20. > > got URL's? German only, sorry: Perhaps Peter can provide an authoritative translation of his comments? >> And how is this not a show-stopper for a global configuration switch >> in the name server, when you can't know the location of middleboxes? > > if you are a recursive nameserver, then you'd use 0x20 except when talking > to a "forwarder". if you are a stub resolver, then you're always talking > to a "forwarder". so the rule would be, don't use 0x20 when talking to a > forwarder. no special config logic needed. I feared that there are middleboxes in front of authoritative servers. There are many places which require mediation of *any* packet by some sort of IDS/IPS box, no matter what the performance impact is. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 05:48:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC22F28C8B0; Fri, 14 Mar 2008 05:48:14 -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 i8NpGheJKbbW; Fri, 14 Mar 2008 05:48:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53D8728C8AB; Fri, 14 Mar 2008 05:48:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja9B4-0003Vg-61 for namedroppers-data@psg.com; Fri, 14 Mar 2008 12:38:26 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja9B1-0003VL-FJ for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 12:38:24 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id C4CF0327A79; Fri, 14 Mar 2008 05:38:22 -0700 (PDT) Received: from [192.168.1.3] (72-255-34-109.client.stsn.net [72.255.34.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id D560B327A78; Fri, 14 Mar 2008 05:38:21 -0700 (PDT) References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <82r6eeyl5b.fsf@mid.bfk.de> <76636.1205435248@sa.vix.com> <82fxutu2mg.fsf@mid.bfk.de> Message-Id: From: Michael Graff To: Florian Weimer In-Reply-To: <82fxutu2mg.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: iPhone Mail (4A102) Mime-Version: 1.0 (iPhone Mail 4A102) Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding Content-Transfer-Encoding: 7bit Date: Fri, 14 Mar 2008 08:37:45 -0400 Cc: "namedroppers@ops.ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Michael On Mar 14, 2008, at 4:32, Florian Weimer wrote: > >> > I feared that there are middleboxes in front of authoritative servers. > There are many places which require mediation of *any* packet by some > sort of IDS/IPS box, no matter what the performance impact is. And of course they make it difficult if not impossible for fpdns to guess what is really there. Fpdns results should be taken with a few pounds of salt. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 06:11:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDD93A6F35; Fri, 14 Mar 2008 06:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38e+VvWdzu7p; Fri, 14 Mar 2008 06:11:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B28628C891; Fri, 14 Mar 2008 06:11:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja9XW-0008zc-BQ for namedroppers-data@psg.com; Fri, 14 Mar 2008 13:01:38 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja9XG-0008x3-UG for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 13:01:28 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2ED14Ym052232; Fri, 14 Mar 2008 14:01:04 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803141301.m2ED14Ym052232@givry.fdupont.fr> From: Francis Dupont To: Michael Graff cc: Paul Vixie , Michael Graff , "W.C.A. Wijngaards" , bert hubert , "namedroppers@ops.ietf.org" Subject: Re: dns-0x20 mismatches In-reply-to: Your message of Thu, 13 Mar 2008 19:17:30 -0400. <9D79FFB8-84C9-465F-9BF9-7E4B01046600@isc.org> Date: Fri, 14 Mar 2008 14:01:04 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion In your previous mail you wrote: EDNS0 echo option for the win. Which is a per query "server please echo these bits" option. => oops, I read this as the EDNS0 cookie idea. Of course if we have to define a new EDNS0 option the cookie idea is the right one (here cookie is the simple transaction ID extension). Thanks Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 08:20:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8929F28C320; Fri, 14 Mar 2008 08:20:19 -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 BTAGMv-qtV47; Fri, 14 Mar 2008 08:20:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71D0028C155; Fri, 14 Mar 2008 08:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaBYy-000CRq-GH for namedroppers-data@psg.com; Fri, 14 Mar 2008 15:11:16 +0000 Received: from [216.82.250.131] (helo=mail128.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaBYq-000CQo-3N for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 15:11:14 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1205507466!652402!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25186 invoked from network); 14 Mar 2008 15:11:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 14 Mar 2008 15:11:07 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2EFB61j017318 for ; Fri, 14 Mar 2008 08:11:06 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m2EFB6Ee017871 for ; Fri, 14 Mar 2008 10:11:06 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m2EFB5DR017863 for ; Fri, 14 Mar 2008 10:11:05 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS is mandatory text Date: Fri, 14 Mar 2008 11:11:00 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790039CFFD3@de01exm64.ds.mot.com> In-Reply-To: <200803131900.m2DJ0KwG012840@ogud.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS is mandatory text Thread-Index: AciFQAyaBPWF86+DT5qkQOPwDYopMgAo98FQ References: <200803120332.m2C3WlBU084335@ogud.com> <823aquwu0q.fsf@mid.bfk.de> <200803131900.m2DJ0KwG012840@ogud.com> From: "Eastlake III Donald-LDE008" To: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Why picked out of a hat? Surely some reasoning can be given. Presumably the problem with making this larger and larger is that you will typically get more fragments and in congested environments the loss of any one (or more) fragments will cause the answer to be thrown away at the IP layer. Two fragments is probably fine. So something like the most common MTU, ~1500 bytes, times two, minus a bit for headers / tunnels / good luck or something, perhaps 2.5K bytes, would be good. If three fragment in the typical case is considered OK, then 4K or a little bigger makes sense. Of course, bigger answers also make traffic amplification attacks worse... I'd go for 2.5K myself. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Olafur Gudmundsson Sent: Thursday, March 13, 2008 2:59 PM To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text At 10:58 13/03/2008, Florian Weimer wrote: >* Olafur Gudmundsson: > > > As number of uses of DNS require larger answers than can be easily > > fit in 512 byte answers, it makes sense to require modern DNS > > software to implement EDNS0. > >Makes sense, I agree. > > > Thus Authorative servers, Recursive Resolvers, Stub-resolver and > > middle-ware boxes speaking DNS in any form MUST implement ENDS0 and > > MUST support buffer size of at least 2K. > >Why 2K? Why not 4K or 1.2K? No reason, number larger than 1.5K was picked out of the hat. The WG should work out what this number should be. I would be happier with 4K as minimum. 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: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 08:32:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0338B3A6E1D; Fri, 14 Mar 2008 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cus5256T2dzg; Fri, 14 Mar 2008 08:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BF4628C950; Fri, 14 Mar 2008 08:32:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaBjy-000EpE-Ii for namedroppers-data@psg.com; Fri, 14 Mar 2008 15:22:38 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaBjV-000ElA-LE for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 15:22:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C1AFB11434 for ; Fri, 14 Mar 2008 15:22:08 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Fri, 14 Mar 2008 09:32:55 +0100." <82fxutu2mg.fsf@mid.bfk.de> References: <57450.1205256926@sa.vix.com> <82myp42cyh.fsf@mid.bfk.de> <16130.1205337563@sa.vix.com> <82r6eeyl5b.fsf@mid.bfk.de> <76636.1205435248@sa.vix.com> <82fxutu2mg.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 15:22:08 +0000 Message-ID: <25084.1205508128@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > got URL's? > > German only, sorry: that article is just a summary of these discussions, and is not critical in an editorial sense, more in a reporting sense. (because discussions here have included some critical comments, and the article describes these.) > > if you are a recursive nameserver, then you'd use 0x20 except when talking > > to a "forwarder". if you are a stub resolver, then you're always talking > > to a "forwarder". so the rule would be, don't use 0x20 when talking to a > > forwarder. no special config logic needed. > > I feared that there are middleboxes in front of authoritative servers. > There are many places which require mediation of *any* packet by some > sort of IDS/IPS box, no matter what the performance impact is. in those cases, the middleboxes will have to be removed or reprogrammed. we cannot make ourselves hostages to the bad decisions of a few ignorant and misguided vendors. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 08:54:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FC43A6849; Fri, 14 Mar 2008 08:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, J_CHICKENPOX_21=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 xfwZ8h66TVGF; Fri, 14 Mar 2008 08:54:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A1B43A63EC; Fri, 14 Mar 2008 08:54:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaC6X-000KjD-5o for namedroppers-data@psg.com; Fri, 14 Mar 2008 15:45:57 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaC6U-000Ki3-9F for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 15:45:55 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 009D811425; Fri, 14 Mar 2008 15:45:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Eastlake III Donald-LDE008" cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text In-Reply-To: Your message of "Fri, 14 Mar 2008 11:11:00 -0400." <3870C46029D1F945B1472F170D2D9790039CFFD3@de01exm64.ds.mot.com> References: <200803120332.m2C3WlBU084335@ogud.com> <823aquwu0q.fsf@mid.bfk.de> <200803131900.m2DJ0KwG012840@ogud.com> <3870C46029D1F945B1472F170D2D9790039CFFD3@de01exm64.ds.mot.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 15:45:53 +0000 Message-ID: <27875.1205509553@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Why picked out of a hat? Surely some reasoning can be given. i don't think so. > Presumably the problem with making this larger and larger is that you > will typically get more fragments and in congested environments the loss > of any one (or more) fragments will cause the answer to be thrown away > at the IP layer. yes, but that doesn't lead to a specific number. > Two fragments is probably fine. So something like the most common MTU, > ~1500 bytes, times two, minus a bit for headers / tunnels / good luck or > something, perhaps 2.5K bytes, would be good. If three fragment in the > typical case is considered OK, then 4K or a little bigger makes sense. the ratio of an atm cell size to the speed of an OC3c is 2X the ratio of a maximum ethernet packet size to the speed of 10GbE. and ATM cells were called too small, where too much silicon had to go into switching them, and too much bandwidth was being spent on headers (relative to payload.) are we sure we want to enshrine the current observed internet MTU (1500) in a recommendation? i'm not. > Of course, bigger answers also make traffic amplification attacks > worse... I'd go for 2.5K myself. i think we should say that 4096 is the absolute lowest recommended value in 2008, giving as our reason that DNS applications have to be able to assume something, and in 2008 the observed usual internet MTU is 1500, and a couple of fragments here and there never hurt anybody, whereas TCP is such a harsh penalty that most DNS application designers will want to avoid it. then we can leave it to our children to sort things out. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 13:11:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7143C3A689E; Fri, 14 Mar 2008 13:11:07 -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.026, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTbdOeO3qa2O; Fri, 14 Mar 2008 13:11:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2245A3A67B6; Fri, 14 Mar 2008 13:11:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaG2m-0005Do-Kx for namedroppers-data@psg.com; Fri, 14 Mar 2008 19:58:20 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaG2j-0005Cm-2H for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 19:58:19 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaG2d-0006Ar-A6; Fri, 14 Mar 2008 20:58:11 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1F70940B3; Fri, 14 Mar 2008 20:58:16 +0100 (CET) Date: Fri, 14 Mar 2008 20:58:15 +0100 From: bert hubert To: Paul Vixie Cc: Robert Elz , Michael Graff , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches Message-ID: <20080314195815.GA29051@outpost.ds9a.nl> References: <82019.1205443130@sa.vix.com> <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1674.1205470225@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Fri, Mar 14, 2008 at 04:50:25AM +0000, Paul Vixie wrote: > note, i am perfectly willing to follow ed lewis' advice from a few days ago, > and split dns-0x20 into two drafts, one for the standards track that just > clarifies the "must always copy" behaviour, and one for the FYI track that > talks about randomizing 0x20 bits in a requestor (and comparing them in the > responses). if the WG supports the idea of invalidating these non-copying > nameservers, then we can still do it. One thing we could ponder is to modify forgery-resilience to state (or 'clarify') that authoritative nameservers MUST do a bitwise copy of the question field, in order to facilitate possible future 0x20-like randomisation efforts. But this all depends on the WG reaction - if this is controversial, and forgery-resilience becomes controversial in turn, I (modestly) think the ensuing delay of this draft would be a loss. 0x20 can then follow at leasure, as a separate effort - we've written down the requirement in that case. Thoughts? Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 13:34:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390D93A69E8; Fri, 14 Mar 2008 13:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[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 0CxzjQQSP4YX; Fri, 14 Mar 2008 13:34:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 021BD3A68A4; Fri, 14 Mar 2008 13:34:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaGWK-000At1-So for namedroppers-data@psg.com; Fri, 14 Mar 2008 20:28:52 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaGWD-000Apt-91 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 20:28:49 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2EKSfnj034586 for ; Fri, 14 Mar 2008 16:28:41 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2EKSfuL034585 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 16:28:41 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja0d4-0004Ei-OD for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 03:30:48 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 20D20327A74; Thu, 13 Mar 2008 20:30:46 -0700 (PDT) Received: from [192.168.1.2] (72-255-34-109.client.stsn.net [72.255.34.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id C722D327A5A; Thu, 13 Mar 2008 20:30:44 -0700 (PDT) From: Michael Graff To: Francis Dupont Subject: Re: dns-0x20 mismatches Date: Thu, 13 Mar 2008 17:30:38 -0500 User-Agent: KMail/1.9.9 Cc: "namedroppers@ops.ietf.org" References: <200803140217.m2E2HqJd049904@givry.fdupont.fr> In-Reply-To: <200803140217.m2E2HqJd049904@givry.fdupont.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1205526522-33290-37" Content-Disposition: inline Message-Id: <200803131730.39321.explorer@flame.org> X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is a multi-part message in MIME format... ------------=_1205526522-33290-37 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline [ 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 Thursday 13 March 2008 21:17:52 Francis Dupont wrote: > => it is useful with DNSSEC too because it limits DoS from outside > the path attackers. As DNSSEC can imply some expensive crypto ops > it could become a good idea to use this (EDNS0 cookie) even with DNSSEC. I specifically did not call these 'cookies' to avoid conflicting with the 'dns cookie' draft. :) I suppose I can call them 'resolver tokens' or something, but really all I am looking for here is some bit of data I can send to the auth server and (reasonably) expect to get a reply with it included. The OPT record is omitted from dnssec signatures, so it being lost is not going to be sufficient to cause us to drop packets on the floor, unless when edns0 becomes manditory we include this option as manditory as well. I am not holding my breath. --Michael ------------=_1205526522-33290-37 Content-Type: text/plain; name="SpamAssassinReport.txt" Content-Disposition: inline; filename="SpamAssassinReport.txt" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Spam detection software, running on the system "mail.ogud.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: [ 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. ] [...] Content analysis details: (2.5 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.4 HEADER_SPAM Bulk email fingerprint (header-based) found 1.3 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS ------------=_1205526522-33290-37-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 13:34:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84D23A69E8; Fri, 14 Mar 2008 13:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[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 eYiZ-0Yf2grK; Fri, 14 Mar 2008 13:34:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B74F3A6852; Fri, 14 Mar 2008 13:34:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaGVd-000AjF-Hz for namedroppers-data@psg.com; Fri, 14 Mar 2008 20:28:09 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaGVZ-000AiU-ST for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 20:28:07 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2EKS1MF034572 for ; Fri, 14 Mar 2008 16:28:01 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2EKS1PY034571 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 16:28:01 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JZu8j-0002Ab-3m for namedroppers@ops.ietf.org; Thu, 13 Mar 2008 20:35:05 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 4E0E6327A72; Thu, 13 Mar 2008 13:35:00 -0700 (PDT) Received: from dhcp-3443.ietf71.ietf.org (dhcp-3443.ietf71.ietf.org [130.129.52.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 85F92327A5A; Thu, 13 Mar 2008 13:34:58 -0700 (PDT) From: Michael Graff To: "W.C.A. Wijngaards" Subject: Re: dns-0x20 mismatches Date: Thu, 13 Mar 2008 10:34:53 -0500 User-Agent: KMail/1.9.9 Cc: bert hubert , Paul Vixie , namedroppers@ops.ietf.org References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> In-Reply-To: <47D987E3.5070206@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1205526481-33290-36" Content-Disposition: inline Message-Id: <200803131034.53400.explorer@flame.org> X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is a multi-part message in MIME format... ------------=_1205526481-33290-36 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline [ 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 Thursday 13 March 2008 15:00:35 W.C.A. Wijngaards wrote: > I do not understand, are the authoritative servers for maps.l.google.com > not copying the query section to the answer? > You seem to imply this is working from a stored set of data - how does > that include the algorithm used by the authority server? It turns out it depends on who behind each l.google.com name server responds: ; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @b.l.google.com mAps.L.GoOgLe.CoM ;maps.l.google.com. IN A ; <<>> DiG 9.4.1-P1 <<>> @c.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @d.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @e.l.google.com mAps.L.GoOgLe.CoM ;maps.l.google.com. IN A ; <<>> DiG 9.4.1-P1 <<>> @f.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @g.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A (running script again) ; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @b.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @c.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @d.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @e.l.google.com mAps.L.GoOgLe.CoM ;maps.l.google.com. IN A ; <<>> DiG 9.4.1-P1 <<>> @f.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @g.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A (so far, "e" varies) ; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @b.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @c.l.google.com mAps.L.GoOgLe.CoM ;maps.l.google.com. IN A ; <<>> DiG 9.4.1-P1 <<>> @d.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @e.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A ; <<>> DiG 9.4.1-P1 <<>> @f.l.google.com mAps.L.GoOgLe.CoM ;maps.l.google.com. IN A ; <<>> DiG 9.4.1-P1 <<>> @g.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A (c, e, f) Running this script enough will eventually show that all of them vary. I suspect they have multiple name server types sitting behind each of these addresses, and one copies, one does not. Note that no matter what, they do not compress using the query-name: ; <<>> DiG 9.4.1-P1 <<>> @a.l.google.com mAps.L.GoOgLe.CoM ;mAps.L.GoOgLe.CoM. IN A maps.l.google.com. 300 IN A 72.14.221.147 maps.l.google.com. 300 IN A 72.14.221.104 maps.l.google.com. 300 IN A 72.14.221.103 maps.l.google.com. 300 IN A 72.14.221.99 ------------=_1205526481-33290-36 Content-Type: text/plain; name="SpamAssassinReport.txt" Content-Disposition: inline; filename="SpamAssassinReport.txt" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Spam detection software, running on the system "mail.ogud.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: [ 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. ] [...] Content analysis details: (2.5 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.4 HEADER_SPAM Bulk email fingerprint (header-based) found 1.3 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS ------------=_1205526481-33290-36-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 13:34:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3186B3A6A56; Fri, 14 Mar 2008 13:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[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 3AGe6REiLNyR; Fri, 14 Mar 2008 13:34:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23F503A6852; Fri, 14 Mar 2008 13:34:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaGWv-000B1x-PH for namedroppers-data@psg.com; Fri, 14 Mar 2008 20:29:29 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaGWh-000Axz-6w for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 20:29:17 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2EKT3UU034594 for ; Fri, 14 Mar 2008 16:29:04 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2EKT3Iu034593 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 16:29:03 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ja2Hr-000Pyo-Ru for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 05:17:01 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 48B70327A75; Thu, 13 Mar 2008 22:16:59 -0700 (PDT) Received: from [192.168.1.2] (72-255-34-109.client.stsn.net [72.255.34.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id B4B9D327A74; Thu, 13 Mar 2008 22:16:58 -0700 (PDT) From: Michael Graff To: Paul Vixie Subject: Re: dns-0x20 mismatches Date: Thu, 13 Mar 2008 19:16:53 -0500 User-Agent: KMail/1.9.9 Cc: namedroppers@ops.ietf.org References: <82019.1205443130@sa.vix.com> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> In-Reply-To: <1674.1205470225@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803131916.53597.explorer@flame.org> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion [ 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 Thursday 13 March 2008 23:50:25 Paul Vixie wrote: > i think we're likely to find middleboxes in almost every case, and hardly > ever servers. a packet-flossing firewall box might strip out the 0x20 bits > of udp/53 as it passes through because its designer thinks it'll otherwise > be used as a covert channel by bad guys. (whereas we want it for good > guys.) While I suspect some firewalls will strip things for this reason, I suspect the servers that really handle a small number of records and use pre-compiled responses are the ones that are doing the unfortunate things we're finding. I note that MOST servers will use the qname for compression, so if you mangle the domain name, you see things like: qname = FlAmE.OrG answer = FlAmE.OrG ns dns01.FlAmE.OrG etc. In Google's case, when it does copy the question, it still returns all lowercase google.com names. This hints to me that it is using pre-compiled responses, with the compression pointers starting at the first name in the pre-compiled blob, and perhaps has two iterations/implementations of DNS servers behind a balancer framework. --Michael -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 14:22:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A48C3A68C5; Fri, 14 Mar 2008 14:22:50 -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=2.106, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nsq5j925GOi; Fri, 14 Mar 2008 14:22:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3604E3A6A2D; Fri, 14 Mar 2008 14:22:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaHBM-000IIZ-Kt for namedroppers-data@psg.com; Fri, 14 Mar 2008 21:11:16 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaHBA-000IGp-Ne for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 21:11:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0B18311425; Fri, 14 Mar 2008 21:11:04 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: Robert Elz , Michael Graff , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Fri, 14 Mar 2008 20:58:15 +0100." <20080314195815.GA29051@outpost.ds9a.nl> References: <82019.1205443130@sa.vix.com> <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Mar 2008 21:11:04 +0000 Message-ID: <41607.1205529064@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > note, i am perfectly willing to follow ed lewis' advice ... > > One thing we could ponder is to modify forgery-resilience to state (or > 'clarify') that authoritative nameservers MUST do a bitwise copy of the > question field, in order to facilitate possible future 0x20-like > randomisation efforts. re-reading http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-02 just now, i am struck by the mismatch between the meaning of the words in 4.1 and the name of the section for 4.1. can you consider renaming this section, or moving most of the words to some other section? that aside, i see no updates to RFC 1034 except in section 9. i suggest that you change o Question (name and type) to say o Question (name, class and type) or ideally to say o Question name (compared case-insensitively) o Question class o Question type in the latter case you would add the following subsection: Additionally, servers must always copy the question section from the request to the response, without modifications of any kind, including but not limited to changing the ASCII upper/lower case status of any character of the question name. and also the following subsubsection after "Assure that its choices...": o Requestor can use the 0x20 bits of any ASCII letter (A-Z, a-z) in the question name as an additional source of transaction identity, perhaps by randomizing them, as long as such randomization is undone in the response before decompression. and this, in the same spot: o If a requestor is multihomed or otherwise has the ability to transmit and receive datagrams using more than one IP address, then an IP address can be chosen at random in order to increase an attacker's difficulty in guessing what address to flood. and this, in the same spot: o If a requestor knows more than one authority server address for a particular zone, then it should choose one randomly in order to increase an attacker's difficulty in guessing a spoofed source address. If authority server RTT is being measured and used to "sort" addresses in order of "closeness", then, these should be grouped into RTT bands of approximately 100ms, and randomized within these bands. you can remove this text: If a resolver sends out multiple equivalent questions to any authoritative server, before receiving an answer, all MUST have identical ID, source address and source port. since it merely restates RFC 1035 and does not update or clarify anything. you should add this text in that spot: If any attribute of the question contained in a response mismatches that attribute of the question in the request, then the question is semantically invalid, and should be treated the same as if it had been syntactically invalid (a so-called "format error"). > But this all depends on the WG reaction - if this is controversial, and > forgery-resilience becomes controversial in turn, I (modestly) think the > ensuing delay of this draft would be a loss. understood, and i don't blame you. but i hope the WG yawns, rolls over, says "OK by me", and allows the above modifications, which will then recommend that every requestor randomize every randomizable member of the tuple used for matching answers to questions, and require that any server who downcases or otherwise modifies a qname, stop doing so. > 0x20 can then follow at leasure, as a separate effort - we've written down > the requirement in that case. > > Thoughts? i'm still hoping to do this in a single RFC that gathers all current knowledge on this topic. dns-0x20 would not even need to be published, in any form, if the above modifications were made. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 18:17:41 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645F43A6A0B; Fri, 14 Mar 2008 18:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R80LSjtoJ4+2; Fri, 14 Mar 2008 18:17:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B43B3A69A3; Fri, 14 Mar 2008 18:17:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaKq3-00059I-C0 for namedroppers-data@psg.com; Sat, 15 Mar 2008 01:05:31 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaKpz-000588-5P for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 01:05:29 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2F15Me8036767 for ; Fri, 14 Mar 2008 21:05:22 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2F15MbE036766 for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 21:05:22 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaIOt-00051H-5m for namedroppers@ops.ietf.org; Fri, 14 Mar 2008 22:29:25 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2372833C1C; Fri, 14 Mar 2008 22:29:17 +0000 (GMT) Message-ID: <47DAFC46.4030107@links.org> Date: Fri, 14 Mar 2008 22:29:26 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Wouter Wijngaards CC: Namedroppers , Bert Hubert , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 References: <47D9296B.60806@nlnetlabs.nl> In-Reply-To: <47D9296B.60806@nlnetlabs.nl> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion [ 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. ] Wouter Wijngaards wrote: > It says: > ~ o Assure that its choices of port and ID cannot be predicted by an > ~ attacker having knowledge of its (pseudo-)random generator. > I do not believe an implementation can have an ability to assure its ID > choices cannot be predicted. Including a rng-breaking test into the > resolver implementation is not helpful. Instead recommend to use a > (pseudo)random generator to generate ID and port choices that is hard to > predict. I don't understand this. You are saying that to fix the predictability of a PRNG, use a PRNG instead? Good PRNGs are not predictable, btw, so long as they are fed enough entropy. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-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 Mar 15 06:39:26 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E435D28C178; Sat, 15 Mar 2008 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsgY7xDBa+PG; Sat, 15 Mar 2008 06:39:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63C833A6892; Sat, 15 Mar 2008 06:39:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaWQJ-0002Kn-1l for namedroppers-data@psg.com; Sat, 15 Mar 2008 13:27:43 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaWQB-0002J8-U2 for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 13:27:41 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaWQ8-00085q-Bp; Sat, 15 Mar 2008 14:27:32 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A0343456B; Sat, 15 Mar 2008 14:27:37 +0100 (CET) Date: Sat, 15 Mar 2008 14:27:37 +0100 From: bert hubert To: Paul Vixie Cc: Robert Elz , Michael Graff , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches Message-ID: <20080315132737.GC9053@outpost.ds9a.nl> References: <82019.1205443130@sa.vix.com> <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> <41607.1205529064@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41607.1205529064@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Fri, Mar 14, 2008 at 09:11:04PM +0000, Paul Vixie wrote: > re-reading http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-02 > just now, i am struck by the mismatch between the meaning of the words in 4.1 > and the name of the section for 4.1. can you consider renaming this section, > or moving most of the words to some other section? Wow - I'm amazed I nor anybody before you noticed this glaring error. > or ideally to say > > o Question name (compared case-insensitively) > > o Question class > > o Question type Done - kept question class and type on one line though. > Additionally, servers must always copy the question section > from the request to the response, without modifications of > any kind, including but not limited to changing the ASCII > upper/lower case status of any character of the question name. I've put this in, pending reaction from the WG. > and also the following subsubsection after "Assure that its choices...": > > o Requestor can use the 0x20 bits of any ASCII letter (A-Z, a-z) > in the question name as an additional source of transaction > identity, perhaps by randomizing them, as long as such > randomization is undone in the response before decompression. This is one bit too far - we now state that authoritative servers must do bitwise copy, which is a new requirement (if present in spirit), and immediately state that it is ok to rely on this behaviour. > o If a requestor is multihomed or otherwise has the ability to > transmit and receive datagrams using more than one IP address, > then an IP address can be chosen at random in order to increase > an attacker's difficulty in guessing what address to flood. Done. > > and this, in the same spot: > > o If a requestor knows more than one authority server address for > a particular zone, then it should choose one randomly in order > to increase an attacker's difficulty in guessing a spoofed > source address. If authority server RTT is being measured and > used to "sort" addresses in order of "closeness", then, these > should be grouped into RTT bands of approximately 100ms, and > randomized within these bands. Isn't this a bit overbearing? I understand the sentiment but it is usually better not to be too exact in defining implementor behaviour. > you can remove this text: > > If a resolver sends out multiple equivalent questions to any > authoritative server, before receiving an answer, all MUST have > identical ID, source address and source port. > > since it merely restates RFC 1035 and does not update or clarify anything. Are you sure? This is the paragraph that was explicitly inserted to prevent nameservers from being vulnerable to the birthday attack caused by having identical questions with differing id's in flight. The idea being that this wasn't stated anywhere else. But I'm no 1035 scholar. > you should add this text in that spot: > > If any attribute of the question contained in a response mismatches that > attribute of the question in the request, then the question is semantically > invalid, and should be treated the same as if it had been syntactically > invalid (a so-called "format error"). Are you sure this adds anything? > i'm still hoping to do this in a single RFC that gathers all current knowledge > on this topic. dns-0x20 would not even need to be published, in any form, if > the above modifications were made. My current feeling is that it would be ok for us to clarify that servers should do a bitwise copy, something that indeed was in the spirit of 1035 already. So much so in fact that PowerDNS added support for spoofing in the correct case for answers derived from the whole packet cache in revision '2': 2 ahu cached->spoofQuestion(p->qdomain); // for correct case Which was before 2002-11-27. However, while we could describe the 0x20 extra randomisation, it is a bridge too far for me to standardise it as being instantly kosher. How about something that indicates that resolvers could do it, but with the caveat that it can cause problems until all auth servers are in compliance with the bitwise copy addition? The alternative is to leave 0x20 as a separate draft for a while, so we can safely state that the new world order that bitwise copies are mandatory has been around long enough. In the meantime, we could approach google, the .tw registry and the few other holdouts to see what they can do. Your suggestions I could apply immediately are in http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/16 Thoughts? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 07:22:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA7628C2AB; Sat, 15 Mar 2008 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.381 X-Spam-Level: * X-Spam-Status: No, score=1.381 tagged_above=-999 required=5 tests=[AWL=-2.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, 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 VXr1icAhBTut; Sat, 15 Mar 2008 07:22:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65BBE28C358; Sat, 15 Mar 2008 07:22:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaX92-000D8U-JF for namedroppers-data@psg.com; Sat, 15 Mar 2008 14:13:56 +0000 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaX8b-000Cz0-4w for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 14:13:46 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaX8Y-000176-Qt for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 15:13:26 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1B2194579; Sat, 15 Mar 2008 15:13:32 +0100 (CET) Date: Sat, 15 Mar 2008 15:13:31 +0100 From: bert hubert To: Wouter Wijngaards Cc: Namedroppers , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 Message-ID: <20080315141331.GE9053@outpost.ds9a.nl> References: <47D9296B.60806@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D9296B.60806@nlnetlabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Thu, Mar 13, 2008 at 02:17:31PM +0100, Wouter Wijngaards wrote: > I think this document is better off as a BCP or for-your-information > document, than as a standards track. It recommends best use for getting > forgery resilience, without specifying protocol elements. Wouter, thanks for your keen reading of the document! I previously feared a lack of WG-attention. Better late than never. I'm not very knowledgeable of the exact differences between RFC, BCP, standard and FYI. FYI seems to light though. > section 2 says > ~ It should be noted that the most commonly used resolver currently > ~ does not perform as well as possible in this respect, making this > ~ document of urgent importance. > Look, bashing some implementation is not very nice. If you want someone > to implement, ask them. Reword to 'most resolvers do not perform well'. This isn't meant to bash but simply to state a fact. I reworded it to: It should be noted that the most commonly used resolvers currently do not perform as well as possible in this respect, making this document of urgent importance. To spread the opprobium a bit. > section 3 says > ~ 5. It is the first answer to match the previous four conditions. > I think point 5 should be removed. There are no rules preventing you > from accepting a later response, and I do not want this document to make > one. Multiple people have mentioned this, but it is in fact rather crucial. If the window is left open for further answers, all the more chance for a fake answer to creep in. I think what you mean is: It is the first answer to match the previous four, plus possible additional, conditions. This leaves room for additional restrictions, perhaps imposed by smarter resolvers, but still indicates that once a vald answer (by some metric) is seen, other answers should be considered extraneous. > Section 4.3 Matching the source address of the authentic answer > This is an obvious place to mention the banding-RTT idea. I cannot > provide text for it, because I do know know it fully yet. So, I would > appreciate text about the RTT banding here to fixup! See my previous message (in time) to Paul Vixie regarding RTT-banding. > 4.5 says > ~ Once any packet has matched the previous four conditions, no further > ~ answers should be accepted. > Again, I do not think a rule against listening for multiple answers > should be advocated, it is even against the spirit of this document > (forgery resilience). Reword to > Most resolvers accept the first packet to match the conditions, and no > further answers are accepted. I've added the same 'additional conditions' clause. > 4.5 also says > ~ This means that the third party has a limited time in which to inject > ~ its spoofed answer, typically in the order of at most 100ms. > Should say that the time you have depends on the speed with which the > authority server is responding. This means also that by choosing a Added wording to this effect. > 5. Birthday attacks, says > ~ An attacker can benefit from this exact phenomenon if it can force > ~ the target resolver to have multiple outstanding questions at any one > ~ time for the same domain to the same authoritative server. > Shouldn't those be the same questions? Or does this also hold when there > are multiple, different questions outstanding at one time for the same > zone to the same authoritative server? Domain as different from 'zone', so the domain is the question in this case. > > 9. Countermeasures, says > ~ Additionally, resolver implementations MUST have the ability to: > I believe these are recommendations for resilience. I disagree with > MUST. Change to 'are more resilient if they have the ability to:' I politely disagree. > and says > ~ (53, or > 1024) of ports that is as large as possible; > as large as possible is not good. Grabbing every possible port is a > denial of service attack on the server itself, for having ports for > other purposes. I.e. with 65000 outstanding queries, this is not a good > recommendation. Instead, recommend that a larger range of ports results > in more spoof resilience. And the tradeoff with other port usage can > then be made. This is reflected in 'as possible', which implies 'not bringing down the server'. Using a range does not mean actually hogging the whole range. > It says: > ~ o Assure that its choices of port and ID cannot be predicted by an > ~ attacker having knowledge of its (pseudo-)random generator. > I do not believe an implementation can have an ability to assure its ID > choices cannot be predicted. Including a rng-breaking test into the > resolver implementation is not helpful. Instead recommend to use a > (pseudo)random generator to generate ID and port choices that is hard to > predict. I'm in full agreement with Ben Laurie's response on this section. > 10. security considerations. > I think that this document is almost completely useless when DNSSEC is > deployed. It may save some calculation by being able to throw away Indeed - this document is about the "interim period". Hence the somewhat strong wording. The changes based on your message above can be found in http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/17 Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 08:08:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC2928C37C; Sat, 15 Mar 2008 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKnl-6yavoEV; Sat, 15 Mar 2008 08:08:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 091FB28C2FA; Sat, 15 Mar 2008 08:07:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaXrI-000G5S-Bn for namedroppers-data@psg.com; Sat, 15 Mar 2008 14:59:40 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaXrF-000G4n-FG for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 14:59:38 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaXrD-0001z4-D7 for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 15:59:35 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B928D45A3; Sat, 15 Mar 2008 15:59:40 +0100 (CET) Date: Sat, 15 Mar 2008 15:59:40 +0100 From: bert hubert To: Edward Lewis Cc: Wouter Wijngaards , Namedroppers , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 Message-ID: <20080315145940.GH9053@outpost.ds9a.nl> References: <47D9296B.60806@nlnetlabs.nl> <20080315141331.GE9053@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Sat, Mar 15, 2008 at 10:39:09AM -0400, Edward Lewis wrote: > At 15:13 +0100 3/15/08, bert hubert wrote: > > >Multiple people have mentioned this, but it is in fact rather crucial. If > >the window is left open for further answers, all the more chance for a fake > >answer to creep in. > > Or ("all the more chance") for the real answer to creep in. The > point is, there's no guarantee that the first or last arriving answer > is more legitimate than any other arriving answer. Ok, point taken. The 'no further answers' thing is mentioned twice, both in non-normative context describing the current state of affairs. I think there is little controversy that *current* nameservers all wait for an acceptable answer to arrive, and then stop listening. How about the following modification, which further tones down the normative spirit: @@ -229,16 +229,18 @@ using the ID field in the response. - DNS data is accepted by a resolver if and only if: + DNS data is to be accepted by a resolver if and only if: The question section of the reply packet is identical to that of a question packet currently waiting for an answer The ID field of the reply packet matches that of the question packet The answer comes from the same network address the question was sent to The answer comes in on the same network address, including port number, as the question was sent from - It is the first answer to match the previous four, plus possible additional, conditions. + In general, the first answer matching these four conditions is accepted. + + If a third party succeeds in meeting the first four conditions before the answer from the authentic answer does so, it is in a position to feed a resolver fabricated data. When it does so, we dub it an attacker, attempting to spoof in fake data. @@ -368,7 +370,7 @@
Once any packet has matched the previous four conditions (plus possible additional conditions), - no further answers should be accepted. + no further answers are generally accepted. This means that the third party has a limited time in which to inject its spoofed answer, typically in the ? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 08:08:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E658828C260; Sat, 15 Mar 2008 08:08:19 -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 IxSXsX+1I6-f; Sat, 15 Mar 2008 08:08:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA50428C35D; Sat, 15 Mar 2008 08:07:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaXqY-000Fyb-Hs for namedroppers-data@psg.com; Sat, 15 Mar 2008 14:58:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaXqV-000Fxn-5l for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 14:58:53 +0000 Received: from [192.168.1.100] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2FEhAHT041665; Sat, 15 Mar 2008 10:43:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080315141331.GE9053@outpost.ds9a.nl> References: <47D9296B.60806@nlnetlabs.nl> <20080315141331.GE9053@outpost.ds9a.nl> Date: Sat, 15 Mar 2008 10:39:09 -0400 To: bert hubert From: Edward Lewis Subject: Re: dnsext-forgery-resilience-02 Cc: Wouter Wijngaards , Namedroppers , remco@virtu.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 15:13 +0100 3/15/08, bert hubert wrote: >Multiple people have mentioned this, but it is in fact rather crucial. If >the window is left open for further answers, all the more chance for a fake >answer to creep in. Or ("all the more chance") for the real answer to creep in. The point is, there's no guarantee that the first or last arriving answer is more legitimate than any other arriving answer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 15 08:24:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DB13A68BB; Sat, 15 Mar 2008 08:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[AWL=0.000, 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 S1pyUdFHyGF3; Sat, 15 Mar 2008 08:24:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7621E28B797; Sat, 15 Mar 2008 08:24:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaY6n-000I4s-9x for namedroppers-data@psg.com; Sat, 15 Mar 2008 15:15:41 +0000 Received: from [85.17.178.135] (helo=spalding.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaY6j-000I4G-UA for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 15:15:39 +0000 Received: from localhost (localhost [127.0.0.1]) by spalding.dds.nl (Postfix) with ESMTP id 4B1931F86A3; Sat, 15 Mar 2008 16:15:37 +0100 (CET) Received: from spalding.dds.nl ([127.0.0.1]) by localhost (spalding.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17687-03; Sat, 15 Mar 2008 16:15:33 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spalding.dds.nl (Postfix) with ESMTP id 042B61F86B4; Sat, 15 Mar 2008 16:15:30 +0100 (CET) Message-ID: <47DBE80D.2010303@nlnetlabs.nl> Date: Sat, 15 Mar 2008 16:15:25 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: bert hubert CC: Namedroppers , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 References: <47D9296B.60806@nlnetlabs.nl> <20080315141331.GE9053@outpost.ds9a.nl> In-Reply-To: <20080315141331.GE9053@outpost.ds9a.nl> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/6248/Sat Mar 15 15:08:59 2008 on spalding.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bert, For your questions, bert hubert wrote: | This isn't meant to bash but simply to state a fact. I reworded it to: Much better |> section 3 says |> ~ 5. It is the first answer to match the previous four conditions. |> I think point 5 should be removed. There are no rules preventing you |> from accepting a later response, and I do not want this document to make |> one. | | Multiple people have mentioned this, but it is in fact rather crucial. If | the window is left open for further answers, all the more chance for a fake | answer to creep in. | | I think what you mean is: | | It is the first answer to match the previous four, plus possible | additional, conditions. | | This leaves room for additional restrictions, perhaps imposed by smarter | resolvers, but still indicates that once a vald answer (by some metric) is | seen, other answers should be considered extraneous. Yes that rewording leaves room for listening for multiple answers. Thank you. |> Section 4.3 Matching the source address of the authentic answer |> This is an obvious place to mention the banding-RTT idea. I cannot |> provide text for it, because I do know know it fully yet. So, I would |> appreciate text about the RTT banding here to fixup! | | See my previous message (in time) to Paul Vixie regarding RTT-banding. Excellent. Well, 'make them more random' should certainly be in there. Giving an idea to go about implementing ('take a band of 100 ms'), is OK too; but I agree with you that it should not be overly specific, as long as randomness results. I was a bit surprised you say that since the MUST issue (see below) is exactly the same concern about over specifying the implementation. |> 5. Birthday attacks, says |> ~ An attacker can benefit from this exact phenomenon if it can force |> ~ the target resolver to have multiple outstanding questions at any one |> ~ time for the same domain to the same authoritative server. |> Shouldn't those be the same questions? Or does this also hold when there |> are multiple, different questions outstanding at one time for the same |> zone to the same authoritative server? | | Domain as different from 'zone', so the domain is the question in this case. But the next section or page contains use of the word domain as 'zone'. Please change the word domain to something more descriptive (in this case and the other case). Domain -> query name, or question. |> 9. Countermeasures, says |> ~ Additionally, resolver implementations MUST have the ability to: |> I believe these are recommendations for resilience. I disagree with |> MUST. Change to 'are more resilient if they have the ability to:' | | I politely disagree. That is a bit short. I think this is an important issue. I do not support this document with MUST on the standards track. The burden of these measures is not required, only for spoof resistance, and spoof resistance may become a non-issue, or be a non-issue in certain situations or environments; that I why I advocate changing the wording to recommendations for more resiliency in the current practice. |> and says |> ~ (53, or > 1024) of ports that is as large as possible; |> as large as possible is not good. Grabbing every possible port is a |> denial of service attack on the server itself, for having ports for |> other purposes. I.e. with 65000 outstanding queries, this is not a good |> recommendation. Instead, recommend that a larger range of ports results |> in more spoof resilience. And the tradeoff with other port usage can |> then be made. | | This is reflected in 'as possible', which implies 'not bringing down the | server'. Using a range does not mean actually hogging the whole range. I did not read it like that. I think the text is vulnerable to misinterpretation. |> It says: |> ~ o Assure that its choices of port and ID cannot be predicted by an |> ~ attacker having knowledge of its (pseudo-)random generator. |> I do not believe an implementation can have an ability to assure its ID |> choices cannot be predicted. Including a rng-breaking test into the |> resolver implementation is not helpful. Instead recommend to use a |> (pseudo)random generator to generate ID and port choices that is hard to |> predict. | | I'm in full agreement with Ben Laurie's response on this section. There is a grammar problem here. I am looking at 'who MUST do this' and everyone else is looking at PRNG vs Entropy. Your bullet points are preceded with 'the implementation MUST'. This point raises issues to be taken by the *implementor*. Please reword for the grammar, I seem to have failed to make it better. To repeat, the PRNG and real randomness that everybody seems to stumble over is not my concern at all (that is to say, I agree already). |> 10. security considerations. |> I think that this document is almost completely useless when DNSSEC is |> deployed. It may save some calculation by being able to throw away | | Indeed - this document is about the "interim period". Hence the somewhat | strong wording. Well I strongly disagree with that strong wording. After DNSSEC deployment, the strong wording leaves resolvers with a burden of implementation troubles (catching ports, tough (P)RNG requirements, doing odd stuff to qnames) that is simply not required any more. I would like to change those MUSTs, so that in the longer future than today and tomorrow, implementations are not forced to needlessly implement this. Thanks for the quick editor function. The recommendations are good; certainly for the 'interim period', so I think it is a good idea to write them down. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH2+gNkDLqNwOhpPgRAvDYAJ9tetruvcv/nsH+kexYU4uPEY4ckACcD4jy mtHhOKwN868GV5DVQyJfROs= =L1Va -----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 Sat Mar 15 08:50:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683DF3A6A9A; Sat, 15 Mar 2008 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x2nFQZFSlP3; Sat, 15 Mar 2008 08:50:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D3183A6A77; Sat, 15 Mar 2008 08:50:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaYY1-000NED-LB for namedroppers-data@psg.com; Sat, 15 Mar 2008 15:43:49 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaYXy-000NDN-GK for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 15:43:48 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaYXv-0002zI-Sv for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 16:43:43 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 28B834029; Sat, 15 Mar 2008 16:43:48 +0100 (CET) Date: Sat, 15 Mar 2008 16:43:48 +0100 From: bert hubert To: "W.C.A. Wijngaards" Cc: Namedroppers , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 Message-ID: <20080315154348.GI9053@outpost.ds9a.nl> References: <47D9296B.60806@nlnetlabs.nl> <20080315141331.GE9053@outpost.ds9a.nl> <47DBE80D.2010303@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DBE80D.2010303@nlnetlabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Sat, Mar 15, 2008 at 04:15:25PM +0100, W.C.A. Wijngaards wrote: > | Domain as different from 'zone', so the domain is the question in this > case. > > But the next section or page contains use of the word domain as 'zone'. > Please change the word domain to something more descriptive (in this > case and the other case). Domain -> query name, or question. Reworded to: An attacker can benefit from this exact phenomenon if it can force the target resolver to have multiple equivalent outstanding questions at any one time to the same authoritative server. I always mess up DNS wording.. > | This is reflected in 'as possible', which implies 'not bringing down the > | server'. Using a range does not mean actually hogging the whole range. > > I did not read it like that. I think the text is vulnerable to > misinterpretation. Added 'and practicable', I hope this clarifies things enough. > There is a grammar problem here. I am looking at 'who MUST do this' and > everyone else is looking at PRNG vs Entropy. Your bullet points are > preceded with 'the implementation MUST'. This point raises issues to be > taken by the *implementor*. Please reword for the grammar, I seem to have > failed to make it better. Hmm, I think I have improved things, but I'm not sure if this addresses the issue. ++++++++ Use an unpredictable source port for outgoing queries from a range (53, or > 1024) of ports that is as large as possible and practicable; Use multiple different source ports simultaneously in case of multiple outstanding questions; Use an unpredictable query ID for outgoing queries, utilizing the full range available (0-65535); In case these abilities are enabled, the implementation MUST strive to have its choices of source port and question ID remain unpredictable, even if an attacker has knowledge of its (pseudo-)random generator. +++++++ This states the desired result, and the effort that should be taken, but does not mandate the use of mathematically proven perfect PRNGs (which I doubt exist - hard to prove a negative). > Well I strongly disagree with that strong wording. After DNSSEC > deployment, the strong wording leaves resolvers with a burden of In this message, I've only addressed issues besides 'MUST' and 'after DNSSEC' deployment, which I hope we can address after the editorial things have settled down. > Thanks for the quick editor function. The recommendations are good; > certainly for the 'interim period', so I think it is a good idea to > write them down. Perhaps we could add wording that waives these rules for resolvers that otherwise validate answers? Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 09:58:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BFD3A6868; Sat, 15 Mar 2008 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, GB_I_LETTER=-2, 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 egeQlyiYOsEl; Sat, 15 Mar 2008 09:58:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A37D53A68D2; Sat, 15 Mar 2008 09:58:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaZZg-000B20-VO for namedroppers-data@psg.com; Sat, 15 Mar 2008 16:49:36 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaZZc-000Azy-IF for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 16:49:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 89CFB11429; Sat, 15 Mar 2008 16:49:29 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20 mismatches In-Reply-To: Your message of "Sat, 15 Mar 2008 14:27:37 +0100." <20080315132737.GC9053@outpost.ds9a.nl> References: <82019.1205443130@sa.vix.com> <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> <41607.1205529064@sa.vix.com> <20080315132737.GC9053@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 15 Mar 2008 16:49:29 +0000 Message-ID: <85595.1205599769@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > and also the following subsubsection after "Assure that its choices...": > > > > o Requestor can use the 0x20 bits of any ASCII letter (A-Z, a-z) > > in the question name as an additional source of transaction > > identity, perhaps by randomizing them, as long as such > > randomization is undone in the response before decompression. > > This is one bit too far - we now state that authoritative servers must do > bitwise copy, which is a new requirement (if present in spirit), and > immediately state that it is ok to rely on this behaviour. either the rfc believes what it says, consistently and throughout, or not. > > and this, in the same spot: > > > > o If a requestor knows more than one authority server address for > > a particular zone, then it should choose one randomly in order > > to increase an attacker's difficulty in guessing a spoofed > > source address. If authority server RTT is being measured and > > used to "sort" addresses in order of "closeness", then, these > > should be grouped into RTT bands of approximately 100ms, and > > randomized within these bands. > > Isn't this a bit overbearing? I understand the sentiment but it is usually > better not to be too exact in defining implementor behaviour. try this: o If a requestor knows more than one authority server address for a particular zone, then it should choose one randomly in order to increase an attacker's difficulty in guessing a spoofed source address. If authority server RTT is being measured and used to "sort" addresses in order of "closeness", then, some method must be used to preserve randomness in selection, such as RTT banding. > > you can remove this text: > > > > If a resolver sends out multiple equivalent questions to any > > authoritative server, before receiving an answer, all MUST have > > identical ID, source address and source port. > > > > since it merely restates RFC 1035 and does not update or clarify anything. > > Are you sure? This is the paragraph that was explicitly inserted to prevent > nameservers from being vulnerable to the birthday attack caused by having > identical questions with differing id's in flight. > > The idea being that this wasn't stated anywhere else. But I'm no 1035 > scholar. try this: Note that selection of a query ID is part of the transformation of a user request into a query (described in RFC 1035 7.1) rather than part of the transmission of the query to name servers (described in RFC 1035 7.2) and as such, the same query ID must be present on all retransmissions of a given query to a given server. Similar care must be taken to preserve the request's source IP address and source UDP port number. If a server has multiple addresses (that is, its NS RR points to multiple A and AAAA RRs) then the stability of query ID and requestor UDP port number must be preserved across all transmissions and retransmissions to all addresses of that server. However, if a user request ultimately causes queries to be transmitted to multiple name servers (that is, different NS RR values) due to nonresponse or errored response from the first name server chosen, then each server SHOULD be sent a new query, having its own randomly chosen query ID, UDP source port, question name 0x20 values, and potentially its own requestor source IP address. that is, if we're going to fix what's wrong with RFC 1035 on this topic, it's a bigger job than restating implications. > > you should add this text in that spot: > > > > If any attribute of the question contained in a response mismatches > > that attribute of the question in the request, then the question is > > semantically invalid, and should be treated the same as if it had been > > syntactically invalid (a so-called "format error"). > > Are you sure this adds anything? yes, because otherwise a requestor would ignore this response outright, such that it would not choose its next server until its current request times out. this is a tradeoff between "when under attack, a requestor should become more aggressive about trying other servers" vs. "when speaking through a middlebox, a requestor should experience long timeouts and low performance." i chose the first alternative because trying other servers yields better security, it closes and opens more transmission contexts, faster, each with its own random UDP ports and so on. note that by not waiting for the first response, an ttack will result in more lookup failures, and that DNS in general will be more fragile. i'm imagining this poor damned non-DNSSEC resolver flinging a query into the great beyond, and then standing its ground while a whole lot of similar looking responses storm back at it, which it has to delicately examine, and each of them can try harder than the last to look like what's desired. i'm not liking the odds. however, in times of high port churn it's easy to imagine that a late response to an earlier question arrives, not as a blizzard but as a singleton. so, in the draft, perhaps these words would be better than the above: If any attribute of the question contained in a response mismatches that attribute of the question in the request, then the entire response is semantically invalid, and if an unreasonably high number (say, a dozen) such responses are encountered, then the requestor should behave as though a syntactically invalid response (a so-called "format error") had been received, which would normally lead to trying the next available server. > ... > However, while we could describe the 0x20 extra randomisation, it is a > bridge too far for me to standardise it as being instantly kosher. > > How about something that indicates that resolvers could do it, but with the > caveat that it can cause problems until all auth servers are in compliance > with the bitwise copy addition? then the RFC should describe the behaviour and set a date. RFC 1 mentions dates, so, these documents don't have to be completely timeless. or, say something like "randomizing the 0x20 bits may lead to resolution failures in the short term, since some responders and middleboxes strip these bits when copying the question from the request to the response, so, requestors are advised to be tolerant of mismatches, for example, by retrying three or four times, with different query ID, UDP port, and 0x20 values, if all of a zone's name servers seem to be stripping the 0x20 values out of questions." the goal here is to penalize 0x20-strippers by sending them more traffic, while making the spoofer's goal harder, since spoofers will have to win a query-ID and UDP-port (and server-address and client-address) race not once or twice but "three or four times" before they can successfully poison us. > The alternative is to leave 0x20 as a separate draft for a while, so we can > safely state that the new world order that bitwise copies are mandatory has > been around long enough. > > In the meantime, we could approach google, the .tw registry and the few > other holdouts to see what they can do. > > Your suggestions I could apply immediately are in > http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/16 > > Thoughts? i really feel that the security level delta between "nothing" and "randomize some things" is smaller than the delta between "randomize some things" and "randomize everything". so, to me, there is no point to a two-RFC solution. -- to unsubscribe send a message to namedroppers-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 Mar 15 10:44:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E5C3A67FC; Sat, 15 Mar 2008 10:44:30 -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.104, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNDIeWOKmj1h; Sat, 15 Mar 2008 10:44:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F32C73A67B4; Sat, 15 Mar 2008 10:44:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaaJC-000LTw-2E for namedroppers-data@psg.com; Sat, 15 Mar 2008 17:36:38 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaaJ8-000LSx-R3 for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 17:36:36 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaaJ5-0005pF-4b; Sat, 15 Mar 2008 18:36:31 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 74DF440C6; Sat, 15 Mar 2008 18:36:36 +0100 (CET) Date: Sat, 15 Mar 2008 18:36:36 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: dear wg: 0x20 safe to mandate or not? Time limit? Message-ID: <20080315173636.GA13857@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> <41607.1205529064@sa.vix.com> <20080315132737.GC9053@outpost.ds9a.nl> <85595.1205599769@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85595.1205599769@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul, I'm splitting my answer in to two keep things clear, which I hope will prevent WG-fatigue from developing further. First the 0x20 mix-in, I'll reply separately to your other points. You and I wrote: > > This is one bit too far - we now state that authoritative servers must do > > bitwise copy, which is a new requirement (if present in spirit), and > > immediately state that it is ok to rely on this behaviour. > > either the rfc believes what it says, consistently and throughout, or not. And: > > How about something that indicates that resolvers could do it, but with the > > caveat that it can cause problems until all auth servers are in compliance > > with the bitwise copy addition? > > then the RFC should describe the behaviour and set a date. RFC 1 mentions > dates, so, these documents don't have to be completely timeless. or, say And: > i really feel that the security level delta between "nothing" and "randomize > some things" is smaller than the delta between "randomize some things" and > "randomize everything". so, to me, there is no point to a two-RFC solution. So we are back to 'conjoin forgery resilience with dns-0x20', with the addition that since discovering that it does break things, we should first mandate bit-for-bit copying, and set a date at which point everybody is free to disregard case-variant answers. Before the cut-off date, we exhort implementations to be lenient and do repetitive queries to non-case-preserving servers, so as to gather some extra bits of security, even though they break dns-0x20. To me the above is bound to be so controversial that I predict it will sink the forgery resilience draft. So for me there are two ways we can go from here: 1) We form consensus that the above is non-controversial, and that people will still form rough consensus on last call if the above dns-0x20 rules are implemented in the forgery resilience draft 2) We only leave in the bit-for-bit copy 'MUST' in there (which doesn't hurt), and go for last call on forgery resilience. So, dear workgroup, please ponder the (non-)controversiality of dns-0x20 as outlined above. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 10:49:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0693A6991; Sat, 15 Mar 2008 10:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmv3iet4Edyp; Sat, 15 Mar 2008 10:49:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F48A3A67B4; Sat, 15 Mar 2008 10:49:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaaQP-000Mum-4z for namedroppers-data@psg.com; Sat, 15 Mar 2008 17:44:05 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaaQM-000MuA-NW for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 17:44:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D6DD111433; Sat, 15 Mar 2008 17:44:01 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: dear wg: 0x20 safe to mandate or not? Time limit? In-Reply-To: Your message of "Sat, 15 Mar 2008 18:36:36 +0100." <20080315173636.GA13857@outpost.ds9a.nl> References: <57450.1205256926@sa.vix.com> <20080313181548.GS10313@outpost.ds9a.nl> <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> <41607.1205529064@sa.vix.com> <20080315132737.GC9053@outpost.ds9a.nl> <85595.1205599769@sa.vix.com> <20080315173636.GA13857@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 15 Mar 2008 17:44:01 +0000 Message-ID: <88073.1205603041@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I'm splitting my answer in to two keep things clear, which I hope will > prevent WG-fatigue from developing further. First the 0x20 mix-in, I'll > reply separately to your other points. > ... splitting it into two has the unfortunate side effect of removing my "run the race more than once" suggestion, which allows servers to bit-strip 0x20 at the cost of having to answer every question multiple times. that may be the difference needed to get a positive answer to your question here: > ... > So for me there are two ways we can go from here: > > 1) We form consensus that the above is non-controversial, and that people > will still form rough consensus on last call if the above dns-0x20 rules are > implemented in the forgery resilience draft > > 2) We only leave in the bit-for-bit copy 'MUST' in there (which doesn't > hurt), and go for last call on forgery resilience. > > So, dear workgroup, please ponder the (non-)controversiality of dns-0x20 as > outlined above. -- to unsubscribe send a message to namedroppers-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 Mar 15 10:53:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8612A3A6876; Sat, 15 Mar 2008 10:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSFStFF2WTsQ; Sat, 15 Mar 2008 10:53:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A12203A67B4; Sat, 15 Mar 2008 10:53:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaaTV-000Ngd-G7 for namedroppers-data@psg.com; Sat, 15 Mar 2008 17:47:17 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JaaTS-000Nfi-DH for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 17:47:15 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JaaTQ-0006Ni-6E; Sat, 15 Mar 2008 18:47:12 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7E5B640C8; Sat, 15 Mar 2008 18:47:17 +0100 (CET) Date: Sat, 15 Mar 2008 18:47:17 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: dear wg: 0x20 safe to mandate or not? Time limit? Message-ID: <20080315174717.GB13857@outpost.ds9a.nl> References: <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> <41607.1205529064@sa.vix.com> <20080315132737.GC9053@outpost.ds9a.nl> <85595.1205599769@sa.vix.com> <20080315173636.GA13857@outpost.ds9a.nl> <88073.1205603041@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88073.1205603041@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Sat, Mar 15, 2008 at 05:44:01PM +0000, Paul Vixie wrote: > > I'm splitting my answer in to two keep things clear, which I hope will > > prevent WG-fatigue from developing further. First the 0x20 mix-in, I'll > > reply separately to your other points. > > ... > > splitting it into two has the unfortunate side effect of removing my "run > the race more than once" suggestion, which allows servers to bit-strip 0x20 > at the cost of having to answer every question multiple times. that may be > the difference needed to get a positive answer to your question here: No, it was in there: Before the cut-off date, we exhort implementations to be lenient and do repetitive queries to non-case-preserving servers, so as to gather some extra bits of security, even though they break dns-0x20. I just summarised it rather briefly. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 11:29:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C403A6C0B; Sat, 15 Mar 2008 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3wCI0fH5JPy; Sat, 15 Mar 2008 11:29:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C350F3A684E; Sat, 15 Mar 2008 11:29:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jaawi-0004gH-I3 for namedroppers-data@psg.com; Sat, 15 Mar 2008 18:17:28 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jaawg-0004fk-4N for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 18:17:27 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7430311433; Sat, 15 Mar 2008 18:17:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: dear wg: 0x20 safe to mandate or not? Time limit? In-Reply-To: Your message of "Sat, 15 Mar 2008 18:47:17 +0100." <20080315174717.GB13857@outpost.ds9a.nl> References: <47D987E3.5070206@nlnetlabs.nl> <200803131034.53400.explorer@flame.org> <798.1205454577@epsilon.noi.kre.to> <1674.1205470225@sa.vix.com> <20080314195815.GA29051@outpost.ds9a.nl> <41607.1205529064@sa.vix.com> <20080315132737.GC9053@outpost.ds9a.nl> <85595.1205599769@sa.vix.com> <20080315173636.GA13857@outpost.ds9a.nl> <88073.1205603041@sa.vix.com> <20080315174717.GB13857@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 15 Mar 2008 18:17:20 +0000 Message-ID: <89374.1205605040@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > splitting it into two has the unfortunate side effect of removing my "run > > the race more than once" suggestion, which allows servers to bit-strip 0x20 > > at the cost of having to answer every question multiple times. that may be > > the difference needed to get a positive answer to your question here: > > No, it was in there: > > Before the cut-off date, we exhort implementations to be lenient and do > repetitive queries to non-case-preserving servers, so as to gather some > extra bits of security, even though they break dns-0x20. > > I just summarised it rather briefly. too briefly, then. what i wrote was that one has to try all of a zone's servers before retrying any, if the basis is 0x20 failure, and then a given server has to solve the QID and UDP Port puzzle at least three or four times before we'll believe that it's a 0x20 bit stripper. -- to unsubscribe send a message to namedroppers-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 Mar 15 12:01:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C4328C3E3; Sat, 15 Mar 2008 12:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=1.642, 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 o6-esxXmQofQ; Sat, 15 Mar 2008 12:01:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1648928C2FD; Sat, 15 Mar 2008 12:00:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JabVc-000Bnn-KQ for namedroppers-data@psg.com; Sat, 15 Mar 2008 18:53:32 +0000 Received: from [32.97.110.150] (helo=e32.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JabVV-000BmF-Td for namedroppers@ops.ietf.org; Sat, 15 Mar 2008 18:53:28 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2FIqCGT023380 for ; Sat, 15 Mar 2008 14:52:12 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2FIrJ8F222136 for ; Sat, 15 Mar 2008 12:53:19 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2FIrJXJ004570 for ; Sat, 15 Mar 2008 12:53:19 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-216-211.wecm.ibm.com [9.67.216.211]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2FIrHl6004519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 12:53:18 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m2FIrFM1023080; Sat, 15 Mar 2008 11:53:16 -0700 Message-Id: <200803151853.m2FIrFM1023080@cichlid.raleigh.ibm.com> To: David Conrad cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: top-level domains (was Re: dns-0x20.txt) In-reply-to: References: <69903.1204047792@sa.vix.com> <20080312171930.GA9404@laperouse.bortzmeyer.org> <63525703-FE53-487E-B980-832A1F28AC55@virtualized.org> <20080312194905.GA27798@vacation.karoshi.com.> <28294.1205354928@sa.vix.com> Comments: In-reply-to David Conrad message dated "Wed, 12 Mar 2008 15:02:01 -0700." Date: Sat, 15 Mar 2008 11:53:15 -0700 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > >> ..., but I'd say numeric TLDs are just a bad idea. > > > > in the grand scheme of things i fear .EXE more than i fear .123, > > though. Then you might want to read: "DNS Stability: The Effect of New Generic Top Level Domains on the Internet Domain Name System" http://www.icann.org/topics/dns-stability-draft-paper-06feb08.pdf and provide input (see http://www.icann.org/public_comment/#newgtlds-dns-stability). I quote here the relevant text: > File Extensions > > ICANN has also considered the possible impact of allowing > commonly-used file extensions as TLDs in the root, examining whether > this might result in users or applications confusing URLs with > filenames, or create other vulnerabilities for the user. Examples of > such strings include: > > · .EXE · .PDF > · .HTML · .TXT > · .DOC · .MP3 > · .JPG · .GIF > · .CSV · .XLS > · .PPT · .RTF > · .ZIP > > Staff explored this issue by consulting the Security and Stability > Advisory Committee (see http://www.icann.org/committees/security/), as > well as conducting some preliminary outreach to browser and operating > system developers on the question of whether TLDs identical to file > extensions could cause technical problems when attempting to be > resolved in their particular programs. Responses to these inquiries > have indicated that if there were problems resulting from the addition > of TLD labels coinciding with common file extensions, they would be > problems of user confusion rather than breakage in the DNS. It should > also be noted that strings that are also file extensions exist as TLDs > in the DNS today without adverse effects. > > The DNS will perform look-ups of a TLD string without consideration to > its perceived meaning in another context. If a user types > "mydocument.pdf" into a browser, the auto completion rules of most > commonly-used browsers will add the "http://" notation to the front of > that string and perform a DNS lookup. Only by expressly indicating > that the user is looking for a file with file://mydocument.pdf will > the browser assume that a path to a file is indicated rather than a > domain name. These are functions of the application, however, not the > DNS. Based on this analysis, there does not appear to be a technical > need to restrict common file extensions from also being TLDs. > > The question remaining to be answered is whether there should be any > application-oriented limitations on TLD strings. If ICANN wished to > prevent potentially significant problems in the application layer or > avoid user confusion issues resulting from a string like .EXE, it > would need to do so based on a defined list of extensions that were > disallowed, a list maintained outside of ICANN and internationally > recognized as the authoritative source for "commonly used file > extensions." Additionally, a mechanism for maintaining and updating > such a list would need to be in place, because new file extensions > could become prevalent at any time. To date, staff has not been able > to locate a list of common file extensions that is generally > acknowledged to be authoritative. > > Given preliminary feedback that there is not a technical need to > prevent file extensions as TLDs, as well as the lack of an > authoritative source of common file extensions to draw from, staff > determined that it is not workable to prevent common file extensions > from being used as TLDs. To summarize, it is the recommendation of > the ICANN technical staff to allow applications for TLD strings that > may also be commonly used for file extensions. Thomas -- to unsubscribe send a message to namedroppers-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 Mar 15 18:56:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3163A686B; Sat, 15 Mar 2008 18:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYzEh17pCpvb; Sat, 15 Mar 2008 18:56:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 911C53A6821; Sat, 15 Mar 2008 18:55:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JahqQ-0003iV-Tf for namedroppers-data@psg.com; Sun, 16 Mar 2008 01:39:26 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JahqO-0003i2-9A for namedroppers@ops.ietf.org; Sun, 16 Mar 2008 01:39:25 +0000 Received: from [10.10.10.100] ([63.209.233.192]) by mx05.gis.net; Sat, 15 Mar 2008 21:37:27 -0400 Message-ID: <47DC79D8.3040302@gis.net> Date: Sat, 15 Mar 2008 21:37:28 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> <11864.1205331327@sa.vix.com> <20080312144655.GD10313@outpost.ds9a.nl> <15397.1205336875@sa.vix.com> In-Reply-To: <15397.1205336875@sa.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: DNSEXT discussion Paul Vixie wrote: >> I'm not exactly sure what 'rtt banding' is, but I estimate it won't play >> well with such badly reported timings. And unfortunately, computers (and >> network drivers, and nics) positively suck for sub-10ms measurements. Even if >> we call Linux buggy in this respect, it remains a challenge. > > rest assured, the rtt banding discussion i overheard accounts for this kind of > slop. most operating systems can't accurately measure things shorter than a > tick, and some can't come within 10ms. "horseshows, hand grenades, and time." This is why NTP does interpolation and adjust the frequency of the clock the way it does. In the end the accuracy that NTP provides takes the limitations of the CPU's clock into account and keeps it accurate. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 21:34:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F663A6B2B; Sat, 15 Mar 2008 21:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 DNgur0moREY6; Sat, 15 Mar 2008 21:34:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 103773A6A12; Sat, 15 Mar 2008 21:34:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JakTo-0006A2-9T for namedroppers-data@psg.com; Sun, 16 Mar 2008 04:28:16 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JakTh-000694-S1 for namedroppers@ops.ietf.org; Sun, 16 Mar 2008 04:28:15 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m2G4NRWG009900; Sun, 16 Mar 2008 04:23:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m2G4NKB2009898; Sun, 16 Mar 2008 04:23:20 GMT Date: Sun, 16 Mar 2008 04:23:20 +0000 From: bmanning@vacation.karoshi.com To: "W.C.A. Wijngaards" Cc: bert hubert , Namedroppers , remco@virtu.nl Subject: Re: dnsext-forgery-resilience-02 Message-ID: <20080316042320.GA3242@vacation.karoshi.com.> References: <47D9296B.60806@nlnetlabs.nl> <20080315141331.GE9053@outpost.ds9a.nl> <47DBE80D.2010303@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DBE80D.2010303@nlnetlabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Sat, Mar 15, 2008 at 04:15:25PM +0100, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > | > | It is the first answer to match the previous four, plus possible > | additional, conditions. > | > | This leaves room for additional restrictions, perhaps imposed by smarter > | resolvers, but still indicates that once a vald answer (by some metric) is > | seen, other answers should be considered extraneous. > > Yes that rewording leaves room for listening for multiple answers. Thank > you. listening for multiple answers was the reason for the creation of the DISCOVER opcode ... QUERY is really targeted to a single qualifying answer. Is perfectly rational to expect multiple, apparently valid answers to a single query and having to use other metrics, besides DNS to sort the answers. > Best regards, > ~ Wouter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 15 21:34:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA81E3A6B7B; Sat, 15 Mar 2008 21:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctw9wEPMpb6r; Sat, 15 Mar 2008 21:34:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 078CA3A6B64; Sat, 15 Mar 2008 21:34:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JakQO-0005j3-RC for namedroppers-data@psg.com; Sun, 16 Mar 2008 04:24:44 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JakQL-0005iD-WB for namedroppers@ops.ietf.org; Sun, 16 Mar 2008 04:24:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1EE2F11436; Sun, 16 Mar 2008 04:24:41 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: mayer@gis.net cc: namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Sat, 15 Mar 2008 21:37:28 -0400." <47DC79D8.3040302@gis.net> References: <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <03FD5883-1340-4992-8484-09A7779132C1@nlnetlabs.nl> <11864.1205331327@sa.vix.com> <20080312144655.GD10313@outpost.ds9a.nl> <15397.1205336875@sa.vix.com> <47DC79D8.3040302@gis.net> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 16 Mar 2008 04:24:41 +0000 Message-ID: <12131.1205641481@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > This is why NTP does interpolation and adjust the frequency of the clock > the way it does. In the end the accuracy that NTP provides takes the > limitations of the CPU's clock into account and keeps it accurate. and indeed, ntp does a fine job at maintaining accuracy for an absolute clock. but it won't do anything to improve the accuracy of relative timers and time-differences if the hardware and kernel are sloppy. -- to unsubscribe send a message to namedroppers-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 Mar 17 08:38:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36C63A6AA4; Mon, 17 Mar 2008 08:38:25 -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 uS-iMki92x4W; Mon, 17 Mar 2008 08:38:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C89893A683D; Mon, 17 Mar 2008 08:38:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbHDF-00097Y-LR for namedroppers-data@psg.com; Mon, 17 Mar 2008 15:25:21 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbHCZ-0008yu-0W for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 15:24:52 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2HFOXlf064303 for ; Mon, 17 Mar 2008 11:24:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200803171524.m2HFOXlf064303@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Mar 2008 11:23:23 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Forgery Resilience consensus call: Qname case sensitivity Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion To focus the discussion a little bit, the current draft says: >Given the above, a resolver implementation MUST match answers to the > following attributes of the question: > > o Remote address > > o Local address > > o Query port > > o Query ID > > o Question (name and type) > > before applying DNS trustworthiness rules. Does this mean that: A. name issued in query matches exactly to name in Query section of answer B. the names match after case folding Please state your reason why you think it should be A or B. Based on this we can then assert what/if FR draft should tell responders to do if they want their answer believed. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 09:48:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90C33A6DF2; Mon, 17 Mar 2008 09:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 OoC5o+qFz-Zc; Mon, 17 Mar 2008 09:48:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBEEC3A68B7; Mon, 17 Mar 2008 09:48:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbINE-0001N2-Ur for namedroppers-data@psg.com; Mon, 17 Mar 2008 16:39:44 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbILt-0000rB-4I for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 16:38:53 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JbILs-00082V-4I; Mon, 17 Mar 2008 12:38:20 -0400 Message-ID: <47DE9E77.9070101@ca.afilias.info> Date: Mon, 17 Mar 2008 12:38:15 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= CC: namedroppers@ops.ietf.org Subject: Re: Forgery Resilience consensus call: Qname case sensitivity References: <200803171524.m2HFOXlf064303@ogud.com> In-Reply-To: <200803171524.m2HFOXlf064303@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Ólafur Guðmundsson /DNSEXT chair wrote: > > To focus the discussion a little bit, the current draft says: >> Given the above, a resolver implementation MUST match answers to the >> following attributes of the question: >> >> o Remote address >> >> o Local address >> >> o Query port >> >> o Query ID >> >> o Question (name and type) >> >> before applying DNS trustworthiness rules. > > Does this mean that: > A. name issued in query matches exactly to name in Query section > of answer > B. the names match after case folding > IMHO, the correct answer is (A). > Please state your reason why you think it should be A or B. > The basic problem is a zero-information, first-order problem. There are any number of ways case folding *could* be done: - to lower - to upper - to match the query (folding the answer) - to match the answer (folding the query) - to match any element of the delegation chain or other kinds of sources of data, e.g. parent label vs RR label(s) And, in order to validate anything that isn't an exact match, would require doing a query on one of the above. But, there is no authoritative/definitive source of non-case-folded data among those, to ascertain which way case folding might have been done. Which means, there is no way to know if case folding should have been expected, versus untrusted injected data. The fact that case folding (for comparisons) is permitted, does not define which way case folding results should be expected (e.g. to-lower *only*). It creates a circular dependency when trying to validate case-folded data. > Based on this we can then assert what/if FR draft should tell > responders to > do if they want their answer believed. I believe Paul Vixie's currently demonstrated method - test all authority servers known, if case-folded answers are seen - is what askers should do. If responders want their answer believed, they have to copy bit-for-bit the original query into the question section of the response. Brian Dickson -- to unsubscribe send a message to namedroppers-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 Mar 17 10:29:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE16D3A6946; Mon, 17 Mar 2008 10:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.195 X-Spam-Level: X-Spam-Status: No, score=-108.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoAbqnHS0PyN; Mon, 17 Mar 2008 10:29:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A757F3A6882; Mon, 17 Mar 2008 10:29:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbJ2v-000DPT-UP for namedroppers-data@psg.com; Mon, 17 Mar 2008 17:22:49 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbJ2q-000DOU-UU for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 17:22:47 +0000 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 17 Mar 2008 10:23:02 -0700 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.240.5; Mon, 17 Mar 2008 10:22:42 -0700 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Mon, 17 Mar 2008 10:22:49 -0700 From: Yue Luo To: Paul Vixie , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= CC: "namedroppers@ops.ietf.org" Date: Mon, 17 Mar 2008 10:22:26 -0700 Subject: RE: Forgery Resilience consensus call: Qname case sensitivity Thread-Topic: Forgery Resilience consensus call: Qname case sensitivity Thread-Index: AciITzoNjcNZKyIURS2Vq4l5t61zOAABCc1A Message-ID: <7F2791CD3A148642AF9069A0336EDE85379243CF1D@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> References: <200803171524.m2HFOXlf064303@ogud.com> <91717.1205772609@sa.vix.com> In-Reply-To: <91717.1205772609@sa.vix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I completely agree with Paul. Thanks. Yue -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Paul Vixie Sent: Monday, March 17, 2008 9:50 AM To: =D3lafur Gu=F0mundsson /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: Re: Forgery Resilience consensus call: Qname case sensitivity > To focus the discussion a little bit, the current draft says: > >Given the above, a resolver implementation MUST match answers to the > > following attributes of the question: > > > > o Remote address > > > > o Local address > > > > o Query port > > > > o Query ID > > > > o Question (name and type) > > > > before applying DNS trustworthiness rules. > > Does this mean that: > > A. name issued in query matches exactly to name in Query section of > answer > > B. the names match after case folding > > Please state your reason why you think it should be A or B. i think it has to mean B until dns-0x20 is contemplated and standardized. > Based on this we can then assert what/if FR draft should tell responders = to > do if they want their answer believed. given that dns-0x20 has become controversial, i withdraw my previous suggestion that forgery-resilience contain a reference to 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: -- to unsubscribe send a message to namedroppers-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 Mar 17 11:00:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D203A6E6C; Mon, 17 Mar 2008 11:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 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, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xh7bH6XHEva; Mon, 17 Mar 2008 11:00:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB2013A696D; Mon, 17 Mar 2008 11:00:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbJWS-000Jhc-Cf for namedroppers-data@psg.com; Mon, 17 Mar 2008 17:53:20 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbJWJ-000Jfg-6H for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 17:53:15 +0000 Received: from [10.31.68.55] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2HHr5rf065761; Mon, 17 Mar 2008 13:53:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200803171524.m2HFOXlf064303@ogud.com> References: <200803171524.m2HFOXlf064303@ogud.com> Date: Mon, 17 Mar 2008 13:49:33 -0400 To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT__chair?= From: Edward Lewis Subject: Re: Forgery Resilience consensus call: Qname case sensitivity Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 11:23 -0400 3/17/08, =D3lafur Gu=F0mundsson /DNSEXT chair wrote: >Does this mean that: >A. name issued in query matches exactly to=20 >name in Query section of answer >B. the names match after case folding DNS has always defined name matching as B. > >Please state your reason why you think it should be A or B. =46rankly, when I read this the first time my=20 reaction was "how are A and B different?" An=20 exact match of labels in DNS parlance has meant=20 post-case folding (as opposed to an in-exact=20 match of a wild card). In AXFR "clarify" we are running into the issue=20 that "matching" for the purpose of generating a=20 response is not the same as "matching" for the=20 purpose of message compression. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 17 12:28:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6028E3A6C88; Mon, 17 Mar 2008 12:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKNwmS8C9dFB; Mon, 17 Mar 2008 12:28:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EE3B3A6D99; Mon, 17 Mar 2008 12:28:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbKsy-000Em9-Tv for namedroppers-data@psg.com; Mon, 17 Mar 2008 19:20:40 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbKsb-000EhM-EX for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 19:20:23 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JbKsT-0005T9-Jf; Mon, 17 Mar 2008 20:20:09 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D71D44106; Mon, 17 Mar 2008 20:20:14 +0100 (CET) Date: Mon, 17 Mar 2008 20:20:14 +0100 From: bert hubert To: Paul Vixie Cc: ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: Forgery Resilience consensus call: Qname case sensitivity Message-ID: <20080317192014.GB21149@outpost.ds9a.nl> References: <200803171524.m2HFOXlf064303@ogud.com> <91717.1205772609@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91717.1205772609@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mon, Mar 17, 2008 at 04:50:09PM +0000, Paul Vixie wrote: > > Please state your reason why you think it should be A or B. > i think it has to mean B until dns-0x20 is contemplated and standardized. Agreed ('case-folding comparisons'). > > Based on this we can then assert what/if FR draft should tell responders to > > do if they want their answer believed. > > given that dns-0x20 has become controversial, i withdraw my previous > suggestion that forgery-resilience contain a reference to it. In the mean time, after doing my own measurements and experiments, I will be implementing dns-0x20 for real including the advanced 'bit stripper' countermeasures suggested by Paul. My wish is to ship forgery resilience in uncontroversial form, after which we'll have time to hash out dns-0x20. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 13:55:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1536B28C48F; Mon, 17 Mar 2008 13:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.753 X-Spam-Level: **** X-Spam-Status: No, score=4.753 tagged_above=-999 required=5 tests=[AWL=7.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FszCsMu+hD2m; Mon, 17 Mar 2008 13:55:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFBC328C23A; Mon, 17 Mar 2008 13:55:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbM8s-0006sW-A3 for namedroppers-data@psg.com; Mon, 17 Mar 2008 20:41:10 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbM8k-0006qr-K8 for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 20:41:04 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DECC511425; Mon, 17 Mar 2008 20:41:01 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: Forgery Resilience consensus call: Qname case sensitivity In-Reply-To: Your message of "Mon, 17 Mar 2008 20:20:14 +0100." <20080317192014.GB21149@outpost.ds9a.nl> References: <200803171524.m2HFOXlf064303@ogud.com> <91717.1205772609@sa.vix.com> <20080317192014.GB21149@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 17 Mar 2008 20:41:01 +0000 Message-ID: <1117.1205786461@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > My wish is to ship forgery resilience in uncontroversial form, after which > we'll have time to hash out dns-0x20. > > Bert in that case, you should remove the must-copy-question logic from your i-d, since it doesn't relate to the rest of what you're saying. -- to unsubscribe send a message to namedroppers-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 Mar 17 14:19:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEB428C3C7; Mon, 17 Mar 2008 14:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[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 LXV5wEupNTkl; Mon, 17 Mar 2008 14:19:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8084E3A6EE1; Mon, 17 Mar 2008 14:18:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbMbV-000Css-GC for namedroppers-data@psg.com; Mon, 17 Mar 2008 21:10:45 +0000 Received: from [216.82.241.179] (helo=mail119.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbMbP-000Crq-BE for namedroppers@ops.ietf.org; Mon, 17 Mar 2008 21:10:43 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1205788237!20965839!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 20908 invoked from network); 17 Mar 2008 21:10:37 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 17 Mar 2008 21:10:37 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2HLAbtB010150 for ; Mon, 17 Mar 2008 14:10:37 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2HLAZrt027587 for ; Mon, 17 Mar 2008 16:10:36 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2HLAYiJ027556 for ; Mon, 17 Mar 2008 16:10:34 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on dns-cookies draft vs. amplification attacks Date: Mon, 17 Mar 2008 17:10:33 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790039D07AD@de01exm64.ds.mot.com> In-Reply-To: <200803110936.42523.michael_graff@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on dns-cookies draft vs. amplification attacks Thread-Index: AciDsrUW0yqBUmadS1uS0mFjdXbSSwEvEbXg References: <200803110936.42523.michael_graff@isc.org> From: "Eastlake III Donald-LDE008" To: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I had originally planned to push for making this a working group draft but have been convinced by Michaels arguments at the DNSEXT meeting and below. Cookies as described in my -03 draft only make sense if you think that draft is a step towards mandatory deployment, which seems implausible. If there is interest, I'd be happy to do a radically simplified -04 which was just an "edns0 echo". Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Michael Graff Sent: Tuesday, March 11, 2008 10:37 AM To: namedroppers@ops.ietf.org Subject: Comments on dns-cookies draft vs. amplification attacks My comments are with section 2.1 of the rev 3 draft. I like the cookies in the resolver-created queries, and their echo in the auth=20 server-created responses. This allows a resolver to add as many entropy bits=20 to the query id as desired to protect from out-of-band attacks. However, I=20 disagree that having the auth server check and maintain state about known=20 resolvers is of practical use. The reason it is there from discussion with Donald Eastlake was that it would=20 prevent DDoS attacks where auth servers are used as amplification attacks. I=20 do not believe the added complexity warrants this, as it is not, IMHO,=20 effective. It will protect resolvers from DDoS attacks of the amplification variety, but=20 it will not protect (say) www.google.com, which is unlikely to send queries=20 to auth servers, and therefore will never have negotiated a cookie with an=20 auth server. Thus, unless auth servers refuse to answer clients without a=20 valid cookie, meaning people have fully and universally implemented=20 dns-cookies, only recursive resolvers are actually protected from flood=20 attacks. If dns-cookies were to move forward, I'd rather see it as a "edns0 echo" and=20 make it purely client-driven, and have the server simply reply with whatever=20 the client included. The complexity of how this value is generated on the=20 client, how the server maintains this state, etc. should all be removed, and=20 only a maximum length be recommended. --Michael -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Mar 17 17:51:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C1E3A6809; Mon, 17 Mar 2008 17:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.915 X-Spam-Level: ** X-Spam-Status: No, score=2.915 tagged_above=-999 required=5 tests=[AWL=5.514, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHBQittiA8Ek; Mon, 17 Mar 2008 17:51:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FD3A28C125; Mon, 17 Mar 2008 17:51:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbPuK-0008Fp-Jp for namedroppers-data@psg.com; Tue, 18 Mar 2008 00:42:24 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbPuI-0008FH-21 for namedroppers@ops.ietf.org; Tue, 18 Mar 2008 00:42:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 518F71142F for ; Tue, 18 Mar 2008 00:42:21 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: draft-vixie-dnsext-dns0x20-00 X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Tue, 18 Mar 2008 00:42:21 +0000 Message-ID: <11421.1205800941@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --=-=-= updated text, as submitted to the draftbot, is up at http://sa.vix.com/~vixie/draft-vixie-dnsext-dns0x20-00.txt the old URL is now a symlink to this one. re: --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=2100 Content-Description: forwarded message Return-Path: X-Original-To: vixie@vix.com Delivered-To: vixie@sa.vix.com Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.isc.org", Issuer "ISC CA" (not verified)) by sa.vix.com (Postfix) with ESMTPS id 745B211429 for ; Mon, 17 Mar 2008 23:55:45 +0000 (UTC) (envelope-from wwwrun@core3.amsl.com) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by mx.isc.org (Postfix) with ESMTP id 5EB2811401E for ; Mon, 17 Mar 2008 23:55:43 +0000 (UTC) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id DC78D3A6E83; Mon, 17 Mar 2008 16:57:58 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: internet-drafts@ietf.org Cc: Paul_Vixie@isc.org, dagon@cc.gatech.edu, ipr@ietf.org From: IETF I-D Submission Tool Subject: Manual Post Requested for draft-vixie-dnsext-dns0x20 Message-Id: <20080317235758.DC78D3A6E83@core3.amsl.com> Date: Mon, 17 Mar 2008 16:57:58 -0700 (PDT) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mx.isc.org Manual Posting Requested for following Internet-Draft: I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=6050 Filename: draft-vixie-dnsext-dns0x20 Version: 00 Staging URL: http://www3.ietf.org/proceedings/staging/draft-vixie-dnsext-dns0x20-00.txt Title: Use of Bit 0x20 in DNS Labels to Improve Transaction Identity Creation_date: 2008-03-17 WG ID: Indvidual Submission Number_of_pages: 8 Abstract: The small (16-bit) size of the DNS transaction ID has made it a frequent target for forgery, with the unhappy result of many cache pollution vulnerabilities demonstrated throughout Internet history. Even with perfectly and unpredictably random transaction ID's, random and birthday attacks are still theoretically feasible. This document describes a method by which an initiator can improve transaction identity using the 0x20 bit in DNS labels. Submitter: Paul Vixie (vixie@isc.org) Author(s): Paul Vixie, vixie@isc.org David Dagon, dagon@cc.gatech.edu Intellectual Property, ipr@ietf.org. Comment: idnits says i have a 4748 problem. i copied the boilerplate word for word from 4748 and 3978, so and verified it by eye. i don't know what it thinks i am doing wrong. --=-=-=-- -- to unsubscribe send a message to namedroppers-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 Mar 17 19:34:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5B03A682B; Mon, 17 Mar 2008 19:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.812 X-Spam-Level: * X-Spam-Status: No, score=1.812 tagged_above=-999 required=5 tests=[AWL=4.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyRCcvJRpfWV; Mon, 17 Mar 2008 19:34:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B4363A6804; Mon, 17 Mar 2008 19:34:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbRUQ-00004n-3P for namedroppers-data@psg.com; Tue, 18 Mar 2008 02:23:46 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbRUN-00004P-LX for namedroppers@ops.ietf.org; Tue, 18 Mar 2008 02:23:44 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5D4A911436; Tue, 18 Mar 2008 02:23:43 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "W.C.A. Wijngaards" cc: Robert Elz , namedroppers@ops.ietf.org Subject: Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding In-Reply-To: Your message of "Wed, 12 Mar 2008 22:54:36 +0100." <47D8511C.7080006@nlnetlabs.nl> References: <11334.1205330770@sa.vix.com> <57450.1205256926@sa.vix.com> <20080311234603.GB4562@outpost.ds9a.nl> <6689.1205354604@epsilon.noi.kre.to> <29775.1205357343@sa.vix.com> <47D8511C.7080006@nlnetlabs.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 18 Mar 2008 02:23:43 +0000 Message-ID: <17059.1205807023@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I would be against no-question-pointers text. It is perfectly ok for a > (authority, cache) server to compress to the question section. The > server can determine if it wants to do so (and if that smashes case). > > If you feel the need for text: > Please note that the copied query name can differ in upper and lower > case, and therefore its use as a compression target depends on the > servers choices regarding compression. because this isn't relevant to the topic of dns-0x20, i left it completely out. -- to unsubscribe send a message to namedroppers-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 Mar 17 19:35:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045013A682B; Mon, 17 Mar 2008 19:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=3.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDZzpmUs0+XZ; Mon, 17 Mar 2008 19:35:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1325B3A6804; Mon, 17 Mar 2008 19:35:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbRT7-000Ptl-Hf for namedroppers-data@psg.com; Tue, 18 Mar 2008 02:22:25 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbRT4-000Pt5-91 for namedroppers@ops.ietf.org; Tue, 18 Mar 2008 02:22:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7BA0511436; Tue, 18 Mar 2008 02:22:21 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org Subject: Re: DNS is mandatory text In-Reply-To: Your message of "Tue, 11 Mar 2008 23:31:54 -0400." <200803120332.m2C3WlBU084335@ogud.com> References: <200803120332.m2C3WlBU084335@ogud.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 18 Mar 2008 02:22:21 +0000 Message-ID: <16888.1205806941@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion as a result of controversy around mandatoriness, i left it out of -01, which according to the draftbot, was just now accepted into the system. -- to unsubscribe send a message to namedroppers-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 Mar 17 19:39:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423BC3A6932; Mon, 17 Mar 2008 19:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 7eDmU2WtMARB; Mon, 17 Mar 2008 19:39:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 575023A683A; Mon, 17 Mar 2008 19:39:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbRYL-0000Wv-Fo for namedroppers-data@psg.com; Tue, 18 Mar 2008 02:27:49 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbRYI-0000W9-Hw for namedroppers@ops.ietf.org; Tue, 18 Mar 2008 02:27:48 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 008A03A6EA7; Mon, 17 Mar 2008 19:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-dnsext-rfc2671bis-edns0-01.txt Message-Id: <20080318023002.008A03A6EA7@core3.amsl.com> Date: Mon, 17 Mar 2008 19:30:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Revised extension mechanisms for DNS (EDNS0) Author(s) : P. Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-01.txt Pages : 9 Date : 2008-03-17 The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.1 - Introduction A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2671bis-edns0-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-17192302.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 03:19:33 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2002028C333; Tue, 18 Mar 2008 03:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.979 X-Spam-Level: X-Spam-Status: No, score=-3.979 tagged_above=-999 required=5 tests=[AWL=2.516, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrmd8XP+fVQ8; Tue, 18 Mar 2008 03:19:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9603F3A6860; Tue, 18 Mar 2008 03:19:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbYkD-000Myw-GO for namedroppers-data@psg.com; Tue, 18 Mar 2008 10:08:33 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbYk9-000MyD-UQ for namedroppers@ops.ietf.org; Tue, 18 Mar 2008 10:08:32 +0000 X-IronPort-AV: E=Sophos;i="4.25,517,1199660400"; d="scan'208";a="3789958" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2008 11:08:23 +0100 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 m2IA8N9S023601 for ; Tue, 18 Mar 2008 11:08:23 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2IA8N1N027409 for ; Tue, 18 Mar 2008 10:08:23 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 11:08:23 +0100 Received: from Townsley-MacBook.local ([64.103.30.65]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 11:08:23 +0100 Message-ID: <47DF9495.7030505@cisco.com> Date: Tue, 18 Mar 2008 11:08:21 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IETF DNSEXT WG Subject: TCP "Road Map" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2008 10:08:23.0270 (UTC) FILETIME=[FFEA7860:01C888DF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5102; t=1205834903; x=1206698903; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20TCP=20=22Road=20Map=22 |Sender:=20; bh=uN97KiJbvUoV0lW8CkIfTzlbLx85GjnlqHxVBmczIqA=; b=hkstQoJpbChx8QN5lfB2wKda1J4hQ9/81tYPLPSnArkb7LtVbvczXtPOZ9 FKlTbtb1DazagnjiE3RVSD+Ulq1Y5pDQlnCSR4rWryMKRaOOJJYCI+xqq9xJ JnwbVDpkiU; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I'm forwarding this note on from Aaron Falk. It describes the Transport Area's attempt to bring sense to its own plethora of documents surrounding TCP. It may or may not be exactly what DNS needs, but it is probably a good idea to at least consider this precedent as food for thought right now. - Mark > Hi Mark- > > The TCP Roadmap (RFC4614) is intended to help folks, particularly > implementers, understand how the many related RFCs fit together. The > document introduction explains the scope and purpose well and, as it > doesn't require any knowledge of TCP, I'm appending it below. Note > that is an Informational Track RFC and doesn't update any standards -- > it is intended to be a helper-document. IMO, this is an excellent way > to make IETF documents more usable. > > --aaron > > 1. Introduction > > A correct and efficient implementation of the Transmission Control > Protocol (TCP) is a critical part of the software of most Internet > hosts. As TCP has evolved over the years, many distinct documents > have become part of the accepted standard for TCP. At the same > time, > a large number of more experimental modifications to TCP have also > been published in the RFC series, along with informational notes, > case studies, and other advice. > > As an introduction to newcomers and an attempt to organize the > plethora of information for old hands, this document contains a > "roadmap" to the TCP-related RFCs. It provides a brief summary of > the RFC documents that define TCP. This should provide guidance to > implementers on the relevance and significance of the standards- > track > extensions, informational notes, and best current practices that > relate to TCP. > > > > > > > Duke, et al. Informational [Page 2] > RFC 4614 TCP Roadmap September 2006 > > > This document is not an update of RFC 1122 and is not a rigorous > standard for what needs to be implemented in TCP. This document is > merely an informational roadmap that captures, organizes, and > summarizes most of the RFC documents that a TCP implementer, > experimenter, or student should be aware of. Particular comments or > broad categorizations that this document makes about individual > mechanisms and behaviors are not to be taken as definitive, nor > should the content of this document alone influence implementation > decisions. > > This roadmap includes a brief description of the contents of each > TCP-related RFC. In some cases, we simply supply the abstract or a > key summary sentence from the text as a terse description. In > addition, a letter code after an RFC number indicates its category > in > the RFC series (see BCP 9 [RFC2026] for explanation of these > categories): > > S - Standards Track (Proposed Standard, Draft Standard, or > Standard) > > E - Experimental > > B - Best Current Practice > > I - Informational > > Note that the category of an RFC does not necessarily reflect its > current relevance. For instance, RFC 2581 is nearly universally > deployed although it is only a Proposed Standard. Similarly, some > Informational RFCs contain significant technical proposals for > changing TCP. > > This roadmap is divided into four main sections. Section 2 lists > the > RFCs that describe absolutely required TCP behaviors for proper > functioning and interoperability. Further RFCs that describe > strongly encouraged, but non-essential, behaviors are listed in > Section 3. Experimental extensions that are not yet standard > practices, but that potentially could be in the future, are > described > in Section 4. > > The reader will probably notice that these three sections are > broadly > equivalent to MUST/SHOULD/MAY specifications (per RFC 2119), and > although the authors support this intuition, this document is merely > descriptive; it does not represent a binding standards-track > position. Individual implementers still need to examine the > standards documents themselves to evaluate specific requirement > levels. > > > > > Duke, et al. Informational [Page 3] > RFC 4614 TCP Roadmap September 2006 > > > A small number of older experimental extensions that have not been > widely implemented, deployed, and used are noted in Section 5. Many > other supporting documents that are relevant to the development, > implementation, and deployment of TCP are described in Section 6. > Within each section, RFCs are listed in the chronological order of > their publication dates. > > A small number of fairly ubiquitous important implementation > practices that are not currently documented in the RFC series are > listed in Section 7. > > > -- to unsubscribe send a message to namedroppers-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 Mar 18 18:24:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6BD3A6783; Tue, 18 Mar 2008 18:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=3.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-DJZVGD5aEO; Tue, 18 Mar 2008 18:24:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C077E3A6C29; Tue, 18 Mar 2008 18:23:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jbmny-000FVz-5C for namedroppers-data@psg.com; Wed, 19 Mar 2008 01:09:22 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jbmnv-000FVB-S4 for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 01:09:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 67BB011425 for ; Wed, 19 Mar 2008 01:09:12 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: thinking about authority and additional sections in recursive answers X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Mar 2008 01:09:12 +0000 Message-ID: <65520.1205888952@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion when a recursive server answers an RD=1 question positively, is there any way that the authority section can be useful to the requestor? since it's RD=1 we more or less think that the requestor is not going to do any iteration. since this adds octets and costs cycles, and since a lot of us have ways to disable it and have not heard any complaints from disabling it... could we perhaps clarify the DNS specification to make this stuff "completely unnecessary" ? -- to unsubscribe send a message to namedroppers-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 Mar 18 18:57:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7E03A680A; Tue, 18 Mar 2008 18:57: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 qV9f9SDcSt0q; Tue, 18 Mar 2008 18:57:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 022383A6857; Tue, 18 Mar 2008 18:57:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbnS3-000M37-Jz for namedroppers-data@psg.com; Wed, 19 Mar 2008 01:50:47 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbnS0-000LxC-99 for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 01:50:46 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m2J1oUwR058068; Wed, 19 Mar 2008 12:50:30 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803190150.m2J1oUwR058068@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: thinking about authority and additional sections in recursive answers In-reply-to: Your message of "Wed, 19 Mar 2008 01:09:12 -0000." <65520.1205888952@sa.vix.com> Date: Wed, 19 Mar 2008 12:50:30 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > when a recursive server answers an RD=1 question positively, is there any way > that the authority section can be useful to the requestor? Yes. It's used to short circuit the process to find the zone that contains a name. This is useful for UPDATE. The alternalte is to keep performing SOA queries and chopping off a label a time until you get a result. > since it's RD=1 we > more or less think that the requestor is not going to do any iteration. sinc > e > this adds octets and costs cycles, and since a lot of us have ways to disable > it and have not heard any complaints from disabling it... could we perhaps > clarify the DNS specification to make this stuff "completely unnecessary" ? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@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 Mar 19 02:13:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB1D28C1CE; Wed, 19 Mar 2008 02:13:18 -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 O97QQsnGx21d; Wed, 19 Mar 2008 02:13:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CF0D28C0D6; Wed, 19 Mar 2008 02:13:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbuBw-000K2f-3D for namedroppers-data@psg.com; Wed, 19 Mar 2008 09:02:36 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbuBs-000K23-LF for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 09:02:34 +0000 X-IronPort-AV: E=Sophos;i="4.25,523,1199660400"; d="scan'208";a="3904108" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2008 10:02:18 +0100 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 m2J92Bpl031775; Wed, 19 Mar 2008 10:02:11 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2J92Bgs028684; Wed, 19 Mar 2008 09:02:11 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:02:11 +0100 Received: from [192.165.72.13] ([10.61.97.146]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:02:11 +0100 Cc: namedroppers@ops.ietf.org Message-Id: <31DA99D2-7064-49AC-9BFB-49E9B0E7B641@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= In-Reply-To: <200803171524.m2HFOXlf064303@ogud.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 v919.2) Subject: Re: Forgery Resilience consensus call: Qname case sensitivity Date: Wed, 19 Mar 2008 10:02:10 +0100 References: <200803171524.m2HFOXlf064303@ogud.com> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 19 Mar 2008 09:02:11.0054 (UTC) FILETIME=[EAB428E0:01C8899F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=394; t=1205917331; x=1206781331; 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=20Forgery=20Resilience=20consensus=20call =3A=20Qname=20case=20sensitivity |Sender:=20; bh=AhEpx1+hDzdrJ/sV3dwTBjS2v5VhPidLZ6qx20rPao4=; b=vXQpHe1M4Cz0UvmvpYTSEm2LUdRTD9jMLsnGhuYg2vSANmoynblkQXjX6z iZKeCkJFo6q4pvvsYKoJ7Geu6jQCttahPbAhrl53MMz+qOkdKBW2UOs6d/jL gHWTU0/hK8; 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: DNSEXT discussion On 17 mar 2008, at 16.23, =D3lafur Gu=F0mundsson /DNSEXT chair wrote: > Does this mean that: > A. name issued in query matches exactly to name in Query =20 > section of answer > B. the names match after case folding Note that B should be "the names match after case folding in ASCII =20 when octet values are within the range 0x41-0x7A" or something similar. Patrik -- to unsubscribe send a message to namedroppers-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 Mar 19 05:22:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BF73A699F; Wed, 19 Mar 2008 05:22:10 -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 tQEK4KPUvpnA; Wed, 19 Mar 2008 05:22:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EA503A6C5E; Wed, 19 Mar 2008 05:22:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbxA7-000O2d-Ri for namedroppers-data@psg.com; Wed, 19 Mar 2008 12:12:55 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbxA4-000O1c-Q7 for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 12:12:54 +0000 Received: from [195.169.217.177] (vhe-420101.sshn.net [195.169.217.177]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2JCClTp092495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Mar 2008 13:12:47 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <47E11F5E.7090709@nlnetlabs.nl> Date: Wed, 19 Mar 2008 15:12:46 +0100 From: Matthijs Mekking User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: review of draft-gudmundsson-life-of-dnskey-00.txt X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 19 Mar 2008 13:12:47 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I read this draft and have some comments: "To large extent this discussion is motivated by Trust anchor keys but the same terminology can be used for zone signing keys." I always interpreted that DNSKEY records (KSK and ZSK) could always be used as trust-anchors. Anyway, in RFC 4033 and 4986 they make no distinction in the trust anchor definition, so why make the distinction here? Retired: "When the key is no longer used for signing the zone it enters state Retired." Maybe you can elaborate on when a key is no longer used. I think it is when the key became 'the old key' during a rollover. Are there any other cases? Am I right if I say: "An expired key is always a retired key, but a retired key does not have to be expired."? Lame TAs: "A Trust Anchor is arguably Lame if there are no signatures by a Retired KSK in the zone." TA is lame if the parent continues to publish DS pointing to the key, after it has been removed from the DNSKEY RRset. Does it make difference if there are signatures in the zone or not? Regards, Matthijs Mekking matthijs@nlnetlabs.nl NLnet Labs Foundation -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4R9eIXqNzxRs6egRAt6GAJ46vbkxE0Qpo4YJr8t/NZ1hD0bVTgCdEbfw Nh8QmLJkmK76IUE4ww/7uTQ= =EyXu -----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 Mar 19 06:27:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E5228C493; Wed, 19 Mar 2008 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.353 X-Spam-Level: X-Spam-Status: No, score=0.353 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrevB6rQXxKG; Wed, 19 Mar 2008 06:27:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A60528C4A4; Wed, 19 Mar 2008 06:27:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbyBb-000A77-C4 for namedroppers-data@psg.com; Wed, 19 Mar 2008 13:18:31 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JbyBQ-000A5d-BC for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 13:18:26 +0000 Received: from [192.168.1.100] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2JDIC5j088011; Wed, 19 Mar 2008 09:18:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <65520.1205888952@sa.vix.com> References: <65520.1205888952@sa.vix.com> Date: Wed, 19 Mar 2008 09:18:04 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: thinking about authority and additional sections in recursive answers Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 1:09 +0000 3/19/08, Paul Vixie wrote: >when a recursive server answers an RD=1 question positively, is there any way >that the authority section can be useful to the requestor? since it's RD=1 we >more or less think that the requestor is not going to do any iteration. since >this adds octets and costs cycles, and since a lot of us have ways to disable >it and have not heard any complaints from disabling it... could we perhaps >clarify the DNS specification to make this stuff "completely unnecessary" ? I'd vote for "possibly of some use in certain situations." In DNSSEC (as if) it would be useful (in case the requestor is prepared to do the validation). Probably helpful for CNAME/DNAME/Wildcard answers too. And in cases where the requestor is someone using dig and forgetting "+norec". (I may be wrong, I haven't thought through these cases thoroughly. It's too early in the morning for me to think deep thoughts.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 19 10:00:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E27728C379; Wed, 19 Mar 2008 10:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.158 X-Spam-Level: X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[AWL=2.757, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75ydA9lRb4d7; Wed, 19 Mar 2008 10:00:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29C9B28C693; Wed, 19 Mar 2008 09:59:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jc1SP-000NWG-DF for namedroppers-data@psg.com; Wed, 19 Mar 2008 16:48:05 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jc1S6-000NLg-Ta for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 16:47:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4220411459; Wed, 19 Mar 2008 16:47:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: thinking about authority and additional sections in recursive answers In-Reply-To: Your message of "Wed, 19 Mar 2008 09:18:04 -0400." References: <65520.1205888952@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Mar 2008 16:47:37 +0000 Message-ID: <97934.1205945257@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I'd vote for "possibly of some use in certain situations." me too, but, there's no reliable way to know in the responder if a requestor is in one of those situations. > In DNSSEC (as if) it would be useful (in case the requestor is prepared to > do the validation). doesn't DNSSEC have its own bit for that kind of thing? i'll agree that if DNSSEC metadata is desireable, then, a full authority section is also likely quite desireable. > Probably helpful for CNAME/DNAME/Wildcard answers too. i would like to hear an example of this. remember, RD=1 so you're talking to a stub resolver. what are they could do with your NS RRs in the auth section? > And in cases where the requestor is someone using dig and forgetting > "+norec". this is a statistical anomaly compared to the cpu cycles and network bandwidth used up by all these authority sections. if the standard were that RD=1 meant no authority sections, then "dig" users would quickly remember to say +norec. > (I may be wrong, I haven't thought through these cases thoroughly. It's too > early in the morning for me to think deep thoughts.) well, thanks for sharing, anyway. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 19 10:49:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554723A6D11; Wed, 19 Mar 2008 10:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.071 X-Spam-Level: X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoYq5LoQ9I1O; Wed, 19 Mar 2008 10:49:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 472DD3A6F77; Wed, 19 Mar 2008 10:48:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jc2H3-0006sc-1K for namedroppers-data@psg.com; Wed, 19 Mar 2008 17:40:25 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jc2Gz-0006s1-BW for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 17:40:22 +0000 Received: from [0.0.0.0] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2JHds7d091694; Wed, 19 Mar 2008 13:40:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 19 Mar 2008 13:39:50 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: the birth of DNSSEC Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I discovered I do have a copy of the old DNSSEC WG archives on my laptop (someone asked). For grins and giggles, here is the oldest message I have (perhaps the first on the list, but I am not sure): (Note: DNSSEC does not appear in this message. The first mention of DNSSEC is in a message dated Feb 23, 1994.) Received: from tis.com by magellan.TIS.COM id aa08723; 28 Oct 93 10:44 EDT Received: from magellan.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA29195; Thu, 28 Oct 93 10:44:51 EDT Received: from [127.0.0.1] by magellan.TIS.COM id aa08710; 28 Oct 93 10:44 EDT Reply-To: James M Galvin To: dns-security@tis.com Subject: DNS Security Sub-Working Group Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 28 Oct 1993 10:44:33 -0400 From: James M Galvin Message-Id: <9310281044.aa08710@magellan.TIS.COM> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" The DNS Security Sub-Working Group will meet at the Houston IETF. The exact placement within the DNS meeting has not been determined, yet. Unfortunately, it took somewhat longer than desirable for Rob and I to get together on when the meeting should be. Rob prefers that the sub-group meet prior to the DNS working group meeting so we can bring "results" for discussion rather than having an open meeting. The problem is that it is really late to be scheduling a meeting time. So, I'm going to try to organize a meeting time for the security subgroup. If you would like to attend, please send me a note saying so and tell me when you are available. I will find a time that is convenient for the most people and post an announcement, on the message board at the IETF. Sorry, but that is the best I can do at this time. On to the real work.... What I've done is to go through all of the mail I've seen on DNS security from the following places: namedroppers, ipsec, dns-security, and firewalls. From the mail I've identified the issues and have summarized them below. I would like to point out that one thing we have not done yet is to identify the threats against which we are providing protection, and then to document them. For the meeting agenda I would like to propose the following: o identification of threats (and justifying rationale) in preparation for a document o review of issues - do we understand the issues documented - is this the right set of issues o development of plan and schedule for deliverables, not to exceed two more IETF meetings I have cc'ed the namedroppers list on this message for information only. Please keep the discussion on the dns-security@tis.com mailing list. If you are not on the list and wish to join please send a message to dns-security-request@tis.com. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Resolved Issues For DNS Security 1. The DNS application should support security services itself, i.e., it can not depend on the security services of another layer, for example, IP. In support of this position is the point made first by Steve Bellovin. Network-level security provides identification and authentication, but not authorization. The DNS requires authorization. Christian Huitema also noted that the source of the DNS data is not the DNS, per se, but some administrator. Thus, the data needs to be signed by this administrator, not the DNS. Unresolved Issues for DNS Security 1. On the firewalls mailing list, there was a fair amount of discussion of the use of the DNS in firewalled environments. I would like to suggest that this group take as an action item to produce an informational document that addresses this issue. 2. Insofar as PEM is a technology that provides key management services, the DNS could make use of it to distribute certificates. However, it has also been suggested that the DNS could distribute its own certificates by specifying a new resource record. The following subissues are relevant to this discussion. a. If the DNS is "secure", could we store/distribute just keys in/with it, or do we need certificates? b. If we store certificates, and even large keys, their distribution or inclusion in DNS replies may exceed the maximum size allowed. Two suggestions have been made. First, we could propose a parallen DNS-like server that does not have the limitation. Second, we could specify MX-like records that point to "key" manager services. c. Could SNMP be used to distribute the key/certificates? 3. In order for key management to be effective, the key must be "bound" to an object that identifies it. For example, in PEM the public keys are embodied in a certificate that binds the distinguished name of owner of the public key to the key. In the case of DNS, the question is should the key be bound to the address (or other data) record, the domain name, or both? ------- =_aaaaaaaaaa0-- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 19 11:22:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10103A68AA; Wed, 19 Mar 2008 11:22:14 -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 XOCqrnKDtJ0P; Wed, 19 Mar 2008 11:22:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E47893A67A3; Wed, 19 Mar 2008 11:22:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jc2na-000E4E-AJ for namedroppers-data@psg.com; Wed, 19 Mar 2008 18:14:02 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jc2nX-000E3o-62 for namedroppers@ops.ietf.org; Wed, 19 Mar 2008 18:14:00 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 69E5DC2DAF; Wed, 19 Mar 2008 18:13:57 +0000 (GMT) Date: Wed, 19 Mar 2008 18:13:55 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , namedroppers@ops.ietf.org cc: ed.lewis@neustar.biz, Alex Bligh Subject: Re: the birth of DNSSEC Message-ID: <5B8160CD92F0B9703330B1BA@Ximines.local> In-Reply-To: References: 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: DNSEXT discussion --On 19 March 2008 13:39:50 -0400 Edward Lewis wrote: > c. Could SNMP be used to distribute the key/certificates? I think this is a fine plan. Alex -- to unsubscribe send a message to namedroppers-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 Mar 20 13:19:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7113028C3D8; Thu, 20 Mar 2008 13:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.345 X-Spam-Level: X-Spam-Status: No, score=-108.345 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ORPoueDJXUQk; Thu, 20 Mar 2008 13:19:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A96E28C42F; Thu, 20 Mar 2008 13:19:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JcQxV-000G6G-NB for namedroppers-data@psg.com; Thu, 20 Mar 2008 20:01:53 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JcQxR-000G5O-2X for namedroppers@ops.ietf.org; Thu, 20 Mar 2008 20:01:52 +0000 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 20 Mar 2008 13:02:13 -0700 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) with Microsoft SMTP Server id 8.1.240.5; Thu, 20 Mar 2008 13:01:48 -0700 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Thu, 20 Mar 2008 13:01:07 -0700 From: Yue Luo To: "namedroppers@ops.ietf.org" Date: Thu, 20 Mar 2008 13:00:41 -0700 Subject: Is there already an implementation of RSA-SHA2 for DNSSEC? Thread-Topic: Is there already an implementation of RSA-SHA2 for DNSSEC? Thread-Index: AciKxRNg8i9RaPNKREKN/HLCvX5qsQ== Message-ID: <7F2791CD3A148642AF9069A0336EDE853792624AAA@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2791CD3A148642AF9069A0336EDE853792624AAANAEXMSGW602wi_" MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --_000_7F2791CD3A148642AF9069A0336EDE853792624AAANAEXMSGW602wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am wondering if anyone knows a DNS server that has already implemented RS= A-SHA2 as specified in draft-ietf-dnsext-dnssec-rsasha256-03. Thank you. Yue --_000_7F2791CD3A148642AF9069A0336EDE853792624AAANAEXMSGW602wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am wondering if anyone knows a DNS server that has a= lready implemented RSA-SHA2 as specified in draft-ietf-dnsext-dnssec-rsasha256-03.=

 

Thank you.

Yue

--_000_7F2791CD3A148642AF9069A0336EDE853792624AAANAEXMSGW602wi_-- -- to unsubscribe send a message to namedroppers-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 Mar 20 16:27:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD6328C5FF; Thu, 20 Mar 2008 16:27:14 -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 KNLkg+T23Se7; Thu, 20 Mar 2008 16:27:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64C4B3A6FA0; Thu, 20 Mar 2008 16:27:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JcU09-0002WU-B3 for namedroppers-data@psg.com; Thu, 20 Mar 2008 23:16:49 +0000 Received: from [2001:7b8:206:1:7200:ff:fe00:28e3] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JcU06-0002WA-9l for namedroppers@ops.ietf.org; Thu, 20 Mar 2008 23:16:47 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id A52A7131DC3; Fri, 21 Mar 2008 00:14:37 +0100 (CET) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 6A50DCF9B3; Fri, 21 Mar 2008 00:14:17 +0100 (CET) Message-ID: <47E2EFC9.3030805@NLnetLabs.nl> Date: Fri, 21 Mar 2008 00:14:17 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Yue Luo Cc: "namedroppers@ops.ietf.org" Subject: Re: Is there already an implementation of RSA-SHA2 for DNSSEC? References: <7F2791CD3A148642AF9069A0336EDE853792624AAA@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <7F2791CD3A148642AF9069A0336EDE853792624AAA@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yue Luo wrote: > I am wondering if anyone knows a DNS server that has already implemented RSA-SHA2 as specified in draft-ietf-dnsext-dnssec-rsasha256-03. > Actually, servers themselves shouldn't need any special modifications to support the SHA-2 algorithms, as long as they don't do any weird in-depth processing of RDATA fields (like, check for known algorithms). What one does need to play with SHA2 keys and signatures is a zone signer that implements it. I have added preliminary support for it in the current trunk of ldns (which manifests itself in ldns-keygen, ldns-signzone and drill), as long as it's compiled with a version of OpenSSL that supports the SHA2 family of functions. Contact me off-list if you want a pointer to the trunk version, or if you have problems with or suggestions about it. The usual disclaimer about unreleased development code is applicable. Of course, since there are no assigned algorithm identifiers from IANA yet, we had to make them up. These are highly likely to change, if not only because the separate NSEC3 numbers will be removed from -04 (when text will be added to the lines of 'if you understand SHA2, you understand NSEC3', which will remove the need to use separate algorithm identifiers). Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4u/J4nZCKsdOncURAiEmAJ9mEAnzjiZlrVH5/QEMKs0VkG77+wCgyt6e IkDoYp+rHe0zJ6NGIqPo2Os= =1bMj -----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 Mar 24 06:25:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87343A694F; Mon, 24 Mar 2008 06:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 1kgw3NVhV0iS; Mon, 24 Mar 2008 06:25:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EBC428C29E; Mon, 24 Mar 2008 06:25:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdmU8-0007ZY-CZ for namedroppers-data@psg.com; Mon, 24 Mar 2008 13:13:08 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdmU5-0007Yh-8h for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 13:13:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id E1CA528C2F8; Mon, 24 Mar 2008 06:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-03.txt Message-Id: <20080324131502.E1CA528C2F8@core3.amsl.com> Date: Mon, 24 Mar 2008 06:15:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Measures for making DNS more resilient against forged answers Author(s) : B. Hubert, R. van Mook Filename : draft-ietf-dnsext-forgery-resilience-03.txt Pages : 22 Date : 2008-03-24 The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus answers quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect answers. This document updates RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-24061348.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 06:27:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B2A3A6DFC; Mon, 24 Mar 2008 06:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njc0jrvuBQGC; Mon, 24 Mar 2008 06:27:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BA323A6A93; Mon, 24 Mar 2008 06:27:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdmYx-0008VH-Aa for namedroppers-data@psg.com; Mon, 24 Mar 2008 13:18:07 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdmYW-0008No-0K for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 13:17:48 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1JdmYQ-0000o0-1V for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 14:17:34 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6234240F9; Mon, 24 Mar 2008 14:17:40 +0100 (CET) Date: Mon, 24 Mar 2008 14:17:40 +0100 From: bert hubert To: namedroppers@ops.ietf.org Subject: diff between -02 and -03 of forgery-resilience Message-ID: <20080324131740.GB14818@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Hi everybody, Now that it has been agreed that 0x20 and forgery-resilience should not be conjoined, it is a good time for -03 which I hope can go for last call quickly. I've worked in most concerns raised, with some slight exceptions to retain a brief document. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-03.txt Differences: Full view: http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset?new=trunk%2Fdraft-ietf-dnsext-forgery-resilience.xml%4020&old=trunk%2Fdraft-ietf-dnsext-forgery-resilience.xml%4013 Summary: * Waive port churn and other rules in case cryptographic verification is in place that guarantees answer validity. This makes sure these measures for the interim period do not place a burden on future security-aware resolvers. The above is new, and based on concerns by Wouter Wijngaards that DNSSEC security-aware resolvers have no benefit of the rules contained in the draft, yet would need to implement them. The rest of changes are more clerical: * Add reference to RFC 4086 (random number generation) * Improve wording on 'random' - only specify that implementations should strive towards unpredictability, we can't demand it (without a revolution in the state of mathematics!) * Improve 'arbitrary' vs 'random' wording * Improve 'identical' vs 'equivalent' wording (case folding comparisons) * Make case-folding explicit in a number of places * Tone down wording on existing practices * Make sure document does not confuse current practice with normative rules ('use the first correct answer' versus 'generally the first correct answer is used') * 'Matching the question' chapter renamed to 'Forcing the question' (chapter title was completely wrong) * Clarify birthday paradox a bit, fix error (22 -> 23) * Clarify that as large a port range as *practicable* should possibly be used (iow, do not mandate taking down the whole server) Kind regards, Bert Hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 09:18:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E40B28C39C; Mon, 24 Mar 2008 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[AWL=2.451, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtDp6a9fsYkL; Mon, 24 Mar 2008 09:18:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E45328C395; Mon, 24 Mar 2008 09:18:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdpCk-000FkD-5P for namedroppers-data@psg.com; Mon, 24 Mar 2008 16:07:22 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdpCb-000Fj0-1K for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 16:07:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8F38011433; Mon, 24 Mar 2008 16:07:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience In-Reply-To: Your message of "Mon, 24 Mar 2008 14:17:40 +0100." <20080324131740.GB14818@outpost.ds9a.nl> References: <20080324131740.GB14818@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 Mar 2008 16:07:07 +0000 Message-ID: <48075.1206374827@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > The rest of changes are more clerical: > ... > * Improve 'identical' vs 'equivalent' wording (case folding comparisons) > * Make case-folding explicit in a number of places i now think this wording overspecifies (in section 9, countermeasures) o Question name (compared case-insensitively) i'd rather leave the ambiguous wording in RFC 1034 in maximal effect while we puzzle our way through the dns-0x20 issues. in the above wording, any initiator who compares case-sensitively is noncompliant, whereas under the existing RFC 1034 rules, compliance level of such behaviour is unspecified. (and in addition, the change is substantive, nowhere close to "clerical".) similarly, in 4.2 (matching the question section), where the text now says: DNS packets, both queries and answers, contain a question section. Incoming answers should be verified to have a question section that is equivalent to that of the outgoing query. i would rather this remain ambiguous, changing "equivilent" to "the same as". (because sameness can mean identity of equivilence, and i'd like initiators who demand identity here to remain compliant.) in section 10 (security considerations) we see this text: The above notwithstanding, it should be noted that using a low Time To Live for DNS records raises the chances of an attacker spoofing a resolver. i think this should be amended by adding the following after "resolver": by using the attacks described in this document. i'd also like to see the following new paragraph added to section 10: All of the spoofing attacks described in this document are due to the nearly universal lack of IP source address validation (see [BCP38] and [SAC004] for more information). If the source address of a UDP datagram were trustworthy, then there would be no need for forgery resilience in DNS initiators. and then in the references section, add something pointing to these two: http://tools.ietf.org/html/bcp38 http://www.icann.org/committees/security/sac004.txt thanks for your continued work on forgery-resilience. -- to unsubscribe send a message to namedroppers-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 Mar 24 10:13:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C0B3A6D72; Mon, 24 Mar 2008 10:13:25 -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 NQjri6J+Iw5U; Mon, 24 Mar 2008 10:13:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 185543A6D24; Mon, 24 Mar 2008 10:13:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdq5A-000284-Bb for namedroppers-data@psg.com; Mon, 24 Mar 2008 17:03:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdq53-00026m-2s for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 17:03:34 +0000 Received: from [10.31.68.68] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2OH3L4H082535; Mon, 24 Mar 2008 13:03:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <48075.1206374827@sa.vix.com> References: <20080324131740.GB14818@outpost.ds9a.nl> <48075.1206374827@sa.vix.com> Date: Mon, 24 Mar 2008 13:03:19 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: diff between -02 and -03 of forgery-resilience Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 16:07 +0000 3/24/08, Paul Vixie wrote: > All of the spoofing attacks described in this document are due to the > nearly universal lack of IP source address validation (see [BCP38] and > [SAC004] for more information). If the source address of a UDP datagram > were trustworthy, then there would be no need for forgery resilience in > DNS initiators. I still need to read -03, but I wanted to add to Paul's comment... Not "All of the spoofing attacks" fit this. If the spoof is sourced on the same LAN (or "LAN") as the victim or the true server then BCP38 won't matter. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 24 10:46:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6EE3A6D4F; Mon, 24 Mar 2008 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.42 X-Spam-Level: X-Spam-Status: No, score=-108.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 mNd8BAlKExnp; Mon, 24 Mar 2008 10:46:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C4A63A6D24; Mon, 24 Mar 2008 10:46:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdqbE-0008bX-9b for namedroppers-data@psg.com; Mon, 24 Mar 2008 17:36:44 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdqb7-0008Zq-0P for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 17:36:38 +0000 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 24 Mar 2008 10:37:08 -0700 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.240.5; Mon, 24 Mar 2008 10:36:36 -0700 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Mon, 24 Mar 2008 10:37:06 -0700 From: Yue Luo To: bert hubert , "namedroppers@ops.ietf.org" Date: Mon, 24 Mar 2008 10:36:33 -0700 Subject: RE: diff between -02 and -03 of forgery-resilience Thread-Topic: diff between -02 and -03 of forgery-resilience Thread-Index: AciNsdkG/H18bOZPSCWtOSxS7f6GMwAIff+A Message-ID: <7F2791CD3A148642AF9069A0336EDE853792625419@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> References: <20080324131740.GB14818@outpost.ds9a.nl> In-Reply-To: <20080324131740.GB14818@outpost.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion The draft discusses about the effect of TTL on the vulnerability. This ass= umes that a record in the cache is not overwritten before its expiration. = This assumption needs more discussion. An attacker can design ways to "pig= gy back" records in spoofed responses order to overwrite important cache en= tries. For example, to attack c.isi.edu, the attacker can use packet simil= ar to that in section 6.2.7 of RFC 1034. The draft should 1) make it explicit that the discussion relies on the assumption that cache= d records are not overwritten 2) discuss under what condition a cached record may be overwritten 3) provide guideline to reader to prevent critical cache records from being= written. Thank you. Yue -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of bert hubert Sent: Monday, March 24, 2008 6:18 AM To: namedroppers@ops.ietf.org Subject: diff between -02 and -03 of forgery-resilience Hi everybody, Now that it has been agreed that 0x20 and forgery-resilience should not be conjoined, it is a good time for -03 which I hope can go for last call quickly. I've worked in most concerns raised, with some slight exceptions to retain = a brief document. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-03= .txt Differences: Full view: http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset?new=3Dtrunk%2F= draft-ietf-dnsext-forgery-resilience.xml%4020&old=3Dtrunk%2Fdraft-ietf-dnse= xt-forgery-resilience.xml%4013 Summary: * Waive port churn and other rules in case cryptographic verification is in place that guarantees answer validity. This makes sure these measures for the interim period do not place a burden on future security-aware resolvers. The above is new, and based on concerns by Wouter Wijngaards that DNSSEC security-aware resolvers have no benefit of the rules contained in the draft, yet would need to implement them. The rest of changes are more clerical: * Add reference to RFC 4086 (random number generation) * Improve wording on 'random' - only specify that implementations should strive towards unpredictability, we can't demand it (without a revolution in the state of mathematics!) * Improve 'arbitrary' vs 'random' wording * Improve 'identical' vs 'equivalent' wording (case folding comparisons) * Make case-folding explicit in a number of places * Tone down wording on existing practices * Make sure document does not confuse current practice with normative rules ('use the first correct answer' versus 'generally the first correct answe= r is used') * 'Matching the question' chapter renamed to 'Forcing the question' (chapte= r title was completely wrong) * Clarify birthday paradox a bit, fix error (22 -> 23) * Clarify that as large a port range as *practicable* should possibly be used (iow, do not mandate taking down the whole server) Kind regards, Bert Hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Mar 24 10:47:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0CA3A6D4F; Mon, 24 Mar 2008 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=2.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz4J+RFhkeww; Mon, 24 Mar 2008 10:47:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03AE43A67F2; Mon, 24 Mar 2008 10:47:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdqai-0008UJ-VQ for namedroppers-data@psg.com; Mon, 24 Mar 2008 17:36:12 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdqab-0008Pj-UF for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 17:36:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 66C9211432; Mon, 24 Mar 2008 17:36:05 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience In-Reply-To: Your message of "Mon, 24 Mar 2008 13:03:19 -0400." References: <20080324131740.GB14818@outpost.ds9a.nl> <48075.1206374827@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 Mar 2008 17:36:05 +0000 Message-ID: <53369.1206380165@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I still need to read -03, but I wanted to add to Paul's comment... > > Not "All of the spoofing attacks" fit this. If the spoof is sourced on the > same LAN (or "LAN") as the victim or the true server then BCP38 won't > matter. fair enough. spoofing responses from a server on the same lan is not a case i had considered, but i suppose that there are configurations where a recursive and authoritative server are on the same lan. my wording is inadequate there. -- to unsubscribe send a message to namedroppers-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 Mar 24 14:36:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A9A3A6DC0; Mon, 24 Mar 2008 14:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evJE6cz2y2wW; Mon, 24 Mar 2008 14:36:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68B0528C39D; Mon, 24 Mar 2008 14:36:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JduAh-0003pR-9o for namedroppers-data@psg.com; Mon, 24 Mar 2008 21:25:35 +0000 Received: from [209.85.132.250] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JduAd-0003oi-Ek for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 21:25:33 +0000 Received: by an-out-0708.google.com with SMTP id c10so817883ana.18 for ; Mon, 24 Mar 2008 14:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=5gmFypITWw2o4Ry95Lx1MgAEliIELx0ZB/fWQg1icPY=; b=XEyQW1diONIv/MwwDrBrn8SC/3SlaNFJdOkmiS1kv0nHqwmEZjcGCDPBRT2km0siIGgmG8bOjwJDilfnb9Epo7f4643WwJqzsF9iN5tZzrYbUQIKgd+GuG05Siu+Cdm17ihGcpRwEaPwjXxudV/xd0SZmRlfpCvZSeMVUHNPtO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=B2eIusVZ1qL9jn/UJ8FwjiAYYEvucXN1eSAL4JhlS41bsf7Srp43CuB/BsRrWb7UoFkv08khRDI/g1XfYwWjFXrS9D0Ef7C/hYj/YF7K/sJXiuQI6cmC7LWrWYcdo7kBWrvGfSP77p+K0D+Avu9St6NOZdAAbEY9QvzJZd1pdSo= Received: by 10.100.34.16 with SMTP id h16mr19465237anh.80.1206393928298; Mon, 24 Mar 2008 14:25:28 -0700 (PDT) Received: from ika.home ( [70.240.199.89]) by mx.google.com with ESMTPS id p27sm687999ele.6.2008.03.24.14.25.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Mar 2008 14:25:24 -0700 (PDT) Message-ID: <47E81C39.7010705@gmail.com> Date: Mon, 24 Mar 2008 16:25:13 -0500 From: Brandon Black User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: OPT RR placement Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Hi, A question about edns0 and truncations and the placement of OPT RRs: My best understanding of where and how to truncate DNS responses to an EDNS0 query (based on the most recent relevant RFCs/drafts and the recent edns0 bis) is basically: If an RR being added to the Answers section would cause the packet to exceed the client's supported edns0 size, then you send a response with the TC bit set and no RRs (other than the copied question obviously). This is basically identical to how you would handle the same query for non-edns clients. If an RR being added to the Authority section would exceed the edns0 size, leave the Authority section empty and set the TC bit (but preserve the answers). In addition if the answer section alone was >512 (but within the edns0 size), then clear that out as well (empty response + TC again). Again this is basically how you would handle the same query for non-edns clients. What seems currently ambiguous to me is what do to about crossing the edns0 size barrier during Additional section processing. It seems the most reasonable behavior would depend largely on where the OPT RR is placed within the additional section. If your implementation puts the OPT RR first in the additional section, then a logical answer would be: If adding the OPT RR itself would cause the packet to exceed the client's supported edns0 size, then fall back to non-edns response, which again means that if one or both of the preceding sections were >512, setting TC and clearing them out as necessary. But if the OPT RR fits, then one could conceivably add additional RRs until the edns0 size limit is reached, and simply send "what fits" without a TC bit. But I don't see any recommendation for putting the OPT RR first, and BIND's behavior is the opposite on short packets (OPT RR last), although I didn't yet test how it would arrange things in this particular case. -- Brandon -- to unsubscribe send a message to namedroppers-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 Mar 24 16:14:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BAF3A6D1B; Mon, 24 Mar 2008 16:14:35 -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 eJ6hTVnDLKBX; Mon, 24 Mar 2008 16:14:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06EF73A6AF1; Mon, 24 Mar 2008 16:14:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdviO-000J9D-40 for namedroppers-data@psg.com; Mon, 24 Mar 2008 23:04:28 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdviK-000J8L-Pn for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 23:04:26 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2ON2lI9014333; Tue, 25 Mar 2008 06:02:50 +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 m2ON20BG025183; Tue, 25 Mar 2008 06:02:17 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience In-Reply-To: <48075.1206374827@sa.vix.com> References: <48075.1206374827@sa.vix.com> <20080324131740.GB14818@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 2008 06:02:00 +0700 Message-ID: <16172.1206399720@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Mon, 24 Mar 2008 16:07:07 +0000 From: Paul Vixie Message-ID: <48075.1206374827@sa.vix.com> | o Question name (compared case-insensitively) | | i'd rather leave the ambiguous wording in RFC 1034 in maximal effect while | we puzzle our way through the dns-0x20 issues. in the above wording, any | initiator who compares case-sensitively is noncompliant, whereas under the | existing RFC 1034 rules, compliance level of such behaviour is unspecified. I think you're attempting to create doubt about aspects of 1034 that really are clear - there's really no doubt that whenever names are compared, ascii case is ignored (the names are the same if all that differs is the case). Please don't try to pretend that 1034 isn't clear about that (I wish it wasn't, it would be nice to be completely rid of this, in the DNS, but it is, for now anyway). What isn't specified (of the things relevant here) is whether the server is required to repeat the exact same question bits in the response, or just a question that means the same thing. kre -- to unsubscribe send a message to namedroppers-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 Mar 24 16:54:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6F93A683B; Mon, 24 Mar 2008 16:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=2.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R36FSavDAVRT; Mon, 24 Mar 2008 16:54:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F02CE3A676A; Mon, 24 Mar 2008 16:54:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdwNq-000OFO-Uq for namedroppers-data@psg.com; Mon, 24 Mar 2008 23:47:18 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdwNn-000OEs-Sf for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 23:47:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 72A6111432; Mon, 24 Mar 2008 23:47:10 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Robert Elz cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience In-Reply-To: Your message of "Tue, 25 Mar 2008 06:02:00 +0700." <16172.1206399720@epsilon.noi.kre.to> References: <48075.1206374827@sa.vix.com> <20080324131740.GB14818@outpost.ds9a.nl> <16172.1206399720@epsilon.noi.kre.to> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 Mar 2008 23:47:10 +0000 Message-ID: <68246.1206402430@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I think you're attempting to create doubt about aspects of 1034 that really > are clear - there's really no doubt that whenever names are compared, ascii > case is ignored (the names are the same if all that differs is the case). perhaps you have no doubt. perhaps others have some. all i'm asking is, let us not try to clarify the point here, unless doing so improves forgery resilience, which in this case, it does not. let it remain doubtable by some. > Please don't try to pretend that 1034 isn't clear about that (I wish it > wasn't, it would be nice to be completely rid of this, in the DNS, but it > is, for now anyway). i'm not pretending so much as recounting. and, please don't tell me what i'm trying to do, i may not agree, and then we'll be off on that as a side-topic. > What isn't specified (of the things relevant here) is whether the server is > required to repeat the exact same question bits in the response, or just a > question that means the same thing. i believe i covered that by asking for "sameness" vs. "equivilence". -- to unsubscribe send a message to namedroppers-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 Mar 24 16:55:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF9A3A6876; Mon, 24 Mar 2008 16:55: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 xhQTi6IY6cqq; Mon, 24 Mar 2008 16:55:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D23863A683B; Mon, 24 Mar 2008 16:55:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdwOt-000OQd-13 for namedroppers-data@psg.com; Mon, 24 Mar 2008 23:48:23 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdwOq-000OQE-7l for namedroppers@ops.ietf.org; Mon, 24 Mar 2008 23:48:21 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m2ONmDxq057528; Tue, 25 Mar 2008 10:48:13 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803242348.m2ONmDxq057528@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: diff between -02 and -03 of forgery-resilience In-reply-to: Your message of "Mon, 24 Mar 2008 13:03:19 EDT." Date: Tue, 25 Mar 2008 10:48:13 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 16:07 +0000 3/24/08, Paul Vixie wrote: > > > All of the spoofing attacks described in this document are due to the > > nearly universal lack of IP source address validation (see [BCP38] and > > [SAC004] for more information). If the source address of a UDP datagram > > were trustworthy, then there would be no need for forgery resilience in > > DNS initiators. > > I still need to read -03, but I wanted to add to Paul's comment... > > Not "All of the spoofing attacks" fit this. If the spoof is sourced > on the same LAN (or "LAN") as the victim or the true server then > BCP38 won't matter. Today you can do BCP 38 at the LAN level for most (not all) LAN technologies. Even for those LAN technologies where you can't you are usually performing a attack on yourself as well as the victim. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 17:20:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA933A69CA; Mon, 24 Mar 2008 17:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tci8J32fDHu7; Mon, 24 Mar 2008 17:20:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19BD33A6C01; Mon, 24 Mar 2008 17:20:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdwkw-00025Y-RD for namedroppers-data@psg.com; Tue, 25 Mar 2008 00:11:10 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdwkt-00023m-GK for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 00:11:09 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m2P0B1XS057971; Tue, 25 Mar 2008 11:11:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803250011.m2P0B1XS057971@drugs.dv.isc.org> To: Brandon Black Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: OPT RR placement In-reply-to: Your message of "Mon, 24 Mar 2008 16:25:13 CDT." <47E81C39.7010705@gmail.com> Date: Tue, 25 Mar 2008 11:11:01 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > Hi, > > A question about edns0 and truncations and the placement of OPT RRs: My > best understanding of where and how to truncate DNS responses to an > EDNS0 query (based on the most recent relevant RFCs/drafts and the > recent edns0 bis) is basically: > > If an RR being added to the Answers section would cause the packet to > exceed the client's supported edns0 size, then you send a response with > the TC bit set and no RRs (other than the copied question obviously). > This is basically identical to how you would handle the same query for > non-edns clients. > > If an RR being added to the Authority section would exceed the edns0 > size, leave the Authority section empty and set the TC bit (but preserve > the answers). In addition if the answer section alone was >512 (but > within the edns0 size), then clear that out as well (empty response + TC > again). Again this is basically how you would handle the same query for > non-edns clients. > > What seems currently ambiguous to me is what do to about crossing the > edns0 size barrier during Additional section processing. It seems the > most reasonable behavior would depend largely on where the OPT RR is > placed within the additional section. If your implementation puts the > OPT RR first in the additional section, then a logical answer would be: > > If adding the OPT RR itself would cause the packet to exceed the > client's supported edns0 size, then fall back to non-edns response, > which again means that if one or both of the preceding sections were > >512, setting TC and clearing them out as necessary. > But if the OPT RR fits, then one could conceivably add additional RRs > until the edns0 size limit is reached, and simply send "what fits" > without a TC bit. > > But I don't see any recommendation for putting the OPT RR first, and > BIND's behavior is the opposite on short packets (OPT RR last), although > I didn't yet test how it would arrange things in this particular case. > > -- Brandon BIND reserves space for the OPT and TSIG/SIG records in the response. They always fit. OPT is logically part of the header. TSIG/SIG are authentication mechanisms. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 17:22:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDB53A6ED8; Mon, 24 Mar 2008 17:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 zsuJoWB+wAJx; Mon, 24 Mar 2008 17:22:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B9723A6ED2; Mon, 24 Mar 2008 17:22:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdwp4-0002cj-Gf for namedroppers-data@psg.com; Tue, 25 Mar 2008 00:15:26 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdwp2-0002bz-2N for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 00:15:25 +0000 Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdwp0-000369-3l; Tue, 25 Mar 2008 00:15:22 +0000 Cc: Edward Lewis , namedroppers@ops.ietf.org Message-Id: <23DBA4AB-01C8-4C28-ACCE-DB860A53BCB0@ca.afilias.info> From: Joe Abley To: Mark Andrews In-Reply-To: <200803242348.m2ONmDxq057528@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: diff between -02 and -03 of forgery-resilience Date: Mon, 24 Mar 2008 20:15:21 -0400 References: <200803242348.m2ONmDxq057528@drugs.dv.isc.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 24 Mar 2008, at 19:48 , Mark Andrews wrote: > Today you can do BCP 38 at the LAN level for most (not all) > LAN technologies. Even for those LAN technologies where > you can't you are usually performing a attack on yourself > as well as the victim. I find this quite impenetrable. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 17:42:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FF43A6D77; Mon, 24 Mar 2008 17:42:29 -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 EbD+2lbhskcS; Mon, 24 Mar 2008 17:42:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 937823A69D2; Mon, 24 Mar 2008 17:42:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdx7p-0005AO-JA for namedroppers-data@psg.com; Tue, 25 Mar 2008 00:34:49 +0000 Received: from [64.233.178.240] (helo=hs-out-0708.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jdx7n-00059o-3C for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 00:34:48 +0000 Received: by hs-out-0708.google.com with SMTP id z77so2923031hsz.9 for ; Mon, 24 Mar 2008 17:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=Kw44ieihFpJE+Ga4e35OA0OAW3Dye/a9pocMUfZMnpk=; b=U+5ilAW2+lEkILLskLQlm4kqRXzDF52IGfWUB6Ief+xGhA/564W24zFfmSd1Z56aHpL5CVG9PcJRa+GGfMurKY6mnm6JZBmO4C2pBBAf3PQX14rr/257sPMKSmuAhUn5E8xouzr9nLlF5u4ky5mNlz5RdrewTVFmOayLwU28dJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bBaeGy4XdP1x+QRDgP5qItCjJyk5Ee8VO8Qg2n1H65dnTpsf9AHIT0iTUdw8nRRhncOb4+k0dGbcNwfjseTOtIlsTtr8fDEka+kNwrGV1VfDoDi1vdCnB6W17o+NxB08hJ4Vw8ZGqZjwZIBGhU+GocWYe1DeY80G5ik1JCNA3OE= Received: by 10.100.255.17 with SMTP id c17mr19941533ani.37.1206405281016; Mon, 24 Mar 2008 17:34:41 -0700 (PDT) Received: from ika.home ( [70.240.199.89]) by mx.google.com with ESMTPS id i27sm15180413elf.14.2008.03.24.17.34.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Mar 2008 17:34:35 -0700 (PDT) Message-ID: <47E84884.7050407@gmail.com> Date: Mon, 24 Mar 2008 19:34:12 -0500 From: Brandon Black User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: OPT RR placement References: <200803250011.m2P0B1XS057971@drugs.dv.isc.org> In-Reply-To: <200803250011.m2P0B1XS057971@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Mark Andrews wrote: >> But I don't see any recommendation for putting the OPT RR first, and >> BIND's behavior is the opposite on short packets (OPT RR last), although >> I didn't yet test how it would arrange things in this particular case. >> > > BIND reserves space for the OPT and TSIG/SIG records in the > response. They always fit. OPT is logically part of the > header. TSIG/SIG are authentication mechanisms. > Hmmm yes I see that now, thank you. I've built up some test zones to explore how BIND (this particular install of 9.4.1 in any case) does these things to help me interpret what the standards are calling for (there are a few related to this). This has clarified some things but made other things less clear. Should TC be set if all of the Answers fit, but the auth RRs don't fit? Should partial RRsets be included in Answers if that's all that can be fit? My reading of this list and the RFCs (and some of the upcoming drafts) says that the answers to both questions should be no, but BIND 9.4.1 seems to say yes to the first question in all cases, and it seems to say yes to the second in response to a non-edns query (but no in response to an edns query). I should add that everything I'm talking about is relative to how an authoritative-only server should operate - caching isn't an issue for me (thankfully), and the BIND I'm looking at for behavioral reference is configured with: recursion no; additional-from-cache no; additional-from-auth yes; -- Brandon -- to unsubscribe send a message to namedroppers-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 Mar 24 21:23:33 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077293A69D2; Mon, 24 Mar 2008 21:23:33 -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 bk5vPeaRsvnk; Mon, 24 Mar 2008 21:23:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 377063A6888; Mon, 24 Mar 2008 21:23:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je0Sn-0008rE-VU for namedroppers-data@psg.com; Tue, 25 Mar 2008 04:08:41 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je0Sk-0008qo-Oz for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 04:08:40 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m2P44RWY020306; Tue, 25 Mar 2008 11:04:31 +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 m2P43isU001317; Tue, 25 Mar 2008 11:04:03 +0700 (ICT) From: Robert Elz To: Brandon Black cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: OPT RR placement In-Reply-To: <47E84884.7050407@gmail.com> References: <47E84884.7050407@gmail.com> <200803250011.m2P0B1XS057971@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 2008 11:03:44 +0700 Message-ID: <3227.1206417824@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Mon, 24 Mar 2008 19:34:12 -0500 From: Brandon Black Message-ID: <47E84884.7050407@gmail.com> | Should TC be set if all of the Answers fit, but the auth RRs don't fit? That depends upon the purpose of the auth RRs - there are times when they're required for the answer, in which case the answer to your question would be yes, but in general, no (provided that any RRset that is added in the auth section is complete - it can be complete, or omitted (if not essential), it can't be partial). | Should partial RRsets be included in Answers if that's all that can be fit? Not unless TC is set, ever - if TC is set, it doesn't matter what is in the answer, so it is generally best (more effecient) to send nothing, but that's an implementation choice. Having said all that, setting TC is never truly fatal, just adds lots of overhead and delays, so erring on the side of setting it more than necessary is the safe way. kre -- to unsubscribe send a message to namedroppers-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 Mar 25 01:27:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4B33A6B30; Tue, 25 Mar 2008 01:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=1.963, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkA9mcALKexZ; Tue, 25 Mar 2008 01:26:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 816C93A6A84; Tue, 25 Mar 2008 01:26:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je4It-000I98-Po for namedroppers-data@psg.com; Tue, 25 Mar 2008 08:14:43 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je4Ii-000I8L-WA for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 08:14:38 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 9E0D51C0128; Tue, 25 Mar 2008 09:14:31 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 985291C0126; Tue, 25 Mar 2008 09:14:31 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 8A91958EBB8; Tue, 25 Mar 2008 09:14:31 +0100 (CET) Date: Tue, 25 Mar 2008 09:14:31 +0100 From: Stephane Bortzmeyer To: Paul Vixie Cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience Message-ID: <20080325081431.GA29784@nic.fr> References: <20080324131740.GB14818@outpost.ds9a.nl> <48075.1206374827@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48075.1206374827@sa.vix.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-6-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mon, Mar 24, 2008 at 04:07:07PM +0000, Paul Vixie wrote a message of 54 lines which said: > i'd also like to see the following new paragraph added to section 10: > > All of the spoofing attacks described in this document are due to the > nearly universal lack of IP source address validation (see [BCP38] and > [SAC004] for more information). If the source address of a UDP datagram > were trustworthy, then there would be no need for forgery resilience in > DNS initiators. Strongly -1 here. See the Last Call comments and the IESG DISCUSS for draft-ietf-dnsop-reflectors-are-evil, which had the exact same issue (overreliance on BCP38). -- to unsubscribe send a message to namedroppers-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 Mar 25 03:25:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977023A6780; Tue, 25 Mar 2008 03:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2mMJy5WXgCd; Tue, 25 Mar 2008 03:25:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 156A43A6B2D; Tue, 25 Mar 2008 03:25:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je6Co-000ALU-39 for namedroppers-data@psg.com; Tue, 25 Mar 2008 10:16:34 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je6CR-000AIN-0G for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 10:16:16 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1Je6CJ-0001Jf-Ox for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 11:16:03 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 07E2B40B2; Tue, 25 Mar 2008 11:16:09 +0100 (CET) Date: Tue, 25 Mar 2008 11:16:09 +0100 From: bert hubert To: Yue Luo Cc: "namedroppers@ops.ietf.org" Subject: Re: diff between -02 and -03 of forgery-resilience Message-ID: <20080325101609.GA22470@outpost.ds9a.nl> References: <20080324131740.GB14818@outpost.ds9a.nl> <7F2791CD3A148642AF9069A0336EDE853792625419@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F2791CD3A148642AF9069A0336EDE853792625419@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mon, Mar 24, 2008 at 10:36:33AM -0700, Yue Luo wrote: > The draft discusses about the effect of TTL on the vulnerability. This Yue, You are right that the TTL features in the calculations - in degenerate cases the TTL revolves into the network rtt, as the draft notes. To not overly broaden the document, I'm trying to stay within the bounds of recommendations outside of the actual payload of DNS packets, and focus on port numbers, id choices etc. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 25 04:37:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D656B3A6EA9; Tue, 25 Mar 2008 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=-0.695, 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 hKPMk1SmFxHa; Tue, 25 Mar 2008 04:37:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 997FB3A6BF9; Tue, 25 Mar 2008 04:37:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je7IV-000KXD-Mo for namedroppers-data@psg.com; Tue, 25 Mar 2008 11:26:31 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je7IO-000KUb-Qh for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 11:26:30 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1Je7I9-0001dq-23 for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 12:26:09 +0100 Received: from fweimer by bfk.de with local id 1Je7IB-0003bR-9W for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 12:26:11 +0100 To: namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience References: <20080324131740.GB14818@outpost.ds9a.nl> <48075.1206374827@sa.vix.com> From: Florian Weimer Date: Tue, 25 Mar 2008 12:26:11 +0100 In-Reply-To: (Edward Lewis's message of "Mon, 24 Mar 2008 13:03:19 -0400") Message-ID: <82zlsnniy4.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: DNSEXT discussion * Edward Lewis: > Not "All of the spoofing attacks" fit this. If the spoof is sourced > on the same LAN (or "LAN") as the victim or the true server then > BCP38 won't matter. I think that there's a strong requirement to implement ingress filtering on LANs, too. Basically, you need to filter at the first trust boundary, which means that you cannot run a pure L2 access network anymore. However, my personal experience is that BCP38 is only implemented by cheap consumer Internet access. Anything else I've looked at performed egress filtering only (or the upstreams of the ISP I was subscribed to performed ingress filtering, same difference), if there were any filters at all. Like the L2 access network scenario, this doesn't protect you against DNS spoofing attacks. --=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 Mar 25 05:58:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E5428C2CC; Tue, 25 Mar 2008 05:58:57 -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 WQ-q0KULggoH; Tue, 25 Mar 2008 05:58:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D084428C145; Tue, 25 Mar 2008 05:58:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je8aC-0008o6-8n for namedroppers-data@psg.com; Tue, 25 Mar 2008 12:48:52 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je8a9-0008nd-6z for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 12:48:50 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [213.154.224.58]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m2PCmaHX062751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 13:48:38 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47E8F4A4.20209@nlnetlabs.nl> Date: Tue, 25 Mar 2008 13:48:36 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Brandon Black CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: OPT RR placement References: <200803250011.m2P0B1XS057971@drugs.dv.isc.org> <47E84884.7050407@gmail.com> In-Reply-To: <47E84884.7050407@gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Tue, 25 Mar 2008 13:48:39 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brandon, Brandon Black wrote: | Mark Andrews wrote: |> BIND reserves space for the OPT and TSIG/SIG records in the |> response. They always fit. OPT is logically part of the |> header. TSIG/SIG are authentication mechanisms. NSD (and unbound) perform similarly; they reserve space for the OPT (and TSIG) RRs in advance. Filling up with data is done by adding RRsets, in full or not at all, until the size limit is reached. If an answer or authority section RRset does not fit the TC bit is set, otherwise the TC bit is not set. It is not valid to give an answer lacking its authority section. You have to set the TC bit then. Because DNSSEC needs NSECs, negatives need SOA, and other cases. | Should TC be set if all of the Answers fit, but the auth RRs don't fit? Yes | Should partial RRsets be included in Answers if that's all that can be fit? No partial RRsets in the answer section. set the TC bit. No partial RRsets in other sections. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH6PSjkDLqNwOhpPgRAhDuAJ9kHmvoCgVoNyF+JI3c9vpdQOdekQCfdQ5N +DIOhtJJndvWWzT5EjrpMrI= =uVZh -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 25 06:27:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D891B28C350; Tue, 25 Mar 2008 06:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=1.838, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkRQ3PFDR1Y8; Tue, 25 Mar 2008 06:27:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49B7728C312; Tue, 25 Mar 2008 06:27:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je8zW-000ERh-0X for namedroppers-data@psg.com; Tue, 25 Mar 2008 13:15:02 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je8zO-000EQL-L5 for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 13:14:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4A93D11438; Tue, 25 Mar 2008 13:14:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: diff between -02 and -03 of forgery-resilience In-Reply-To: Your message of "Tue, 25 Mar 2008 09:14:31 +0100." <20080325081431.GA29784@nic.fr> References: <20080324131740.GB14818@outpost.ds9a.nl> <48075.1206374827@sa.vix.com> <20080325081431.GA29784@nic.fr> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 25 Mar 2008 13:14:54 +0000 Message-ID: <95746.1206450894@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > i'd also like to see the following new paragraph added to section 10: > > > > All of the spoofing attacks described in this document are due to the > > nearly universal lack of IP source address validation (see [BCP38] and > > [SAC004] for more information). If the source address of a UDP > > datagram were trustworthy, then there would be no need for forgery > > resilience in DNS initiators. > > Strongly -1 here. See the Last Call comments and the IESG DISCUSS for > draft-ietf-dnsop-reflectors-are-evil, which had the exact same issue > (overreliance on BCP38). does ed lewis' observation (that on LANs, BCP38 doesn't help you) and my agreement (that the language should be modified to that effect) help at all? i'm concerned that a reader of this document know the real source of the terror, which isn't in DNS's design alone, but rather, the whole IP stack. -- to unsubscribe send a message to namedroppers-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 Mar 25 07:07:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FED23A67D6; Tue, 25 Mar 2008 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-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 CPDPyvGeQ4dD; Tue, 25 Mar 2008 07:07:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71C793A699C; Tue, 25 Mar 2008 07:07:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je9fD-000KQw-7w for namedroppers-data@psg.com; Tue, 25 Mar 2008 13:58:07 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Je9f8-000KOX-R9 for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 13:58:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 17FFC28C2AF; Tue, 25 Mar 2008 07:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-dnsext-rfc2672bis-dname-11.txt Message-Id: <20080325140002.17FFC28C2AF@core3.amsl.com> Date: Tue, 25 Mar 2008 07:00:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Update to DNAME Redirection in the DNS Author(s) : S. Rose, W. Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-11.txt Pages : 16 Date : 2008-03-25 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is an update to the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision.Requirements Language 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-25064506.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 25 09:51:24 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679E63A6AA2; Tue, 25 Mar 2008 09:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scAmb-cGT+7c; Tue, 25 Mar 2008 09:51:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A44C63A6D3E; Tue, 25 Mar 2008 09:51:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeC9w-0003gQ-38 for namedroppers-data@psg.com; Tue, 25 Mar 2008 16:38:00 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeC81-0003Id-EU for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 16:36:34 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m2PGZrW8009563 for ; Tue, 25 Mar 2008 12:35:54 -0400 Message-ID: <47E929E9.8020700@nist.gov> Date: Tue, 25 Mar 2008 12:35:53 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: IETF DNSEXT WG Subject: dname-bis -11 draft submitted Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Just submitted the -11 version of the DNAME update draft. Changes from -09 to -10 (from the presentation at IETF 71): - changed Dynamic Update text according to namedroppers discussion - changed text on how caches should construct answers. Changes from -10 to -11 version of the DNAME update draft. - fixed wording error I pointed out in presentation (lower case "should" I try to avoid those simply to avoid confusion). - fixed error I made in Dynamic Update section (pointed out by Sam Weiler during the WG session). Thanks, Scott (and Wouter) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 25 12:52:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21A73A6964; Tue, 25 Mar 2008 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=-0.768, 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 dFcDa0cclw+K; Tue, 25 Mar 2008 12:52:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C57A93A681F; Tue, 25 Mar 2008 12:52:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeF0K-0008B4-2E for namedroppers-data@psg.com; Tue, 25 Mar 2008 19:40:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeF0A-00089T-Fz for namedroppers@ops.ietf.org; Tue, 25 Mar 2008 19:40:12 +0000 Received: from [192.168.1.100] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2PJdrd4097328; Tue, 25 Mar 2008 15:39:53 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080324131740.GB14818@outpost.ds9a.nl> References: <20080324131740.GB14818@outpost.ds9a.nl> Date: Tue, 25 Mar 2008 15:38:59 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: diff between -02 and -03 of forgery-resilience Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 14:17 +0100 3/24/08, bert hubert wrote: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-03.txt Comments on -03, "#" in the left means lines from the document. # Measures for making DNS more resilient against forged answers # draft-ietf-dnsext-forgery-resilience-03.txt ... # Abstract # # The current Internet climate poses serious threats to the Domain Name # System. In the interim period before the DNS protocol can be secured # more fully, measures can already be taken to harden the DNS to make # 'spoofing' a recursing nameserver many orders of magnitude harder. # # Even a cryptographically secured DNS benefits from having the ability # to discard bogus answers quickly, as this potentially saves large # amounts of computation. # # By describing certain behaviour that has previously not been # standardised, this document sets out how to make the DNS more # resilient against accepting incorrect answers. This document updates # RFC 1034. I don't like the apologetic tone of the abstract. The more I have seen of DNSSEC the more I realize it is a mistake to fuse cryptography into the naming system and protocol - but that's an aside. The upshot is that this document shouldn't be apologizing for its existence, what it is espousing is just good, making it harder to stuff answers is nothing but "goodness." (My) Abstract (suggestion) This document presents steps that can be taken to make it harder for a third party to forge a reply to an outstanding query. By making it harder to predict the values of the fields a client checks to verify that an incoming response relates to an outstanding query, the chance a third party can insert an illegitimate answer is lowered. This document updates portions of RFC 1034 instructing a client to be more careful when accepting incoming responses. # 2. Introduction (First a disclaimer - when it comes to opening sections of documents I get overly concerned with setting up the problem correctly. I'll try to keep my nits to a minimum.) # ... # Additionally, it has recently become possible to acquire SSL/TLS # certificates with no other confirmation of identity than the ability # to respond to a verification email sent via SMTP ([RFC2821]) - which # generally uses DNS for its routing. The above is the kind of "claim" that really needs to be substantiated via a reference. I am referring to the "possible to acquire certificates" statement. As a matter of fact, I don't really believe that it is true, at least I doubt the value of a certificate backed only by email. I would suspect there is also a credit card angle to this too. But I stress, I am not trying to argue this point, but just asking for the inclusion of a reference to a document that supports the claim. # 3. Description of DNS spoofing # # When certain steps are taken it is feasible to 'spoof' the current # deployed majority of caching resolvers with carefully crafted and # timed DNS packets. Once spoofed, a caching server will repeat the # data it wrongfully accepted, and make its clients contact the wrong, # and possibly malicious, servers. Is 'spoof' the accurate word here? "Forged answers" are the problem, as well as the practice of "message insertion." I suppose you could say it is the case that the problem is someone spoofing a server, but the problem being tacked here is not server authentication but forgery resistance. # To understand how this process works it is important to know what # makes a resolver (and more specifically a caching server) accept an # answer. # # The following sentence in section 5.3.3 of [RFC1034] presaged the # present problem: # # The resolver should be highly paranoid in its parsing of responses. # It should also check that the response matches the query it sent # using the ID field in the response. # # DNS data is to be accepted by a resolver if and only if: These rules are not from 5.3.3. of RFC 1034, are they? From the flow here I thought they were. These are this document's summary, right? # # 1. The question section of the reply packet is equivalent to that of # a question packet currently waiting for an answer # # 2. The ID field of the reply packet matches that of the question # packet # # 3. The answer comes from the same network address the question was # sent to # # 4. The answer comes in on the same network address, including port # number, as the question was sent from # # In general, the first answer matching these four conditions is # accepted. "In practice" not "in general." What I want to make clear (and this has already been in email) is that the "first answer" acceptance is a convenience and *not necessarily* the best approach. Perhaps it would illustrative to show a time diagram of how a forged answer might slip in. (Packet sniffer attack) Client v issues query gets gets DNS forgery ^ true ^ Intermediate v Sees query (Attacker) Forges response ^ Intended v Sees query DNS Server Prepares response ^ 0------------1------------2------------3------------4-----time-> (Predictor Attack) Client v issues query gets gets DNS forgery ^ true ^ Intermediate based on prediction (Attacker) sends response ^ Intended v Sees query DNS Server Prepares response ^ 0------------1------------2------------3------------4-----time-> In both cases, the false one comes first, which is why the current practice (accept first) is suspect. BTW - the ascii art is "more precise than accurate," meant as a substitute for sending in the text I'd like to see. # If a third party succeeds in meeting the four conditions before the # answer from the authentic answer does so, it is in a position to feed # a resolver fabricated data. When it does so, we dub it an attacker, # attempting to spoof in fake data. # # All conditions mentioned above can theoretically be met by a third # party, with the difficulty being a function of the resolver # implementation and zone configuration. "difficulty" of what? I think you mean generating a forgery that is accepted as genuine. # 4. Details Details of what...? Details of attacks or details of defenses? # The previous paragraph discussed a number of requirements an attacker # must match in order to spoof in manipulated (or fake) data. This # section discusses the relative difficulties and how implementation # defined choices impact the amount of work an attacker has to perform # to meet said difficulties. # # Some more details can be found in section 2.2 of [RFC3833]. # # 4.1. Forcing a question I think this is what you are saying in this section: This is one form of what I call a predictive attack. In this, the attacker predicts that the victim will make a move in response to a stimulus from the attacker. To the attacker, they first decide what forged answer they want the victim to accept and then force the victim to ask the question. The challenge remaining for the attacker is to fill in the fields of the response that it can't predict before the true response arrives. ... Another form of predictive attack is one that takes advantage of the TTL, the attacker doesn't make the victim ask but guesses when the question will arise and then attempts to get an accepted forgery. # 4.3. Matching the ID field ... # Additionally, if the target nameserver can be forced into having # multiple identical questions outstanding, the 'Birthday Attack' # phenomenon means that any fake data sent by the attacker is matched # against multiple outstanding questions, significantly raising the # chance of success. Further details in Section 5. I ask (again) for a reference to something defining the term "Birthday Attack." I am not asking for an explanation of it in email, this document has to have a refernce for the term somewhere. # 4.4. Matching the source address of the authentic answer # ... # Generally, this condition requires at most two or three attempts # before it is matched. # # It should be noted that meeting this condition entails being able to # transmit packets on behalf of the address of the authoritative # nameserver. While two Best Current Practice documents ([RFC2827] and # [RFC3013] specifically) direct Internet access providers to prevent # their customers from assuming IP addresses that are not assigned to # them, these recommendations are not universally (nor even widely) # implemented. After reading this section, I wonder why the response's source address is checked at all. If it is soooo easy to forge, what's the use? # 4.6. Have the answer arrive before the authentic answer # # Once any packet has matched the previous four conditions (plus # possible additional conditions), no further answers are generally # accepted. # # This means that the third party has a limited time in which to inject # its spoofed answer, typically in the order of at most 100ms # (depending on the network distance to the authentic authoritative # nameserver). # # This time period can be far longer if the authentic authoritative # nameservers are (briefly) overloaded by queries, perhaps by the # attacker. So the summary is - the attacker can either stimulate the victim into asking, otherwise predict the time of an particular question, or just through dumb luck, throw packets forging the message ID, question, source and destination addresses plus a plausible reply (answer/authority/additional section) in less than 100ms. Our challenge is to make the forgery too difficult to do. What is unclear is whether the attacks assume that the attacker is 1) next to the victim 2) between the victim and true source (in-line) 3) next to true source 4) no where's near either and whether 5) the attack is targeting a particular domain 6) the attack is targeting the cache of the victim # 5. Birthday attacks # # The so called birthday paradox implies that a group of 23 people # suffices to have a more than even chance of having two or more # members of the group share a birthday. This time I'll ask the same question again - the number "23" is related to only 366 days in a year, right? What would the number be if it were 8K or 32K (which are the numbers presented earlier in the section on message IDs being just 14 or the full 16 bits)? # An attacker can benefit from this exact phenomenon if it can force # the target resolver to have multiple equivalent outstanding questions # at any one time to the same authoritative server. This is a new "issue" - whether a querier would have such a situation. # 6. Accepting only in-zone answers This is not the next section I expected. The document has taken time to set up the problem of forgery and I would expect that is time to shift gears into the steps to be taken to make forgery harder. But instead we branch off into something completely unrelated. # Answers from authoritative nameservers often contain information that # is not part of the zone for which we deem it authoritative. As an # example, a query for the MX record of a domain might get as its # answer a mail exchanger in another domain, and additionally the IP # address of this mail exchanger. # # If accepted uncritically, the resolver stands the chance of accepting # data from an untrusted source. Care must be taken to only accept # data if it is known that the originator is authoritative for that # data. I really don't buy that. If that were true, glue would never work. In DNS you need to have some level of trust in what you see at first peek but know to find better info, and ditch bad stuff once you know. # # One very simple way to achieve this is to only accept data if it is # part of the domain we asked the question for. I think this is too simplistic to be true. What you want to restrict acceptance to is data germane to the question. Like the NS records for the zone purporting to be authoritative for the answer, CNAME/DNAME records redirection. While I don't like that RFC 1034 included CNAME chasing (in retrospect a mistake in my book but I realize why it is there), we have it. (Terminology - we don't ask for data that is "part of a domain.") # 7. Combined difficulty # # Given a known or static destination port, matching ID field, source Instead of "destination" use some play on "query/question" "source/origination" to disambiguate between the query and response source and destination. # and destination address requires on average in the order of 2 * 2^15 # = 65000 packets, assuming a domain has 2 authoritative nameservers. 64K packets...and it isn't "2 authoritative" but "2 nameserver IP addresses." Remember, we have anycast and load balancers out there. # If the window of opportunity available is around 100ms, as assumed # above, an attacker would need to be able to briefly transmit 650000 # packets/s to have a 50% chance to get spoofed data accepted on the # first attempt. # # A realistic minimal DNS answer consists of around 80 bytes, including # IP headers, making the packet rate above correspond to a respectable # burst of 416Mb/s. But this attacks just one victim server, not a widespread cache poisoning. # As of mid-2006, this kind of bandwidth was not common but not scarce # either, especially among those in a position to control many servers. # # These numbers change when a window of a full second is assumed, # possibly because the arrival of the authentic answer can be prevented # by overloading the bonafide authoritative hosts with decoy questions. # This reduces the needed bandwidth to 42 Mb/s. I get a little uneasy stretching this without evidence of actual activity to back it up. For one, I'd have to also have sufficient bandwidth to flood all authoritative servers (and recall when you deal with anycast, all the servers that the victim would see, not the attacker) to lengthen the window of vulnerability. If I was cutting down from 420 to 42 Mb/s for an attack at a cost of needing n x a high number to shut down other server response, I don't think it would be worth it - and it would raise alarm bells more readily. Upshot - the above paragraph seems like hyperbole to me. # If in addition the attacker is granted more than a single chance and # allowed up to 60 minutes of work on a domain with a time to live of ... Most crooks screw up on the first attempt and get cold feet or caught. This is why law enforcement works. Again, this paragraph seems more like a scare statement than the telling of a motivating incident. # 7.2. Calculation # # The probability of spoofing a resolver is equal to the amount of fake # packets that arrive within the window of opportunity, divided by the # size of the problem space. "Spoofing a resolver"...I think that should be "getting a forged answer accepted as real. And I don't believe that is the correct probability measure either. What you have is a measure of what percentage of possible answers could be confused with the real one. The probability of getting an answer accepted illegitimately is the probability of getting an acceptable forgery through in the time allotted. # # When the resolver has 'D' multiple identical outstanding questions, # each fake packet has a proportionally higher chance of matching any # of these questions. This assumption only holds for small values of # 'D'. If they are "identical outstanding questions" then what does "matching any of these" refer to? I suppose your meaning of identical has some degrees of freedom in it. # # In symbols, if the probability of being spoofed is denoted as P_s: # # D * F # P_s = --------- # N * P * I # P_s = (average number of identical queries x packets sent by attacker) / (number of nameservers x ports x ids) I don't know...that makes no real sense to me. You are assuming that the attacker is trying to get one "point of poisoning" at one server. A point of poisoning is either one RRset or all the sets at a domain name (via an "any" response). (I've been staring at this for a while and can't get it, so I'll move on.) # 8. Discussion # # The calculations above indicate the relative ease with which DNS data # can be spoofed. For example, using the formula derived earlier on a # domain with a 3600 second TTL, an attacker sending 7000 fake answer # packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a # record in the first 24 hours, which rises to 50% after a week. The problem I have is that the "relative ease" is only presented via a calculation that I have a hard time following. Is this kind of attack really happening? Is there any evidence to demonstrate (as opposed to calculate) the relative ease? # 9. Countermeasures ... # o Question name (compared case-insensitively) # # o Question class and type Keep in mind that the above does not (yet) apply to AXFR. # Resolver implementations MUST have the ability to: Why are these "MUST"s and not "RECOMMEND"ations? Is this needed for interoperability? # If a resolver sends out multiple equivalent questions to any # authoritative server, before receiving an answer, all MUST have # identical ID, source address and source port. Then you are fixing D:=1? # Resolvers SHOULD favour authoritative nameservers with which a trust # relation has been established; Stub-resolvers SHOULD be able to use # TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their # recursive resolver. Or SIG(0) or some other message/datagram verification scheme... # In case a cryptographic verification of answer validity is available, # resolver implementations MAY waive above rules, and rely on this # guarantee instead. Why? What if I sign something, distribute it and then discover I want to "revoke" it. It is possible someone could replay the shoulda-been-revoked data to drown out the good replacement data. Or what if I yank off DNSSEC because of an error and want to return to unsigned? Cryptography is not a panacea. # 10. Security Considerations No IANA Considerations? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 27 10:00:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B875C28C929; Thu, 27 Mar 2008 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.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 JGydXQ2divwq; Thu, 27 Mar 2008 10:00:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBED928C309; Thu, 27 Mar 2008 09:59:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JevDS-000Ox4-O3 for namedroppers-data@psg.com; Thu, 27 Mar 2008 16:44:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JevDL-000Ovp-AV for namedroppers@ops.ietf.org; Thu, 27 Mar 2008 16:44:36 +0000 Received: from [192.168.1.100] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2RGiGQJ023672; Thu, 27 Mar 2008 12:44:17 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080325140002.17FFC28C2AF@core3.amsl.com> References: <20080325140002.17FFC28C2AF@core3.amsl.com> Date: Thu, 27 Mar 2008 12:44:11 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D Action:draft-ietf-dnsext-rfc2672bis-dname-11.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 7:00 -0700 3/25/08, Internet-Drafts@ietf.org wrote: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-11.txt # Update to DNAME Redirection in the DNS # draft-ietf-dnsext-rfc2672bis-dname-11 # # 1. Introduction # # DNAME is a DNS Resource Record type. DNAME provides redirection from # a part of the DNS name tree to another part of the DNS name tree. Suggested change to the first sentence: DNAME is a DNS Resource Record type defined in RFC 2672. ++++++++++++++++++++ # Take for example, looking through a zone (see RFC 1034 [RFC1034], # section 4.3.2, step 3) for the domain name "foo.example.com" and a # DNAME resource record is found at "example.com" indicating that all # queries under "example.com" be directed to "example.net". The lookup # process will return to step 1 with the new query name of # "foo.example.net". Had the query name been "www.foo.example.com" the # new query name would be "www.foo.example.net". I would place the example down further, after the next paragraph. I find that examples are good, but better left until after the definition. # The DNAME RR is similar to the CNAME RR in that it provides # redirection. The CNAME RR only provides redirection for exactly one # name while the DNAME RR provides redirection for all names in a sub- # tree of the DNS name tree. Because of the fights over what "similar" means, I'd suggest this: The DNAME RR and the CNAME RR [RFC 1034] cause a lookup to (potentially) return data corresponding to a domain name different from the queried domain name. The difference between the two resource records is that the CNAME RR directs the lookup of data at its owner to another single name, a DNAME RR directs lookups for data at descendents of its owner's name to corresponding names under a different (single) node of the tree. # 2. The DNAME Resource Record # # 2.1. Format ... # The DNAME RR causes type NS additional section processing. That's not really a "Format" issue. (Belongs in section 3.) # 2.2. The DNAME Substitution # # DNAMEs cause a name substitution to happen to query names. This is # called the DNAME substitution. The portion of the QNAME ending with # the root label that matches the owner name of the DNAME RR is # replaced with the contents of the DNAME RR's RDATA. The owner name # of the DNAME is not itself redirected, only domain names below the # owner name are redirected. Only whole labels are replaced. A name # is considered below the owner name if it has more labels than the # owner name, and the labels of the owner name appear at the end of the # query name. See the table of examples for common cases and corner # cases. (It's darn hard to word this definition. Maybe we need to invent a term for the sequence of labels that end with the root. One problem is trying to work in that it is not necessary to read a domain name r to l or l to r [accommodating scripts that are read left to right] but retaining that there is a root "on top" and we descend the tree to the desired location.) When following RFC 1034, section 4.3.2's algorithm's third step, "start matching down, label by label, in the zone" a node is found to own a DNAME resource record a DNAME substitution occurs. The name being sought may be the original query name or a name that is the result of a CNAME resource record being followed or a previously encountered DNAME. As is the case of finding a CNAME resource record or NS resource record set, the processing of a DNAME will happen prior to finding the desired domain name. A DNAME substitution is performed by replacing the labels of the name being sought matching the owner name of the DNAME resource record with those labels with the string of labels in the RDATA field. The matching labels end with the root label in all cases. # 2.3. DNAME Apex not Redirected itself # # The owner name of a DNAME is not redirected itself. The reason for # the original decision was that one can have a DNAME at the zone apex # without problem. Then use this DNAME at the zone apex to point # queries to the target zone. There still is a need to have the # customary SOA and NS resource records at the zone apex. This means # that DNAME does not mirror a zone completely, as it does not mirror # the zone apex. Remove the "without problem" phrase. And then strike the sentence after that. # Another reason for excluding the DNAME owner from the DNAME # substitution is that one can then query for the DNAME through RFC # 1034 [RFC1034] caches. That doesn't make much sense to me, but I can't think of a replacement or a real reason to strike it. # 2.4. Names Next to and Below a DNAME Record # # Other resource records MUST NOT exist at a domain name subordinate to # the owner of a DNAME RR. To get the contents for names subordinate # to that owner, the DNAME redirection must be invoked and the # resulting target queried. A server MAY refuse to load a zone that # has data at a domain name subordinate to a domain name owning a DNAME # RR. If the server does load the zone, those names below the DNAME RR # will be occluded. Also a server SHOULD refuse to load a zone # subordinate to the owner of a DNAME record in the ancestor zone. See # Section 5.2 for further discussion related to dynamic update. The term "occluded" needs definition (or a reference). # 2.5. Compression of the DNAME record. # # The DNAME owner name can be compressed like any other owner name. # The DNAME RDATA target name MUST NOT be sent out in compressed form, # so that a DNAME RR can be treated as an unknown type. [RFC 3597] - unknown types # Although the previous specification [RFC2672] talked about signaling # to allow compression of the target name, no such signaling is # explicitly specified. previous DNAME specification +++++ What is meant by "no such signaling is *explicitly* specified"? I don't know if this means that this revision is saying there is no "such signalling" or something else. # 3. Processing Here is where the comment (under Formatting) about causing "additional" processing should be put. # 3.1. Wildcards I would have expected the first order of business would be to go over in detail the changes to "the algorithm" in RFC 1034/4.3.2 before outlying issues. Even if you are subsuming the existing definitions - but I recall that even the old changes (in RFC 2672) needed updating. # 3.2. CNAME synthesis # # On the server side, the DNAME RR record is always included in the # answer section of a query, when one is encountered. A CNAME RR When preparing an response, a server upon performing a DNAME substitution will in all cases include the DNAME RR used in the answer section. Note - not "of a query" but "of a response." # record with TTL equal to the corresponding DNAME RR is synthesized and included in the answer section # for old resolvers, specifically for the QNAME in the query. DNSSEC but I don't get "for the QNAME in the query." # [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does # not have to be signed. The DNAME has an RRSIG and a validating # resolver can check the CNAME against the DNAME record and validate # the DNAME record. # ... # The UD bit is part of the EDNS extended RCODE and Flags field. It is # used to omit server processing, transmission and resolver processing # of unsigned synthesized CNAMEs. Resolvers can set this in a query to EDNS is RFC 2671 "unsigned?" As opposed to negative numbers? ;) # request omission of the synthesized CNAMEs. Servers copy the UD bit # to the response, and can omit synthesized CNAMEs from the answer. # Older resolvers do not set the UD bit, and older servers do not copy # the UD bit to the answer, and will not omit synthesized CNAMEs. ... # 3.3. Acceptance and Intermediate Storage # # DNS caches can encounter data at names below the owner name of a # DNAME RR, due to a change at the authoritative server where data from # before and after the change resides in the cache. This conflict # situation is a transitional phase, that ends when the old data times # out. The cache can opt to store both old and new data and treat each # as if the other did not exist, or drop the old data, or drop the # longer domain name. In any approach, consistency returns after the # older data TTL times out. I would think that with the new "occluded" text, the option to drop the longer name is out the window. Come to think of it though, there is no right answer for this situation. # 3.4. Server algorithm This should be 3.1... # 3. Start matching down, label by label, in the zone. The matching # process can terminate several ways: ... # 5. Other Issues with DNAME # # There are several issues to be aware of about the use of DNAME. # # 5.1. MX, NS and PTR Records Must Point to Target of DNAME What about the replacement field in the NAPTR record or the domain name in an SRV? (Trying to think of other RR's that contain domain names.) What about a URL in a NAPTR regExp field? Or is the problem only with records that have special processing for the additional section? Also, this section title is a bit hard to digest. "Point to" and "Target of" are not precise terms. Is this more accurately "RDATA-contained domain names cannot be below DNAME owners?" (I'm guessing.) Or something that that doesn't refer to "pointing" or "target."` -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-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 Mar 27 19:43:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962543A699D; Thu, 27 Mar 2008 19:43:45 -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 qrvkPmMlz1Pm; Thu, 27 Mar 2008 19:43:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD0483A685B; Thu, 27 Mar 2008 19:41:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jf4M6-0005bZ-Co for namedroppers-data@psg.com; Fri, 28 Mar 2008 02:30:10 +0000 Received: from [129.9.40.81] (helo=odvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jf4M3-0005bM-W1 for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 02:30:09 +0000 Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.99.241]) by odvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id EC7444BD4 for ; Thu, 27 Mar 2008 22:31:10 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008032722300306082 for ; Thu, 27 Mar 2008 22:30:03 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m2S2U4ik025942 for ; Thu, 27 Mar 2008 21:30:04 -0500 (EST) Message-ID: <47EC582C.5060500@chrysler.com> Date: Thu, 27 Mar 2008 21:30:04 -0500 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D Action:draft-ietf-dnsext-rfc2672bis-dname-11.txt References: <20080325140002.17FFC28C2AF@core3.amsl.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: DNSEXT discussion Edward Lewis wrote: > > > (It's darn hard to word this definition. Maybe we need to invent a > term for the sequence of labels that end with the root. Is "suffix" too overloaded a term to use here? In this context I think it effectively denotes "a sequence of labels extending rootwards". If it is desired to emphasize that the label-sequence actually _terminates_ at the root, then a compound term could be used, such as "root-terminating suffix", "full suffix", "complete suffix" or some such. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 28 08:28:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339673A68FC; Fri, 28 Mar 2008 08:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.005 X-Spam-Level: *** X-Spam-Status: No, score=3.005 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 JkKYqt6VuD0w; Fri, 28 Mar 2008 08:28:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C3683A68F9; Fri, 28 Mar 2008 08:28:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JfGNU-000BWw-Uj for namedroppers-data@psg.com; Fri, 28 Mar 2008 15:20:24 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JfGNR-000BWD-P7 for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 15:20:23 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2SFKIlr038112 for ; Fri, 28 Mar 2008 11:20:18 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2SFKId8038111 for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 11:20:18 -0400 (EDT) (envelope-from namedroppers) Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jf2m1-000Cfy-Bw for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 00:48:51 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA242535307; Fri, 28 Mar 2008 01:48:27 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA29102; Fri, 28 Mar 2008 01:48:21 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200803280048.BAA29102@TR-Sys.de> Subject: draft-ietf-dnsext-rfc2672bis-dname-09 UD definition placement To: scottr@nist.gov, wouter@nlnetlabs.nl Date: Fri, 28 Mar 2008 01:48:21 +0100 (MEZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1206717618-32751-11" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is a multi-part message in MIME format... ------------=_1206717618-32751-11 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Content-Disposition: inline [ 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. ] Another unrelated issue I found in draft-ietf-dnsext-rfc2672bis-dname-09 : The definition of the EDNS UD bit currently is placed in Section 3.2, under the umbrella of Section 3. "Processing". This does not make much sense to me. The basice protocol/format definitions underlying the whole specification should be grouped together. To obtain a more logical structure of the document, I therefore recommend to move that definition (artwork plus basic description of purpose) into Section 2.1. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ------------=_1206717618-32751-11 Content-Type: text/plain; name="SpamAssassinReport.txt" Content-Disposition: inline; filename="SpamAssassinReport.txt" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Spam detection software, running on the system "mail.ogud.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: [ 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. ] [...] Content analysis details: (3.2 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.4 HEADER_SPAM Bulk email fingerprint (header-based) found 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS -1.2 AWL AWL: From: address is in the auto white-list ------------=_1206717618-32751-11-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 28 08:33:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B71F3A6C63; Fri, 28 Mar 2008 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.749 X-Spam-Level: *** X-Spam-Status: No, score=3.749 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, 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 wUMe8LxEgELY; Fri, 28 Mar 2008 08:33:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09B8D28C353; Fri, 28 Mar 2008 08:30:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JfGMq-000BPn-4q for namedroppers-data@psg.com; Fri, 28 Mar 2008 15:19:44 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JfGMf-000BLj-RZ for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 15:19:39 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2SFJMQq037971 for ; Fri, 28 Mar 2008 11:19:22 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2SFJMDq037970 for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 11:19:22 -0400 (EDT) (envelope-from namedroppers) Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeuJ1-000FXb-0v for namedroppers@ops.ietf.org; Thu, 27 Mar 2008 15:46:29 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA240012757; Thu, 27 Mar 2008 16:45:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA28413 for namedroppers@ops.ietf.org; Thu, 27 Mar 2008 16:45:44 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200803271545.QAA28413@TR-Sys.de> Subject: draft-ietf-dnsext-forgery-resilience-03 To: namedroppers@ops.ietf.org Date: Thu, 27 Mar 2008 16:45:44 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion [ 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. ] ----- Forwarded message from Alfred HÎnes ----- >From A.Hoenes@WOTAN.TR-Sys.de Thu Mar 27 16:42:26 MEZ 2008 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA239932545; Thu, 27 Mar 2008 16:42:25 +0100 Return-Path: Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA28346; Thu, 27 Mar 2008 16:42:23 +0100 (MEZ) From: Alfred HÎnes Message-Id: <200803271542.QAA28346@TR-Sys.de> Subject: draft-ietf-dnsext-forgery-resilience-03 To: bert.hubert@netherlabs.nl, remco@virtu.nl Date: Thu, 27 Mar 2008 16:42:23 +0100 (MEZ) Cc: namedroppers@ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Hello, after some time I eventually found the time to again spent some time for the latest revision of your DNS Forgery Resilience I-D, draft-ietf-dnsext-forgery-resilience-03. The notes below are restricted to areas already discussed earlier but not (yet) addressed in this edition, and which I did not find being subject to elaboration on the list, quickly browsing through the recent records in the list archive. (1) Section 1.1 -- editorial nit Please apply a consistent style of punctuation, at the end of the definitions in Section 1.1. (2) Section 3 -- order of numbered items The draft says: DNS data is to be accepted by a resolver if and only if: 1. The question section of the reply packet is equivalent to that of a question packet currently waiting for an answer 2. The ID field of the reply packet matches that of the question packet 3. The answer comes from the same network address the question was sent to 4. The answer comes in on the same network address, including port number, as the question was sent from This seems to suggest an order of checks to be performed by the receiver of a DNS reply, but the sequence of items is illogical and inappropriate for several reasons: a) The checks should be performed 'bottom up' in the network layers, for architectural reasons. If TCP transport is used, the correlation of transport address tuples (src/dst addr & port) is performed at the IP and TCP layers, anyway, before the application ever sees the response. In the (standard) case of UDP transport, these checks must be performed by the application (i.e., DNS resolver software) in a transport layer API specific manner. For the sake of proper structuring, such code should parallel the code for TCP transport and provide a comparable set of functionality to the application (DNS) layer. b) To mitigate the net effect of DoS attacks, the computationally most simple checks should be performed first. Because the transport address tuples have to be matched first anyway to discover the DNS query context of the DNS reply, it is natural that the matching check of source address and port and destination address and port of the reply should be performed first. c) If multiple transactions are outstanding to an authoritative server using the same transport 'connection' (addr+port quadruple), the next step in discovering the context is the check of the ID field. d) If (and only if) all these checks have identified a single open query context, the reply can be accepted provisionally, and then the details of the question section be cross-checked with the query sent. This is a much more complex operation, in particular due to the complicated rules for QNAME matching (case-insensitive matching of standard DNS labels, etc.), and hence should be performed late anyway -- see b) above. Hence, the above snippit must be reordered and the items renumbered, and the wording adjusted to the amount of context available at each level: DNS data is to be accepted by a resolver if and only if: | 1. The answer comes from a transport address (IP address and port | number) a question was sent to recently (and still awaiting an | answer). | 2. The answer comes in on the same transport address (IP address | and port number) a question was sent from to the transport | address checked in step 1. | 3. The ID field of the reply packet matches that of a question | packet sent using the transport address pair checked in steps | 1 and 2. | 4. The question section of the reply packet is equivalent to that of | the question packet identified in step 3 as currently waiting for | an answer, in particular, QCLASS and QTYPE match literally, and | QNAME matches according to the applicable label-specific rules. Note 1: Section 9 already almost adheres to this ordering; I suggest to only reverse the last two bullets in the first part of section 9 to list the QCLASS + QTYPE check *before* the more complicated QNAME check. Note 2: Since this is a SHOULD requirement, some resolvers might see the need to allow administrative suppressing some of these checks under particular circumstances, e.g. for TCP connections dedicated for a single AXFR query to legacy servers not following the echo-back rule for the ID field. This might be clarified in the draft at this place as well. (3) Section titles After all, the title of Sections 3 and 4 seem to be inappropriate. How about changing: 3. Description of DNS spoofing --- 3. Accepting DNS Replies and: 4. Details --- 4. Details of DNS Reply Spoofing Attempts (4) Section 4.4 In the last paragraph, delete the word "spcifically"; it has become redundant, or even confusing, by the text change performed recently: [...]. While two Best Current Practice documents ([RFC2827] and | [RFC3013] specifically) direct Internet access providers to prevent their customers from assuming IP addresses that are not assigned to them, these recommendations are not universally (nor even widely) implemented. --- [...]. While two Best Current Practice documents ([RFC2827] and | [RFC3013]) direct Internet access providers to prevent their customers from assuming IP addresses that are not assigned to them, these recommendations are not universally (nor even widely) implemented. Furthermore, I strongly recommend putting more emphasis on the inalienable importance of ingress filtering, e.g., by replacing the last two lines above by: [...] unfortunately these recommendations are yet not universally (nor even widely) implemented. (5) Section 4.5 Because of the drastical operational consequences, I suggest to amend the text in Section 4.5, after the 2nd paragraph, as follows: The actual address of a recursing nameserver is generally known; the port used for asking questions is harder to determine. Most current resolvers pick an arbitrary port at startup (possibly at random) and use this for all outgoing questions. In quite a number of cases the source port of outgoing questions is fixed at the traditional DNS assigned server port number of 53. | | Note however that, if the resolver is located behind a (port | translating) NAT or firewall, the externally visible source port | number will be randomized, perhaps over the full port number range. | Depending on the strategy implemented in the NAT or firewall, the | port number will be chosen independent of the destination transport | address or per transport address association. | | The more granular the port selection of the NAT/firewall and the | larger the pool of port numbers used is, and the better the random | port number selection algorithm performs, this will restrict the | opportunities for an attacker to spoof the source transport address | significantly, and as such mitigate the threat of cache poisoning | for a resolver behind a NAT or firewall middlebox, from outside of | the protected subnetwork. (6) Section 7.2 -- editorials The draft text still uses a confusing mix of quoted and non-quoted instances of the formula variable names in the running text. I strongly suggest to remove all single quotes still present in the text surrounding variable names of formula terms. (7) Section 9 -- order of attribute checks See Note 1 in item (2) above. (8) Section 9 -- Licence for active DoS ??? Section 9 contains a fatal recommendation. Similar text in other Internet-Drafts already has caused much trouble and denial of service to legitimate, well-behaving resolvers. The first bullet in the second part of Section 9 says: o Use an unpredictable source port for outgoing queries from a range | (53, or > 1024) of ports that is as large as possible and practicable; It should say: o Use an unpredictable source port for outgoing queries from a range | of ports that is as large as possible and practicable; Rationale: Apparently, similar recommendations have caused administrators to block access to DNS servers for specific source port number ranges, in particular 1..52 and 54..1023. This immediately leads to denial of service for all resolvers located behind a (port translating) NAT/firewall middlebox that randomizes the externally visible source port numbers, e.g. of DNS queries sent out to the globally routable Internet. For instance, practical observations and dedicated tests indicate that a well-known major player in IT has established (since last summer) such packet filters for the name servers they operate for the public part of the company resources and for the public services they offer, including a popular "high temperature" mail gate. This effectively blackholes all attempts to establish communication with users/clients of the "protected" infrastructure, for all users of a DNS resolver located behind a port mapping NAT/firewall. In particular, this practice makes it impossible for us to send mail to IETF members affiliated with that company or being clients of the mail gate they operate. I have been told that the above restriction was based on the (platform dependent) subdivision of port numbers. This neglects the fundamental distinction between server port numbers and client port numbers. The classification of port numbers as codified in RFCs only applies to server ports, i.e. ports intentionally unbound to a specific remote transport address (unspecific Passive OPEN). Apparently, this distinction is disregarded deliberately by some (implementors and) administrators. However, looking into RFC 1122, it becomes immediate that the practice of restricting access for traffic based on (client) port numbers in the range deemed 'restricted' in popular operating systems (1-1023) is inappropriate. Section 4.2.2.1 of RFC 1122 says (with respect to TCP -- but the sections on UDP there refer to the port number discussion for TCP as well): Some systems extend this notion by adding a third subdivision of the TCP port space: reserved ports, which are generally used for operating-system-specific services. [...] [...] Some systems further choose to protect well-known and reserved ports by permitting only privileged users to o>>> open TCP connections with those port values. This is o>>> perfectly reasonable as long as the host does not o>>> assume that all hosts protect their low-numbered ports o>>> in this manner. I repeat: ... as long as the host does not assume that all hosts protect their low-numbered ports in this manner. Colophon: Some major providers of DNS services (including the operators of the largest gTLDs) and important security service providers once had installed similar filters as well, but they all have diligently removed these quickly after being informed of the damaging consequences. To my knowledge, it's only the single big player indicated above which still maintains these filters and has been resistive to all attempts to explain the DoS it causes. (9) Section 9 -- conflict with other specification Subsequently, the draft requests: If a resolver is multihomed or otherwise has the ability to transmit and receive datagrams using more than one IP source address, then an IP address can be chosen at random in order to increase an attacker's difficulty in guessing what address to flood. This recommendation is inappropriate. Source address selection is governed by specific rules that should not be overridden by this document. In particular, RFC 3484 has been written for IPv6 and entirely dedicated to this topic (and there is work in progress for a revised version of RFC 3484). Consequently, the above clause should either be omitted entirely, or be amended by a qualifying note, e.g.: If a resolver is multihomed or otherwise has the ability to transmit and receive datagrams using more than one IP source address, then, | as far as other standards do not overrule this recommendation, an IP address can be chosen at random in order to increase an attacker's difficulty in guessing what address to flood. (10) Section 9 -- further minor issues a) The IETF has reached consensus to spell IP Security as "IPsec", thus please s/IPSEC/IPsec/ ' b) RFC 2401 has been obsoleted long ago by RFC 4301, which in turn now should be quoted for IPsec. (11) Section 9 -- substantial omission As already mentioned in item (4) above, I strongly miss emphasis on the importance of ingress filtering, the single and most simple measure in defence of many kinds of attacks against many services in the Internet. So please add to Section 9 another strong recommendation for adherence to RFC 2827 and RFC 3013, and add BCP 84, RFC 3704, to the list of fundamental references for this topic. (12) Section 10 -- editorial in the 3rd paragraph, the comma is inappropriate and should be replaced by a semicolon (or a full-stop): This document directly impacts the security of the Domain Name System, implementers are urged to follow its recommendations. --- This document directly impacts the security of the Domain Name System; implementers are urged to follow its recommendations. or: This document directly impacts the security of the Domain Name System. Implementers are urged to follow its recommendations. (13) Section 12 Apparently, not all references listed there are truly Normative. So please split off this section in Normative and Informative. In particular, references - [RFC2821], - [RFC3833], and - [vu-457875] are clearly Informative. I personally would also demote - [RFC2401] (or better: [RFC4301] -- see above), - [RFC2845] (and SIG(0) mentioned by others as missing), - [RFC2827], and - [RFC3013] to Informative. (14) Further Reference Finally, I suggest adding an Informative Reference to for practices for source port randomization (already close to WGLC, if I recall things the right way). Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End of forwarded message from Alfred HÎnes ----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 28 08:33:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA53C3A6CCC; Fri, 28 Mar 2008 08:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.677 X-Spam-Level: **** X-Spam-Status: No, score=4.677 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, 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 ORi-VcFESoQo; Fri, 28 Mar 2008 08:33:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F101E3A6D20; Fri, 28 Mar 2008 08:31:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JfGNI-000BVB-7h for namedroppers-data@psg.com; Fri, 28 Mar 2008 15:20:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JfGN7-000BTO-D3 for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 15:20:06 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m2SFJsfs038039 for ; Fri, 28 Mar 2008 11:19:55 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m2SFJs0J038038 for namedroppers@ops.ietf.org; Fri, 28 Mar 2008 11:19:54 -0400 (EDT) (envelope-from namedroppers) Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeyGZ-0008KA-SL for namedroppers@ops.ietf.org; Thu, 27 Mar 2008 20:00:06 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA241267979; Thu, 27 Mar 2008 20:59:40 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA28655; Thu, 27 Mar 2008 20:59:38 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200803271959.UAA28655@TR-Sys.de> Subject: draft-ietf-dnsext-rfc2672bis-dname-11 -- fate of 2672 ?? To: scottr@nist.gov, wouter@nlnetlabs.nl Date: Thu, 27 Mar 2008 20:59:37 +0100 (MEZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1206717595-32751-10" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is a multi-part message in MIME format... ------------=_1206717595-32751-10 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Content-Disposition: inline [ 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 all, After reconsidering the latest revision of the DNAME-bis draft, I wanted to figure out the real fate of RFC 2672. Currently, the front matter of I-D.dnsext-rfc2672bis-dname-11 says: Updates: 2672,... This means, anybody interested in DNAME has to consult RFC 2672 and the new RFC (once published), and hence has to find out which parts of RFC 2672 have been revised by 2672bis and which are still valid. I tried, based on the current draft, and I lamentably failed, caught in a tangling web of text. Apparently, almost all significant parts of RFC 2672 are revised or effectively superseded by text somewhere in 2672bis. This is a very confusing scenario. To avoid sustained confusion and endless discussions on the proper exegesis of both documents, IMO the only clean and clear solution will be to formally obsolete RFC 2672 by 2672bis. According to my attempt to figure out the 'surviving' text in RFC 2672, it looks like only section 2.1 of 2672bis should be slightly amended to give a complete description of the 'static' aspects of the DNAME RR. All 'dynamic' aspects, processing rules, etc., apparently already are fully covered by 2672bis. To the contrary, obsoleting RFC 2672 will allow to simplify some parts of the text, e.g. dropping Section 2.6 entirely. (I leave it as an exercise to pick up further redundant text.) Finally, as a subsidiary measure, the IANA Considerations have to be adapted slightly as well. So what's to do? (1) Change the front matter Updates: 2672,3363,4294 (if approved) --- Obsoletes: 2672 (if approved) Updates: 3363,4294 (if approved) (2) Update Section 2.1 For details, see below. (3) Delete Section 2.5 (4) Adjust Section 6 For details, see below. ==== Details for step (2) ==== I have tried to compile a slightly revised version of Section 2.1 for inclusion into 2672bis, accommodating all the wisdom accrued in my lazy brain on required precision in terminology and possible pitfalls -- but this is probably condemned to incompleteness. As such, everybody is invited to add more content and precision if deemed necessary. For quick reference, here's the current Section 2.1 of 2672bis: ---- snip ---- 2. The DNAME Resource Record 2.1. Format The DNAME RR has mnemonic DNAME and type code 39 (decimal). The format of the DNAME record has not changed from the original specification in RFC 2672. DNAME has the following format: DNAME The format is not class-sensitive. All fields are required. The RDATA field target is a domain name. The RDATA field target name MUST be sent uncompressed [RFC3597]. The DNAME RR causes type NS additional section processing. ---- snip ---- Below I present two variants for the proposed revision of this text, after first giving the detailed considerations that lead these proposals. Since the 'core' specification of a RR type has to include hints to required processing by authoritative servers, the final sentence above is present and should be retained. Nevertheless, it does not fit properly under the headline "Format". This text also has to be amended by more clauses defining the basic properties of the DNAME RR, which have been adapted from RFC 2672. Therefore, I propose to change the headline to "Basic Specification". The first and last (single-line) paragraph above are left unchanged. To allow obsoleting RFC 2672, the (potentially normative) reference to the predecessor has been elided. The terminological distinction between presentation format and binary (on-the-wire) format of the RR has been emphasized. To my knowledge, the owner field of all DNS RRs is covered by the general rules for DNS labels and their concatenation (RFC 1034/1035 plus updates). The current draft text seems to be too much focussed on the 'standard' label format. To allow for future extensibility (binary / extended label types, etc.) and avoid possible normative text clashes, I suggest to avoid restating too much details already normatively specified in other documents. Nevertheless, I offer two variants to choose from, depending on the weight given to this 'avoid restatement' argument: - The long form specifies the whole RR, and inevitably contains significant repetitions from other RFCs. - The short form restricts itself to only defining the type code and mnemonic, and the RDATA portion of the DNAME RR, the only parts left unspecified by existing standards. ---- snip (begin long form) ---- 2. The DNAME Resource Record 2.1. Basic Specification The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is not class-sensitive. The presentation format of the DNAME resource record is: DNAME This format follows the general rules of Sections 3.6 and 3.6.1 of RFC 1034 [RFC1034]; in particular: - all fields are required, unless , , and can be implicitely derived in the context of a zone file, according to the rules in RFC 1034; - the owner name is formatted following the standard rules, which imply case-insensitivity for 'text' format labels; - the class and RR type mnemonics are case-sensitive. The only RDATA field is a fully qualified domain name, and its presentation also follows the applicable standard rules for domain names [RFC1034] [RFC1035] [RFC4343]. The binary (on-the-wire) format of the DNAME RR follows Section 3.2.1 of RFC 1035 [RFC1035]. The RDATA field MUST contain the target name in uncompressed form [RFC3597]. The effect of the DNAME RR is the substitution of the record's for its owner name, as a suffix of a domain name. This substitution has to be applied for every DNAME RR found in the resolution process, which allows fairly lenghty valid chains of DNAME RRs. Details of the substitution process, methods to avoid conflicting resource records, and rules for specific corner cases are given in the following subsections. The DNAME RR causes type NS additional section processing. ---- snip (end long form) ---- ---- snip (begin short form) ---- 2. The DNAME Resource Record 2.1. Basic Specification The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is not class-sensitive. Its RDATA is comprised of a single field, , which contains a fully qualified domain name that must be sent in uncompressed form [RFC1035], [RFC3597]. The presentation format of is that of a domain name [RFC1034]. The effect of the DNAME RR is the substitution of the record's for its owner name, as a suffix of a domain name. This substitution has to be applied for every DNAME RR found in the resolution process, which allows fairly lenghty valid chains of DNAME RRs. Details of the substitution process, methods to avoid conflicting resource records, and rules for specific corner cases are given in the following subsections. The DNAME RR causes type NS additional section processing. ---- snip (end short form) ---- ==== Details for step (4) ==== I suggest the following change to the first paragraph of the IANA Considerations (Section 6): The main purpose of this draft is to discuss issues related to the use of DNAME RRs in a DNS zone. The original document registered the DNAME Resource Record type code 39 (decimal). IANA should update the DNS resource record registry by adding a pointer to this document for RR type 39. --- The DNAME Resource Record type code 39 (decimal) originally has been registered by [RFC2672]. IANA should update the DNS resource record registry to point to this document for RR type 39. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ------------=_1206717595-32751-10 Content-Type: text/plain; name="SpamAssassinReport.txt" Content-Disposition: inline; filename="SpamAssassinReport.txt" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Spam detection software, running on the system "mail.ogud.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: [ 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. ] [...] Content analysis details: (3.0 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.4 HEADER_SPAM Bulk email fingerprint (header-based) found 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS -1.4 AWL AWL: From: address is in the auto white-list ------------=_1206717595-32751-10-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From LincolncommonwealthKey@craigslist.org Fri Mar 28 15:33:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EE53A709A; Fri, 28 Mar 2008 15:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.025 X-Spam-Level: X-Spam-Status: No, score=-18.025 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_ROLEX=5, HELO_EQ_IT=0.635, HOST_MISMATCH_NET=0.311, LOW_PRICE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_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 iJ03M6FH6yF9; Fri, 28 Mar 2008 15:33:46 -0700 (PDT) Received: from ivyf1871c414fd.fastwebnet.it (213-156-49-133.fastres.net [213.156.49.133]) by core3.amsl.com (Postfix) with SMTP id CE6553A708E; Fri, 28 Mar 2008 15:32:04 -0700 (PDT) Received: from 12101016954311880.18956878605438045.15260986524512888.13534368238889684 (HELO localhost.localdomain) (16922726845183183.16076288940804308.17109654253748561.12355933771000604) by 12261957284997426.13353623803637863.15381041555934746.12270063048098965 with SMTP; Fri, 28 Mar 2008 23:31:29 -0100 Date: Fri, 28 Mar 2008 23:31:29 -0100 Message-Id: <5IX216EJXVWDA363@craigslist.org> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 815646 X-Header-Versions: Hewlett-Packard.8t7bn6nd6.fk@us.newsgram.hp.com X-FID: 60E07DBC-1405-34AF-B2E6-32CDEA42DCB3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: , , , , From: "Jame Bentley" Subject: Lowest Price Guaranteed X-Antivirus: avast! (VPS 080328-0, 28/03/2008), Outbound message X-Antivirus-Status: Clean High Quality Watches & Products from an offical of prestige USA and Swiss watches manufacturers! http://velarpunjoyed.com/ Rolex Timepieces on Sale!!