From EsmeraldaschottkyVera@genzyme.com Fri Feb 1 00:05: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 8AA7E3A6875; Fri, 1 Feb 2008 00:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 23.631 X-Spam-Level: *********************** X-Spam-Status: Yes, score=23.631 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_06_12=1.069, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_NET=0.611, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RMML_Stock7=1.64, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.6 SARE_RMML_Stock7 BODY: SARE_RMML_Stock7 * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [205.162.223.208 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 0.6 HELO_MISMATCH_NET HELO_MISMATCH_NET * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PweQEBuSxVKz; Fri, 1 Feb 2008 00:05:29 -0800 (PST) Received: from altay.shcek.gov.tr (unknown [88.225.212.83]) by core3.amsl.com (Postfix) with SMTP id E5D663A6813; Fri, 1 Feb 2008 00:05:27 -0800 (PST) Message-ID: 292bc01c864a9$6d3a3140$b8083f0a@altay From: "Sofia Shipley" To: Subject: ***SPAM*** 23.631 (5) Next big market winner Date: Fri, 1 Feb 2008 10:06:52 -0200 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.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 No Looking back on G&S minerals Symbol-GSML Up 4 consecutive days for over 40% in profits and record volume Read the PR, the good news keeps coming. Add GSML to your Radar and watch it like a hawk. This company is going to $3. even if it hits half of projected forcast it would be a phenomenal 1000% profit. No other stock can deliver that in times like this Get in on GSML G&S minerals INC. From LoraineappellateVillalobos@wikipedia.org Fri Feb 1 00:11: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 2DE283A686B; Fri, 1 Feb 2008 00:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 20.158 X-Spam-Level: ******************** X-Spam-Status: Yes, score=20.158 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HOST_EQ_IT HOST_EQ_IT * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.6 HELO_EQ_IT HELO_EQ_IT * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [213.140.6.116 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [213.140.6.116 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRJlv-NX79nP; Fri, 1 Feb 2008 00:11:07 -0800 (PST) Received: from luca.fastwebnet.it (213-140-6-116.ip.fastwebnet.it [213.140.6.116]) by core3.amsl.com (Postfix) with SMTP id 186563A6863; Fri, 1 Feb 2008 00:11:05 -0800 (PST) Message-ID: From: "Avis Coon" To: Cc: , " =20
We told you to keep = watching, G &=20 S Minerals... Symol : GSML

Gold is reaching = record of $1000/=20 oz ... GSML is the undiscovered gem you should be invested=20 in.

Up 4 straight days with = record=20 volume

If you missed the move = from .13 to .17=20 dont dispair they have not even scratched the surfact.

This company is going to=20 $3.00

So grab yourself = some GSML and=20 earn easy 10 bagger

------=_NextPart_000_B4D5_01C864AA.35892F20-- From owner-namedroppers@ops.ietf.org Fri Feb 1 00:13: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 302643A6863; Fri, 1 Feb 2008 00:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXNkfN1dflyx; Fri, 1 Feb 2008 00:13:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 40CF93A6813; Fri, 1 Feb 2008 00:13:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKqtd-000L8w-GN for namedroppers-data@psg.com; Fri, 01 Feb 2008 08:05: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 1JKqta-000L8M-G0 for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 08:05:12 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m11850l5061908; Fri, 1 Feb 2008 09:05:01 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47A2D2AC.4050609@nlnetlabs.nl> Date: Fri, 01 Feb 2008 09:05:00 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Kevin Darcy CC: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> In-Reply-To: <47A28F95.3020706@chrysler.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 01 Feb 2008 09:05:01 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Darcy wrote: | Danny Mayer wrote: |> There are many solutions to improving the design of the architected or |> mis-architected configuration, but the protocol needs to work for all |> situations including this one. So setting the TC bit is the correct |> answer. I agree with Danny. | Non sequitur. The protocol "works" whether TC is clear or not: if it's | clear, the client takes the answer as it finds it and queries the | "missing" NS records as necessary; if TC is set, then the client | (typically) will retry the query using TCP, thus obtaining the answer | and all of the NS records that wouldn't fit in the initial response. Well, your use of the protocol works without the NS records. The DNS is robust. The DNS protocol as widely used, needs those NS records to help resolvers find nameservers more efficiently. So what is querying for the SOA record that cannot retry with TCP? (This is your local subnet, so speed is not that much of a problem?) Can you deploy EDNS? That is the other obvious solution. | The main question is whether an implementation which sets TC under these | circumstances conforms to RFC 2181. A follow-on question would be | whether RFC 2181 needs to be amended for situations such as this one. What is the problem with a TC bit on a SOA answer? I am guessing 140 records may fit in an EDNS answer even (if the names compress well, name your domain controllers a.domaincontroller.local to zz.domaincontroller.local). Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHotKskDLqNwOhpPgRApOsAJ0W7+qb3tA2dAgqSr8ktNigJr9mzgCfXZbt lUhD9El6Jpo3epCKJ0FaDXg= =ZD4P -----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 jqoww@weber.edu Fri Feb 1 00:25: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 9211D3A68A9 for ; Fri, 1 Feb 2008 00:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 114.128 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=114.128 tagged_above=-999 required=5 tests=[AWL=-3.001, BAYES_99=3.5, FB_PENIS=1.66, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_BIG_REASON=10.357, FM_DDDD_TIMES_2=1.999, FRT_PENIS1=3.592, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_3=0.001, J_CHICKENPOX_31=0.6, MANGLED_ENLARG=2.3, MANGLED_ENLGMN=5, MANGLED_PENIS=2.3, NORMAL_HTTP_TO_IP=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_FORGED_WROTE=2.523, RCVD_FORGED_WROTE2=4.325, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADLTOBFU=0.68, SARE_ADLTSUB1=1.66, SARE_HTML_A_BODY=0.742, SARE_SUB_PROVEN=0.618, SUBJECT_FUZZY_PENIS=3.096, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.6 SARE_SUB_PROVEN subject has likely spammer phrase or word * 1.7 SARE_ADLTSUB1 Contains OBFU and "strong" adult words * 3.1 SUBJECT_FUZZY_PENIS Attempt to obfuscate words in Subject: * 4.3 RCVD_FORGED_WROTE2 RCVD_FORGED_WROTE2 * 2.5 RCVD_FORGED_WROTE Forged 'Received' header found ('wrote:' spam) * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.7 SARE_ADLTOBFU BODY: Contains OBFU adult material * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 5.0 MANGLED_ENLGMN BODY: mangled enlargement * 1.7 FB_PENIS BODY: FB_PENIS * 2.3 MANGLED_ENLARG BODY: mangled enlarge(r|s) * 0.6 J_CHICKENPOX_31 BODY: 3alpha-pock-1alpha * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.6 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.7 SARE_HTML_A_BODY FULL: Message body has very strange HTML sequence * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: domizu.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: domizu.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: domizu.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: domizu.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: domizu.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [65.31.45.66 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [65.31.45.66 listed in dnsbl.sorbs.net] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.0 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image * 10 FM_BIG_REASON Lot's of CAP words, BIG, REASON, BEST * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * -3.0 AWL AWL: From: address is in the auto white-list Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzZX6kqhUyqw for ; Fri, 1 Feb 2008 00:25:21 -0800 (PST) Received: from cpe-65-31-45-66.woh.res.rr.com (cpe-65-31-45-66.woh.res.rr.com [65.31.45.66]) by core3.amsl.com (Postfix) with SMTP id 8C0083A68A2 for ; Fri, 1 Feb 2008 00:24:53 -0800 (PST) Received: from 137.190.12.80 (HELO fielding3.weber.edu) by ietf.org with esmtp (FAVKNVDXVSWU QQTGD) id awWfzW-tlEjyv-11 for dnsext-archive@ietf.org; Fri, 01 Feb 2008 03:26:23 -0500 Message-ID: <822d01c864ac$21786530$422d1f41@Guillermo> From: "Guillermo Bowen" To: "Laurence Daniel" Subject: ***SPAM*** 114.128 (5) Proven effect for your pen!s enlargement Date: Fri, 01 Feb 2008 03:26:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_33323_8295_01C86482.38A25D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 This is a multi-part message in MIME format. ------=_NextPart_33323_8295_01C86482.38A25D30 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your pen!s grows into the biggest, thickest, hardest, and most powerfu= l tool=20 you`ve ever imagined - the one you`ve constantly wanted about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - THE BEST}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PEN|S OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! TRY IS TODAY TO MAKE YOUR PEN|S BIGGER AND HARDER IN THIS YEAR! http://domizu=2Ecom/ Armed with a theory that perceptions count for everything, andcameras to = admit defeat=2E His face looks worn, haggard, dismayed=2E TheA lesser mor= tal might have been tempted to open a bottle of champagne, Wednesday, 2:15 PMExplaining his moves before Black Wednesday, Soros told= Kaletsky: ------=_NextPart_33323_8295_01C86482.38A25D30 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
#1 DOCTOR RECOMMENDED PEN|S EN'L@RGEMENT = FORMULA!

In = just a few short weeks, you`ll watch with amazement as your pen!s
grows into the biggest, thickest, hardest, and most powerf= ul tool
you`ve ever imagined - the one you`ve constantly wanted about=
having! No pen!s en`l@rgement system is faster, easier to use, or more effective than VPXL+ - THE BEST!

VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PEN|S OR YOUR MONEY BACK= - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARGE TODAY!

TRY IS TODAY TO MAKE YOUR PEN|S BIGGER AND HARDER IN = THIS YEAR!


interest rates are frozen in place=2E The Germans are not = about to offerThe pound fails to respond=2E
the head of the Bundesbank= , gave which was published in The WallArmed with a theory that perception= s count for everything, and
cameras to admit defeat=2E His face looks = worn, haggard, dismayed=2E TheA lesser mortal might have been tempted to = open a bottle of champagne,
Wednesday, 2:15 PMExplaining his moves bef= ore Black Wednesday, Soros told Kaletsky: ------=_NextPart_33323_8295_01C86482.38A25D30-- From MallorytestifyRagland@cbsnews.com Fri Feb 1 00:31: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 091873A689E; Fri, 1 Feb 2008 00:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 21.379 X-Spam-Level: ********************* X-Spam-Status: Yes, score=21.379 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_03_06=0.274, DOS_OE_TO_MX=2.75, FORGED_MUA_OUTLOOK=3.116, HELO_LH_HOME=3.714, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, SARE_MLH_Stock7=1.66] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 3.7 HELO_LH_HOME HELO_LH_HOME * 1.7 SARE_MLH_Stock7 Various common stock subjects * 0.3 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [87.202.4.135 listed in zen.spamhaus.org] * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBKBEjAhFmzM; Fri, 1 Feb 2008 00:31:32 -0800 (PST) Received: from lacayihaqgqzkjc.lan (athedsl-01151.home.otenet.gr [87.202.4.135]) by core3.amsl.com (Postfix) with SMTP id 02FB03A6893; Fri, 1 Feb 2008 00:31:29 -0800 (PST) Message-ID: <1db8101c864ad$14a84130$4001a8c0@lacayihaqgqzkjc> From: "Lakisha Ragland" To: , " =20
We told you to keep = watching, G &=20 S Minerals... Symol : GSML

Gold is reaching = record of $1000/=20 oz ... GSML is the undiscovered gem you should be invested=20 in.

Up 4 straight days with = record=20 volume

If you missed the move = from .13 to .17=20 dont dispair they have not even scratched the surfact.

This company is going to=20 $3.00

So grab yourself = some GSML and=20 earn easy 10 bagger

------=_NextPart_000_1DB7D_01C864AD.14A84130-- From moseh-shinuray@allanaindia.com Fri Feb 1 02:03: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 2CD3F3A68F3 for ; Fri, 1 Feb 2008 02:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 97.89 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=97.89 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_EQ_FR=0.35, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MANGLED_DICK=2.3, 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, 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] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.3 HELO_EQ_FR HELO_EQ_FR * 1.9 FH_HOST_ALMOST_IP The host almost looks like an IP addr. * 1.4 HOST_EQ_MODEMCABLE HOST_EQ_MODEMCABLE * 5.4 FH_HELO_ALMOST_IP Helo is almost an IP addr. * 0.8 HELO_EQ_MODEMCABLE HELO_EQ_MODEMCABLE * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 2.3 MANGLED_DICK BODY: mangled dick * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: oatings.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: oatings.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: oatings.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: oatings.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: oatings.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: oatings.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: oatings.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [89.3.164.39 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg-GDAGOSPXL for ; Fri, 1 Feb 2008 02:03:07 -0800 (PST) Received: from ip-39.net-89-3-164.rev.numericable.fr (ip-39.net-89-3-164.rev.numericable.fr [89.3.164.39]) by core3.amsl.com (Postfix) with ESMTP id 23CD43A68D9 for ; Fri, 1 Feb 2008 02:03:06 -0800 (PST) Message-ID: <000701c864b9$ebaab620$27a40359@mr1df6dbfa1d88> From: "moseh saranteas" To: dnsext-archive@lists.ietf.org Subject: ***SPAM*** 97.89 (5) Make her dreams come true, fulfil her greatest desires with your new big d1ck Date: Fri, 1 Feb 2008 11:05:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C864C2.4D6F1E20" 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 X-Antivirus: avast! (VPS 080201-0, 01/02/2008), Outbound message X-Antivirus-Status: Clean ----------=_NextPart_000_0003_01C864C2.4D6F1E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A revolutionary medical discovery has been made Find out more here ----------=_NextPart_000_0003_01C864C2.4D6F1E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A revolutionary medical discovery = has been=20 made Find out more here ----------=_NextPart_000_0003_01C864C2.4D6F1E20-- From Schuylo-upsoktip@LOOF.COM Fri Feb 1 02:11: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 177723A6892 for ; Fri, 1 Feb 2008 02:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 95.691 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=95.691 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_PENIS=1.66, FRT_PENIS1=3.592, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HTML_MESSAGE=1, J_CHICKENPOX_13=0.6, MANGLED_PENIS=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 2.3 MANGLED_PENIS BODY: mangled - Penis * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 1.7 FB_PENIS BODY: FB_PENIS * 0.6 J_CHICKENPOX_13 BODY: 1alpha-pock-3alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tueesnan.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tueesnan.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tueesnan.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tueesnan.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tueesnan.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tueesnan.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tueesnan.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server * [195.158.108.128 listed in dnsbl.sorbs.net] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KodQANiN26Sx for ; Fri, 1 Feb 2008 02:11:00 -0800 (PST) Received: from adsl4p128.access.maltanet.net (adsl4p128.access.maltanet.net [195.158.108.128]) by core3.amsl.com (Postfix) with ESMTP id 969583A686F for ; Fri, 1 Feb 2008 02:10:59 -0800 (PST) Message-ID: <000c01c864ba$f7e5db30$806c9ec3@lukepc> From: "Schuylo Ferreira" To: dnsext-archive@ietf.org Subject: ***SPAM*** 95.691 (5) Real Men have Real Big Dcks, are you a Real Man? Date: Fri, 1 Feb 2008 11:12:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C864C3.59AA4330" 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 ----------=_NextPart_000_0008_01C864C3.59AA4330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Want to make your p3nis long and thick? click here ----------=_NextPart_000_0008_01C864C3.59AA4330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Want to make your p3nis long and = thick? click=20 here ----------=_NextPart_000_0008_01C864C3.59AA4330-- From Joyce93@cgpbooks.co.uk Fri Feb 1 02:20: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 4897B3A68B5; Fri, 1 Feb 2008 02:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 15.089 X-Spam-Level: *************** X-Spam-Status: Yes, score=15.089 tagged_above=-999 required=5 tests=[BAYES_80=2, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_65=0.6, 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_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.6 J_CHICKENPOX_65 BODY: 6alpha-pock-5alpha * 2.0 BAYES_80 BODY: Bayesian spam probability is 80 to 95% * [score: 0.8759] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [78.166.141.6 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.7 HELO_MISMATCH_UK HELO_MISMATCH_UK * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4qDOE7i5f7S; Fri, 1 Feb 2008 02:20:27 -0800 (PST) Received: from cgpbooks.co.uk (unknown [78.166.141.6]) by core3.amsl.com (Postfix) with SMTP id ACC633A686F; Fri, 1 Feb 2008 02:20:24 -0800 (PST) Message-ID: <001c01c864cd$17778040$00ac95c4@windowsxp> From: "Jim Anderson" To: "dnsext-archive" Subject: ***SPAM*** 15.089 (5) Representative job available Date: Fri, 1 Feb 2008 12:22:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.1409 Hello. My name is Jim Anderson, I represent Jorque Development Inc. company. Jorque Development Inc. mainly develops securely web databases for USA companies and we are seekeing for representative for administrative/representative job in USA. We need representatives in USA for full and part-time jobs (2 positions are available). We do not ask for any money, we are reputable company operating in Netherlands. Job benefits: - 5000 USD guaranteed monthly income for full-time job - 3500 USD guaranteed monthly income for part-time job - Comprehensive medical and life insurance for you and your dependents. You - will be receiving the Jorque Development Inc. Medicine card and all the paperwork in 2 weeks after successfully completing your probation period. GENERAL REQUIREMENTS: - You have to be honest,loyal, responsible and hard-working. - You have to comply with all reasonable and lawful instructions provided to - You by our company. - Minimal 5-7 hours during the week for communication, this work is considered to be homework and shall take no more then 2-3 hrs a day. - Computer w/internet connection. We do not ask any money and the job is 100% legal. Please, reply to support@jorquedevelopment.com if you are interested and company manager will contact you shortly with job details. Thanks Jim Anderson Jorque Development Inc. From Riddle38@roswell.oilfield.slb.com Fri Feb 1 02:24: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 6C8813A68EE; Fri, 1 Feb 2008 02:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 15.089 X-Spam-Level: *************** X-Spam-Status: Yes, score=15.089 tagged_above=-999 required=5 tests=[BAYES_80=2, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_65=0.6, 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_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.6 J_CHICKENPOX_65 BODY: 6alpha-pock-5alpha * 2.0 BAYES_80 BODY: Bayesian spam probability is 80 to 95% * [score: 0.8759] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [78.166.141.6 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.7 HELO_MISMATCH_UK HELO_MISMATCH_UK * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cyox1l9v4UL; Fri, 1 Feb 2008 02:24:48 -0800 (PST) Received: from momhouse123.socal.rr.com (cpe-76-174-7-49.socal.res.rr.com [76.174.7.49]) by core3.amsl.com (Postfix) with SMTP id 338123A68B5; Fri, 1 Feb 2008 02:24:46 -0800 (PST) Message-ID: <001401c86479$d52e4960$0190ccd4@momhouse123> From: "Jim Anderson" To: "dnsext-archive" Subject: ***SPAM*** 15.089 (5) Seeking for representative in USA Date: Fri, 1 Feb 2008 02:26:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2963 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.2963 Hello. My name is Jim Anderson, I represent Jorque Development Inc. company. Jorque Development Inc. mainly develops securely web databases for USA companies and we are seekeing for representative for administrative/representative job in USA. We need representatives in USA for full and part-time jobs (2 positions are available). We do not ask for any money, we are reputable company operating in Netherlands. Job benefits: - 5000 USD guaranteed monthly income for full-time job - 3500 USD guaranteed monthly income for part-time job - Comprehensive medical and life insurance for you and your dependents. You - will be receiving the Jorque Development Inc. Medicine card and all the paperwork in 2 weeks after successfully completing your probation period. GENERAL REQUIREMENTS: - You have to be honest,loyal, responsible and hard-working. - You have to comply with all reasonable and lawful instructions provided to - You by our company. - Minimal 5-7 hours during the week for communication, this work is considered to be homework and shall take no more then 2-3 hrs a day. - Computer w/internet connection. We do not ask any money and the job is 100% legal. Please, reply to support@jorquedevelopment.com if you are interested and company manager will contact you shortly with job details. Thanks Jim Anderson Jorque Development Inc. From owner-namedroppers@ops.ietf.org Fri Feb 1 03:05: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 48F8E3A6937; Fri, 1 Feb 2008 03:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52q7FXvepJdp; Fri, 1 Feb 2008 03:05:09 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 840873A68D9; Fri, 1 Feb 2008 03:05:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKtcO-000FUJ-2E for namedroppers-data@psg.com; Fri, 01 Feb 2008 10:59:36 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKtcL-000FTy-4T for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 10:59:34 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id D02881C00F8; Fri, 1 Feb 2008 11:59:31 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CB46E1C00F4; Fri, 1 Feb 2008 11:59:31 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id BDF7E58EB6A; Fri, 1 Feb 2008 11:59:31 +0100 (CET) Date: Fri, 1 Feb 2008 11:59:31 +0100 From: Stephane Bortzmeyer To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) Message-ID: <20080201105931.GC15412@nic.fr> References: <479FBDD3.4030206@chrysler.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <479FBDD3.4030206@chrysler.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-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 Tue, Jan 29, 2008 at 06:59:15PM -0500, Kevin Darcy wrote a message of 31 lines which said: > So, if an authoritative nameserver responds to a QTYPE=SOA query, > with the SOA RR in the Answer Section, but cannot fit all of the > apex NS records of the zone into the Authority Section, should it > set TC or not? IMHO, yes, strong YES. Doing otherwise would violate the atomicity of the NS RRset. I admit I was not able to find text in an RFC about this atomicity (RFC 2181, 5.1, only talks about the Answer section). Somehting to add to the "profile" document? Thou MUST NOT split a RRset *or* set TC if you do? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From cjyoujsd@yahoo.com.cn Fri Feb 1 03:25: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 38FAE3A68EE for ; Fri, 1 Feb 2008 03:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 92.056 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=92.056 tagged_above=-999 required=5 tests=[BAYES_99=3.5, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HS_INDEX_PARAM=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_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SUB_ENC_ISO2022JP=0.413, SARE_URI_DIGITS4=0.415, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HELO_EQ_JP HELO_EQ_JP * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 HELO_EQ_NE_JP HELO_EQ_NE_JP * 0.4 SARE_SUB_ENC_ISO2022JP Subject specifies display in non-English lang * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * 1.9 RCVD_ILLEGAL_IP Received: contains illegal IP address * 0.0 HS_INDEX_PARAM URI: Link contains a common tracker pattern. * 0.4 SARE_URI_DIGITS4 URI: References a multi-digit domain * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: 78587.net] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 78587.net] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 78587.net] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: 78587.net] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: 78587.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [123.165.121.212 listed in zen.spamhaus.org] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 78587.net] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.5 FROM_EXCESS_BASE64 From: base64 encoded unnecessarily Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ7dwDLFO-A7 for ; Fri, 1 Feb 2008 03:25:39 -0800 (PST) Received: from a-net.ne.jp (unknown [123.165.126.25]) by core3.amsl.com (Postfix) with ESMTP id 066A73A6869 for ; Fri, 1 Feb 2008 03:25:37 -0800 (PST) Received: from quffibebhv3 (unknown [53.186.147.133]) by smtp37 (Coremail) with SMTP id kvEDvC7A6gDDHm06.1 for ; Thu, 01 Feb 2007 19:11:50 +0800 (CST) X-Originating-IP: [53.186.147.133] Subject: ***SPAM*** 92.056 (5) =?iso-2022-jp?B?GyRCIickNEVQTz89YEh3JCw9UE1oJF4kNyQ/GyhC?= From: =?shift-jis?B?Y2p4dmZpZWpmcg==?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Message-Id: <20080201112538.066A73A6869@core3.amsl.com> Date: Fri, 1 Feb 2008 03:25:37 -0800 (PST) $B$4EPO?=`Hw$,=PMh$^$7$?!#(B $B2<5-(BURL$B$h$j!"L5NA2q0wEPO?$r$*:Q$^$;$/$@$5$$!#(B http://78587.net/h/?gbbsp $B$J$*!"(B24$B;~4V0JFb$K$4EPO?$,$J$$>l9g!"L5NA2q0wEPO?;q3J$O%-%c%s%;%k$H$5$;$F$$$?$@$-$^$9$N$G$4Cm0U$/$@$5$$!#(B $B(#(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B("(B $BG[?.Dd;_$O%3%A%i$^$G!#(B $B("(B DeliveryStop $B("(B info@mjeh.suroot.com $B("(B $B("!ZG[?.Dd;_$K!VG[?.Dd;_!W$H$*=q$-2<$5$$!#(B $B("7oL>$K!VG[?.Dd;_!W$H5-:\$5$l$F$$$J$$>l9g$O=hM}$,9T$($^$;$s!#(B $B(">0!"Dd;_$K$O?tF|4V$[$I$*;~4V$r$$$?$@$/>l9g$,$4$6$$$^$9!#(B $B("Dd;_$^$G?tF|!"?t2s%a!<%k$,Aw?.$5$l$k$3$H$,$4$6$$$^$9$,!"(B $B("2?B4$4N;>5$/$@$5$$!#(B $B(&(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B From JanellMcelroy@nujournal.net Fri Feb 1 03:40: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 636A93A67CF for ; Fri, 1 Feb 2008 03:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 89.839 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=89.839 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, DATE_IN_PAST_12_24=0.992, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_NET=0.611, INVALID_MSGID=1.9, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 1.0 DATE_IN_PAST_12_24 Date: is 12 to 24 hours before Received: date * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 0.0 BODY_ENHANCEMENT2 BODY: Information on getting larger body parts * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tunborr.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [189.135.252.174 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tunborr.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tunborr.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [189.135.252.174 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 0.6 HELO_MISMATCH_NET HELO_MISMATCH_NET * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I8KTN5z18U1 for ; Fri, 1 Feb 2008 03:40:20 -0800 (PST) Received: from impresoras.gateway.2wire.net (unknown [189.135.252.174]) by core3.amsl.com (Postfix) with SMTP id F2A5C3A6871 for ; Fri, 1 Feb 2008 03:40:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by host71290924.nujournal.net (8.13.1/8.13.1) with SMTP id QUU409Dx22.064847.BYX.M75.7993373304203 for ; Fri, 1 Feb 2008 05:40:16 +0600 Message-ID: 286901c864c7$6bf44820$4001a8c0@impresoras From: "Dr. Janell Mcelroy" To: Subject: ***SPAM*** 89.839 (5) Huge male machine has much more advantages. Date: Fri, 1 Feb 2008 05:40:16 +0600 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 080201-0, 01/02/2008), Outbound message X-Antivirus-Status: Clean Your girlfriend shack up with your mate thats why you are alone. For reason of of his male organ length. Girlfriends like huge shlong. Lengthen your male organ and you'll be popular among chicks for sure. Lots of men the world over have increase. Today its your turn. http://www.tunborr.com From RubenmervinCarr@redhousebooks.com Fri Feb 1 03:45: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 E359C3A6916; Fri, 1 Feb 2008 03:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 21.265 X-Spam-Level: ********************* X-Spam-Status: Yes, score=21.265 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RMML_Stock7=1.64, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 0.9998] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 1.6 SARE_RMML_Stock7 BODY: SARE_RMML_Stock7 * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [213.123.194.158 listed in zen.spamhaus.org] * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdHNwo8jNnA5; Fri, 1 Feb 2008 03:45:23 -0800 (PST) Received: from samcomputer.home (pool-71-188-108-121.cmdnnj.east.verizon.net [71.188.108.121]) by core3.amsl.com (Postfix) with SMTP id 3ED5D3A6842; Fri, 1 Feb 2008 03:45:23 -0800 (PST) Message-ID: 20ba01c192cb$f2fabea0$0401a8c0@SamComputer From: "Franklin Banks" To: Cc: , " X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73173A695F; Fri, 1 Feb 2008 03:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8eC5hcLDMQT; Fri, 1 Feb 2008 03:47:23 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BCB9A3A695E; Fri, 1 Feb 2008 03:47:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKuH9-000KrY-16 for namedroppers-data@psg.com; Fri, 01 Feb 2008 11:41:43 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKuH6-000Kr0-8s for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 11:41:41 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JVK00G015QK6L00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 11:41:38 +0000 (GMT) Received: from [137.43.2.214] by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0JVK00DE35TDAY80@cali.ucd.ie>; Fri, 01 Feb 2008 11:41:38 +0000 (GMT) Date: Fri, 01 Feb 2008 11:42:14 +0000 From: Niall O'Reilly Subject: Re: updated dname draft-08 In-reply-to: To: Niall O'Reilly Cc: Paul Vixie , Wouter Wijngaards , Scott Rose , Namedroppers Message-id: <6D235026-7FD1-43B9-9E48-3A615B867EE8@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: multipart/signed; boundary=Apple-Mail-42-220635678; micalg=pgp-sha1; protocol="application/pgp-signature" Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.2 (Tiger) References: <478B2AE0.2060108@nlnetlabs.nl> <62627.1200324912@sa.vix.com> <478B931D.3080306@nist.gov> <70150.1200334845@sa.vix.com> <478C6B2F.7030407@nlnetlabs.nl> <20323.1200393620@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Apple-Mail-42-220635678 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 15 Jan 2008, at 12:57, Niall O'Reilly wrote: > OTOH, step 3C of the algorithm seems to require an empty > non-terminal to trigger DNAME processing. As everyone was too polite to point out, I misread the passage. Apologies. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 --Apple-Mail-42-220635678 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.1 (Darwin) iD8DBQFHowWbeYfkja6ZXtkRAqwnAJwLT9bLJl8s7ajrSN5srZXhR+S5OgCfUuQd B4b1argGJpHXeBFEhUTNkCA= =Eofh -----END PGP SIGNATURE----- --Apple-Mail-42-220635678-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From FranklincryptAlvarez@femalehealth.com Fri Feb 1 03:49: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 6924C3A67D0; Fri, 1 Feb 2008 03:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 17.363 X-Spam-Level: ***************** X-Spam-Status: Yes, score=17.363 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_06_12=1.069, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [200.119.7.209 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va4pTsBlTnQd; Fri, 1 Feb 2008 03:49:22 -0800 (PST) Received: from diempaques02.diempaques.local (unknown [200.119.7.209]) by core3.amsl.com (Postfix) with SMTP id 6E82128C203; Fri, 1 Feb 2008 03:49:21 -0800 (PST) Message-ID: <0c3f01c864c9$084060a0$3400a8c0@diempaques02> From: "Angel Alvarez" To: , " =20
We told you to keep = watching, G &=20 S Minerals... Symol : GSML

Gold is reaching = record of $1000/=20 oz ... GSML is the undiscovered gem you should be invested=20 in.

Up 4 straight days with = record=20 volume

If you missed the move = from .13 to .17=20 dont dispair they have not even scratched the surfact.

This company is going to=20 $3.00

So grab yourself = some GSML and=20 earn easy 10 bagger

------=_NextPart_000_0C3B_01C864C9.084060A0-- From jramos@apu.edu Fri Feb 1 03:54: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 749B83A6914 for ; Fri, 1 Feb 2008 03:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 104.803 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=104.803 tagged_above=-999 required=5 tests=[AWL=-2.414, BAYES_99=3.5, FB_PENIS=1.66, FRT_PENIS1=3.592, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_3=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_84=0.6, MANGLED_DICK=2.3, MANGLED_ENLARG=2.3, MANGLED_ENLGMN=5, MANGLED_PENIS=2.3, NORMAL_HTTP_TO_IP=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_FORGED_WROTE=2.523, RCVD_FORGED_WROTE2=4.325, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_ADLTOBFU=0.68, SARE_HTML_A_BODY=0.742, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, XMAILER_MIMEOLE_OL_8627E=3.462] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.9 HOST_EQ_PL HOST_EQ_PL * 1.1 HELO_EQ_PL HELO_EQ_PL * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 4.3 RCVD_FORGED_WROTE2 RCVD_FORGED_WROTE2 * 2.5 RCVD_FORGED_WROTE Forged 'Received' header found ('wrote:' spam) * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.7 SARE_ADLTOBFU BODY: Contains OBFU adult material * 0.6 J_CHICKENPOX_84 BODY: 8alpha-pock-4alpha * 2.3 MANGLED_DICK BODY: mangled dick * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 5.0 MANGLED_ENLGMN BODY: mangled enlargement * 1.7 FB_PENIS BODY: FB_PENIS * 2.3 MANGLED_ENLARG BODY: mangled enlarge(r|s) * 0.6 J_CHICKENPOX_31 BODY: 3alpha-pock-1alpha * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.6 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.7 SARE_HTML_A_BODY FULL: Message body has very strange HTML sequence * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: khuttjine.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: khuttjine.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: khuttjine.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [83.20.132.99 listed in zen.spamhaus.org] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [83.20.132.99 listed in dnsbl.sorbs.net] * 0.0 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image * 3.5 XMAILER_MIMEOLE_OL_8627E XMAILER_MIMEOLE_OL_8627E * -2.4 AWL AWL: From: address is in the auto white-list Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm+9UyOwPJcl for ; Fri, 1 Feb 2008 03:54:11 -0800 (PST) Received: from esm99.neoplus.adsl.tpnet.pl (esm99.neoplus.adsl.tpnet.pl [83.20.132.99]) by core3.amsl.com (Postfix) with SMTP id 81D0A3A693B for ; Fri, 1 Feb 2008 03:54:08 -0800 (PST) Received: from 199.184.238.20 (HELO mx1.apu.edu) by lists.ietf.org with esmtp (IQKNIEQVXX HVRRYB) id IY0pTm-NHz96s-j0 for dnsext-archive@lists.ietf.org; Fri, 01 Feb 2008 12:55:48 +0100 Message-ID: <0a1001c864c9$62c65bb0$63841453@Therese> From: "Therese Kyle" To: "Daphne Dodge" Subject: ***SPAM*** 104.803 (5) Gradually your dic'k will grow larger! Date: Fri, 01 Feb 2008 12:55:48 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_2574_0A78_01C864D1.C48AC3B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 This is a multi-part message in MIME format. ------=_NextPart_2574_0A78_01C864D1.C48AC3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your phallus grows into the biggest, thickest, hardest, and most power= ful tool=20 you`ve ever imagined - the one you`ve constantly wanted about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - FOREVER}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PHALLUS OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! CHECK IT OUT NOW TO MAKE YOUR PEN|S BIGGER AND HARDER IN THIS YEAR! http://khuttjine=2Ecom/ also was their final match in the competition, and theZimbabwe won the to= ss and elected to field first=2EScientists discover a microscopic creatur= e that has This victory meant both South Africa and AustraliaSnipes and trained by C= had Frederick=2E Cyberflash's time ------=_NextPart_2574_0A78_01C864D1.C48AC3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MAXIMIZE YOUR GROWTH, PERFORMANCE & STREN= GTH
WITH THIS REVOLUTIONARY PEN|S EN'L@RGEMENT BREAKTHROUGH! <= /FONT>

In = just a few short weeks, you`ll watch with amazement as your phallus
grows into the biggest, thickest, hardest, and most powe= rful tool
you`ve ever imagined - the one you`ve constantly wanted abo= ut
having! No pen!s en`l@rgement system is faster, easier to use, or more effective than VPXL+ - FOREVER!

VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PHALLUS OR YOUR MONEY BA= CK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARGE TODAY!

CHECK IT OUT NOW TO MAKE YOUR PEN|S BIGGER AND HARDER= IN THIS YEAR!


air-purification equipment in the forward section of theMe= mbers of the boy's church were praying for his safe
details are report= ed=2Ealso was their final match in the competition, and the
Zimbabwe w= on the toss and elected to field first=2EScientists discover a microscopi= c creature that has
This victory meant both South Africa and Australia= Snipes and trained by Chad Frederick=2E Cyberflash's time ------=_NextPart_2574_0A78_01C864D1.C48AC3B0-- From Susan-gadulank@Biljax.Com Fri Feb 1 04:14: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 01DA728C138 for ; Fri, 1 Feb 2008 04:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 49.899 X-Spam-Level: ************************************************* X-Spam-Status: Yes, score=49.899 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_06_12=1.897, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ookbast.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ookbast.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [58.175.214.56 listed in dnsbl.sorbs.net] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8MdZo2iqgry for ; Fri, 1 Feb 2008 04:14:12 -0800 (PST) Received: from [58.175.214.56] (unknown [58.175.214.56]) by core3.amsl.com (Postfix) with ESMTP id 6A9453A6937 for ; Fri, 1 Feb 2008 04:13:45 -0800 (PST) Message-ID: <000801c864cc$1e130c90$38d6af3a@yourhf6ioz8zz5> From: "Susan Warnecke" To: dnsext-archive@ietf.org Subject: ***SPAM*** 49.899 (5) Chicks will be AMAZED by your legendary PROWESS. Date: Fri, 1 Feb 2008 22:45:22 +10-30 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0004_01C86524.20A15090" 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 ----------=_NextPart_000_0004_01C86524.20A15090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ensure you do not get left out - get your necessary equipment here. ----------=_NextPart_000_0004_01C86524.20A15090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ensure you do not get left out - get = your=20 necessary equipment here. ----------=_NextPart_000_0004_01C86524.20A15090-- From a-adriev@abz-dv.de Fri Feb 1 04:24: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 D90673A6943; Fri, 1 Feb 2008 04:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 16.353 X-Spam-Level: **************** X-Spam-Status: Yes, score=16.353 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_CHAT_1=5, HELO_EQ_IP_ADDR=1.119, INVALID_DATE=1.245, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 5.0 GB_CHAT_1 BODY: I've already got a girl 1 * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [88.251.251.86 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83ZNJ4LUjYcP; Fri, 1 Feb 2008 04:24:12 -0800 (PST) Received: from [88.251.251.86] (unknown [88.251.251.86]) by core3.amsl.com (Postfix) with ESMTP id 0F3193A6894; Fri, 1 Feb 2008 04:24:08 -0800 (PST) Received: from [88.251.251.86] by mail.abz-dv.de; Fri, 32 Jan 2008 15:00:15 +0200 From: "Eduardo Richards" To: Subject: ***SPAM*** 16.353 (5) Let's chat Date: Fri, 32 Jan 2008 15:00:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QOYSQR19IUM503M85SA35Y3QR4== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <0310fd74$00000005$56fbfb58@a-adriev> Hello! I am bored today. I am nice girl that would like to chat with you. Email me at Camilla@EHealThies.info only, because I am using my friend's email to write this. To see my pics From owner-namedroppers@ops.ietf.org Fri Feb 1 04:56: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 69FF03A6949; Fri, 1 Feb 2008 04:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+8HNoqOkaTh; Fri, 1 Feb 2008 04:56:46 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9FFD93A680E; Fri, 1 Feb 2008 04:56:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKvOT-0006cV-PD for namedroppers-data@psg.com; Fri, 01 Feb 2008 12:53:21 +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 1JKvON-0006Ts-Ch for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 12:53:20 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m11CpBg2026094; Fri, 1 Feb 2008 19:51: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 m11CpO7v005622; Fri, 1 Feb 2008 19:51:33 +0700 (ICT) From: Robert Elz To: mayer@gis.net cc: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) In-Reply-To: <47A2875C.4050801@gis.net> References: <47A2875C.4050801@gis.net> <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Feb 2008 19:51:24 +0700 Message-ID: <2011.1201870284@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Thu, 31 Jan 2008 21:43:40 -0500 From: Danny Mayer Message-ID: <47A2875C.4050801@gis.net> | There are many solutions to improving the design of the architected or | mis-architected configuration, but the protocol needs to work for all | situations including this one. Yes, that is exactly what I think I said in the message you quoted. | So setting the TC bit is the correct answer. No, it isn't - I suspect you're making the same mistake as Stephane Bortzmeyer made, and not really considering the viable choices - see the reply I just sent to him. | If DNS performance is poor as a result, that a matter of fixing | the configuration rather than messing with the protocol. Absolutely. That I agree with. 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 Fri Feb 1 04:58: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 4241C3A6960; Fri, 1 Feb 2008 04:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSUISG6ObSxE; Fri, 1 Feb 2008 04:58:23 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 62C153A6951; Fri, 1 Feb 2008 04:58:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKvLp-00064n-Fs for namedroppers-data@psg.com; Fri, 01 Feb 2008 12:50: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 1JKvLi-00061t-UL for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 12:50:36 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m11ClwVM020662; Fri, 1 Feb 2008 19:47:58 +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 m11CmFrx002654; Fri, 1 Feb 2008 19:48:15 +0700 (ICT) From: Robert Elz To: Stephane Bortzmeyer cc: Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) In-Reply-To: <20080201105931.GC15412@nic.fr> References: <20080201105931.GC15412@nic.fr> <479FBDD3.4030206@chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Feb 2008 19:48:15 +0700 Message-ID: <6012.1201870095@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Fri, 1 Feb 2008 11:59:31 +0100 From: Stephane Bortzmeyer Message-ID: <20080201105931.GC15412@nic.fr> | IMHO, yes, strong YES. Doing otherwise would violate the atomicity of | the NS RRset. No, you're considering the incorrect alternative. That is, you're assuming the choice is between including the SOA in the annswer, incomplete NS RRSet in the auth, and setting TC, and including the SOA in the answer, incomplete NS RRSet in the auth, and TC==0. That's not what is being questioned here, that choice isn't worth asking about, the second alternative is clearly wrong. The actual choice being asked about is a) SOA in answer, incomplete NS RRSet in Auth, TC set b) SOA in answer, nothing in auth, TC==0 Of those, (b) is the better option, and the one 2181 says that servers should implement. (a) also works, but is sub-optimal. That is, in this case, the NS records in the auth section do nothing really useful (beyond priming the cache of the resolver), and the better choice is to omit them, and send the answer the resolver requested without TC, so it isn't forced into a TCP repeat of the query. | I admit I was not able to find text in an RFC about this atomicity | (RFC 2181, 5.1, only talks about the Answer section). Somehting to add | to the "profile" document? Thou MUST NOT split a RRset *or* set TC if | you do? See section 9. 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 Fri Feb 1 05:46: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 C678428C7AF; Fri, 1 Feb 2008 05:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A445aBbCbDKF; Fri, 1 Feb 2008 05:45:33 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4709628E3E9; Fri, 1 Feb 2008 05:21:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKvjh-000AW4-GP for namedroppers-data@psg.com; Fri, 01 Feb 2008 13:15:17 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKvjb-000AVP-Le for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 13:15:16 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id E405A1C00F8; Fri, 1 Feb 2008 14:15:10 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id DFD3F1C0038; Fri, 1 Feb 2008 14:15:10 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D3EE158EB6A; Fri, 1 Feb 2008 14:15:10 +0100 (CET) Date: Fri, 1 Feb 2008 14:15:10 +0100 From: Stephane Bortzmeyer To: "W.C.A. Wijngaards" Cc: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) Message-ID: <20080201131510.GA3626@nic.fr> References: <200801300332.m0U3WnSY062365@drugs.dv.isc.org> <479FF945.7060203@chrysler.com> <47A02563.2040007@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A02563.2040007@nlnetlabs.nl> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-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 Wed, Jan 30, 2008 at 08:21:07AM +0100, W.C.A. Wijngaards wrote a message of 53 lines which said: > Additional section can be partial. RFC number, section and line, please :-) Because I am not so sure. -- to unsubscribe send a message to namedroppers-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 Feb 1 06:47: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 7E89A28C4F9; Fri, 1 Feb 2008 06:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBgYgl5+jooB; Fri, 1 Feb 2008 06:47:02 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A13AA293499; Fri, 1 Feb 2008 06:28:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKwpN-000K6O-0M for namedroppers-data@psg.com; Fri, 01 Feb 2008 14:25: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 1JKwpJ-000K5i-On for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 14:25:11 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m11EOxiL030341; Fri, 1 Feb 2008 15:24:59 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47A32BBB.1060304@nlnetlabs.nl> Date: Fri, 01 Feb 2008 15:24:59 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Namedroppers Subject: Re: Clarification Request (Truncation) References: <200801300332.m0U3WnSY062365@drugs.dv.isc.org> <479FF945.7060203@chrysler.com> <47A02563.2040007@nlnetlabs.nl> <20080201131510.GA3626@nic.fr> In-Reply-To: <20080201131510.GA3626@nic.fr> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 01 Feb 2008 15:24:59 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Bortzmeyer wrote: |> Additional section can be partial. | | RFC number, section and line, please :-) Because I am not so sure. Hmm I think I was wrong, this is not conform RFC. It is indeed not what I send, although it is what I expect to possibly receive... Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHoyu7kDLqNwOhpPgRAs8CAKCvXVLcnALBADQMCKBlCy7hjdRBvACgtbuc DG4VPpzdqg6nscitNI/NjuA= =Z/M4 -----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 Mafkees-gilmarti@123agencyweb.com Fri Feb 1 06:52: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 CFF9228C585 for ; Fri, 1 Feb 2008 06:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 63.73 X-Spam-Level: *************************************************************** X-Spam-Status: Yes, score=63.73 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, J_CHICKENPOX_13=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HOST_EQ_IT HOST_EQ_IT * 0.6 HELO_EQ_IT HELO_EQ_IT * 0.6 J_CHICKENPOX_13 BODY: 1alpha-pock-3alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ohpeoege.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ohpeoege.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: ohpeoege.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: ohpeoege.com] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGC4fb06ybH8 for ; Fri, 1 Feb 2008 06:52:15 -0800 (PST) Received: from host171-120-static.107-82-b.business.telecomitalia.it (host171-120-static.107-82-b.business.telecomitalia.it [82.107.120.171]) by core3.amsl.com (Postfix) with ESMTP id 3213A28D0D4 for ; Fri, 1 Feb 2008 06:30:35 -0800 (PST) Message-ID: <000701c864e0$3a3b0ee0$ab786b52@Server> From: "Mafkees Dovale" To: dnsext-archive@lists.ietf.org Subject: ***SPAM*** 63.73 (5) Always wondered how others could have some big d1cks? Here's the answer. Date: Fri, 1 Feb 2008 15:39:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C864E8.9BFF76E0" 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 ----------=_NextPart_000_0003_01C864E8.9BFF76E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Non-stop action every night - do you have what it takes? ----------=_NextPart_000_0003_01C864E8.9BFF76E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Non-stop action every night - do = you have=20 what it takes? ----------=_NextPart_000_0003_01C864E8.9BFF76E0-- From RobbiecountdownWhitaker@stephenibaraki.com Fri Feb 1 06:57: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 2AD6628C629; Fri, 1 Feb 2008 06:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 17.024 X-Spam-Level: ***************** X-Spam-Status: Yes, score=17.024 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, DOS_OE_TO_MX=2.75, FORGED_MUA_OUTLOOK=3.116, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, SARE_MLH_Stock1=0.87, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.9 SARE_MLH_Stock1 Subject mentions stock or stock related words * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [77.134.49.254 listed in zen.spamhaus.org] * 1.5 DNS_FROM_RFC_BOGUSMX RBL: Envelope sender in * bogusmx.rfc-ignorant.org * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFPN6Swq3JEN; Fri, 1 Feb 2008 06:57:34 -0800 (PST) Received: from userpc.servermaragos.local (ppp247-18.adsl.forthnet.gr [77.49.26.18]) by core3.amsl.com (Postfix) with SMTP id 9CE6E28D17A; Fri, 1 Feb 2008 06:31:45 -0800 (PST) Message-ID: 617a01c864df$af3aa580$4301a8c0@userpc From: "Antoine Wolf" To: Subject: ***SPAM*** 17.024 (5) Stock breaker report Date: Fri, 1 Feb 2008 16:35:04 -0200 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.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Antivirus: avast! (VPS 080201-0, 01/02/2008), Outbound message X-Antivirus-Status: Clean No Looking back on G&S minerals Symbol-GSML Up 4 consecutive days for over 40% in profits and record volume Read the PR, the good news keeps coming. Add GSML to your Radar and watch it like a hawk. This company is going to $3. even if it hits half of projected forcast it would be a phenomenal 1000% profit. No other stock can deliver that in times like this Get in on GSML G&S minerals INC. From filth@earthlink.net Fri Feb 1 07:21: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 C6D7A3A69F7 for ; Fri, 1 Feb 2008 07:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 99.199 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=99.199 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, 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, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HOST_EQ_IT HOST_EQ_IT * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 0.6 HELO_EQ_IT HELO_EQ_IT * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: strutfoothome.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: strutfoothome.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: strutfoothome.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: strutfoothome.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: strutfoothome.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: strutfoothome.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [87.7.142.239 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [87.7.142.239 listed in zen.spamhaus.org] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: strutfoothome.com] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8-+LmdoOrqs for ; Fri, 1 Feb 2008 07:21:34 -0800 (PST) Received: from host239-142-dynamic.7-87-r.retail.telecomitalia.it (host239-142-dynamic.7-87-r.retail.telecomitalia.it [87.7.142.239]) by core3.amsl.com (Postfix) with ESMTP id 876DD28C99A for ; Fri, 1 Feb 2008 07:01:21 -0800 (PST) Message-ID: <000701c864e3$0789610a$20cc5486@jddprgoc> From: "horton adolphus" To: Subject: ***SPAM*** 99.199 (5) Save today 60% Off ALL Designer Footwear such as Gucci Prada Chanel Date: Fri, 01 Feb 2008 13:15:36 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C864E3.0783F7FC" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C864E3.0783F7FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable They say first impressions are everything... Make sure you stand your ground when walking around, simply by walking = hard in Top Brand Name Designer Footwear. Forget department store prices, Enjoy DIRECT PRICING at more than 65% = OFF on a wide variety of 2008 Collections from Versace, Prada, Chanel, = Dior & More. =20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers and = Casual Shoes from Brand Names at less than WHOLESALE prices. Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR! Forget Department Store Prices, Buy Direct=20 Visit Today! Click Here.... =20 =20 ------=_NextPart_000_0004_01C864E3.0783F7FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

They say first = impressions are everything...
Make sure you stand your ground when walking around, simply by walking = hard in Versace, = Prada, Chanel, Dior & More.

=20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers = and Casual Shoes from Brand Names at less than WHOLESALE prices.
Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR!

Forget Department = Store Prices, Buy Direct
Visit Today! Click Here....
------=_NextPart_000_0004_01C864E3.0783F7FC-- From kippfens1990@1awebsites.ws Fri Feb 1 10:41: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 89EFF28C464 for ; Fri, 1 Feb 2008 10:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 71.25 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=71.25 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HTML_MESSAGE=1, 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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: risohoegb.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: risohoegb.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: risohoegb.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: risohoegb.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: risohoegb.com] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2sn3m8s0AEz for ; Fri, 1 Feb 2008 10:41:47 -0800 (PST) Received: from customer-232.20.livas.lv (customer-232.20.livas.lv [84.245.232.20]) by core3.amsl.com (Postfix) with ESMTP id 6155428C5A6 for ; Fri, 1 Feb 2008 10:40:13 -0800 (PST) Message-ID: <000e01c86502$1c353c50$14e8f554@Bermuds> From: "Flemming Jokinen" To: dnsext-archive@ietf.org Subject: ***SPAM*** 71.25 (5) Ensure you do not get left out - get your necessary equipment here. Date: Fri, 1 Feb 2008 20:41:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C86512.DFBE0C50" 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 ----------=_NextPart_000_000A_01C86512.DFBE0C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Non-stop action every night - do you have what it takes? ----------=_NextPart_000_000A_01C86512.DFBE0C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Non-stop action every night - do = you have=20 what it takes? ----------=_NextPart_000_000A_01C86512.DFBE0C50-- From diplomaticliv3@processmail.com Fri Feb 1 11:09: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 6D2CF3A69C0 for ; Fri, 1 Feb 2008 11:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 89.967 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=89.967 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, FH_HELO_ENDS_DOT=10.993, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=1, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, SARE_URI_CONS7=0.306, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_NOVOWEL=1.62] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 11 FH_HELO_ENDS_DOT Helo ends with a dot. * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 1.4 SARE_ADULT2 BODY: Contains adult material * 1.6 URI_NOVOWEL URI: URI hostname has long non-vowel sequence * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: hjksrpsege.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: hjksrpsege.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: hjksrpsege.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: hjksrpsege.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: hjksrpsege.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [98.196.63.244 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 0.3 SARE_URI_CONS7 body contains link to probable spammer * 0.3 HOST_MISMATCH_NET HOST_MISMATCH_NET Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsRHM4iCrndi for ; Fri, 1 Feb 2008 11:09:19 -0800 (PST) Received: from DHQBCY81.hsd1.tx.comcast.net. (c-98-196-63-244.hsd1.tx.comcast.net [98.196.63.244]) by core3.amsl.com (Postfix) with ESMTP id 442CB28C7C9 for ; Fri, 1 Feb 2008 11:02:14 -0800 (PST) Received: from [98.196.63.244] by processmail.com.s5a1.psmtp.com; Fri, 32 Jan 2008 13:03:51 -0600 Message-ID: <339dfd74$00000006$f43fc462@diplomaticliv3> From: "Natasha Stringer" To: Subject: ***SPAM*** 89.967 (5) Argyrerin speciosa seed 100 mg; Valeriana wallichii 25 mg Date: Fri, 32 Jan 2008 13:03:51 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_339DFCB0.00000003" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_339DFCB0.00000003 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Vitamin E 20 IU, soya protein concentrate 250 mg Our team of Scientists s= pent years developing a product that will safely and effectively add leng= th, width, and strength to any man's penis. The work has created a produc= t that has been shown to significantly increase penis length, provide str= onger erections, improve sexual endurance, and increase ejaculation volum= e. http://hjksrpsege.com Vpxl will work on both circumcised and non circumcised penis. ------=_NextPart_000_0007_339DFCB0.00000003 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Vitamin E 20 IU, soya protein concentrat= e 250 mg Our team of Scientists spent years developing a product that wil= l safely and effectively add length, width, and strength to any man's pen= is. The work has created a product that has been shown to significantly i= ncrease penis length, provide stronger erections, improve sexual enduranc= e, and increase ejaculation volume.
Vpxl will work on both circumcised and n= on circumcised penis.
 
------=_NextPart_000_0007_339DFCB0.00000003-- From devaelru1955@40nip-perist.att.sch.gr Fri Feb 1 11:47: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 E8C073A6888 for ; Fri, 1 Feb 2008 11:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 87.332 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=87.332 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.9 HOST_EQ_PL HOST_EQ_PL * 1.1 HELO_EQ_PL HELO_EQ_PL * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: magefro.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: magefro.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: magefro.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: magefro.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [87.205.189.88 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FofWBB1m2uHu for ; Fri, 1 Feb 2008 11:47:14 -0800 (PST) Received: from 87-205-189-88.adsl.inetia.pl (87-205-189-88.adsl.inetia.pl [87.205.189.88]) by core3.amsl.com (Postfix) with ESMTP id 7C4CB3A681F for ; Fri, 1 Feb 2008 11:43:51 -0800 (PST) Message-ID: <001201c8650a$f73bd130$58bdcd57@dom63ofviiwfzv> From: "Abdallah michel" To: dnsext-archive@lists.ietf.org Subject: ***SPAM*** 87.332 (5) Chicks will be AMAZED by your legendary PROWESS. Date: Fri, 1 Feb 2008 20:45:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C86513.59003930" 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 ----------=_NextPart_000_000E_01C86513.59003930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ever wanted a GIANT ROD? Click here for one. ----------=_NextPart_000_000E_01C86513.59003930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ever wanted a GIANT ROD? Click here = for=20 one. ----------=_NextPart_000_000E_01C86513.59003930-- From owner-namedroppers@ops.ietf.org Fri Feb 1 13:15: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 93DA73A68A6; Fri, 1 Feb 2008 13:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K4fDatM7E4Z; Fri, 1 Feb 2008 13:15:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 59EA23A6932; Fri, 1 Feb 2008 13:15:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL38I-0001Jt-3n for namedroppers-data@psg.com; Fri, 01 Feb 2008 21:09:10 +0000 Received: from [129.9.40.82] (helo=odvirpr6.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL38F-0001JT-N7 for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 21:09:08 +0000 Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.99.241]) by odvirpr6.extra.daimlerchrysler.com (Postfix) with SMTP id 1382516218E for ; Fri, 1 Feb 2008 16:09:06 -0500 (EST) Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008020116090620019 for ; Fri, 01 Feb 2008 16:09:06 -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 m11L96Z7019869 for ; Fri, 1 Feb 2008 16:09:06 -0500 (EST) Message-ID: <47A38A72.9090208@chrysler.com> Date: Fri, 01 Feb 2008 16:09:06 -0500 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> <47A2D2AC.4050609@nlnetlabs.nl> In-Reply-To: <47A2D2AC.4050609@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 > > Kevin Darcy wrote: > | Danny Mayer wrote: > |> There are many solutions to improving the design of the architected or > |> mis-architected configuration, but the protocol needs to work for all > |> situations including this one. So setting the TC bit is the correct > |> answer. > > I agree with Danny. > > | Non sequitur. The protocol "works" whether TC is clear or not: if it's > | clear, the client takes the answer as it finds it and queries the > | "missing" NS records as necessary; if TC is set, then the client > | (typically) will retry the query using TCP, thus obtaining the answer > | and all of the NS records that wouldn't fit in the initial response. > > Well, your use of the protocol works without the NS records. The DNS is > robust. The DNS protocol as widely used, needs those NS records to help > resolvers find nameservers more efficiently. So what is querying for the > SOA record that cannot retry with TCP? (This is your local subnet, so > speed is not that much of a problem?) > > Can you deploy EDNS? That is the other obvious solution. Already deployed. The advertised buffer size is 2048 which is still not big enough to fit all of the NS records. > > | The main question is whether an implementation which sets TC under > these > | circumstances conforms to RFC 2181. A follow-on question would be > | whether RFC 2181 needs to be amended for situations such as this one. > > What is the problem with a TC bit on a SOA answer? Besides the wastefulness of an unnecessary TCP retry, it causes execution of a code branch that has an unfortunate end result. But, I don't want to whine about the coding of a particular implementation. My focus here is on the question of standards conformance. Apparently we still don't have a consensus answer on that. - 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 Feb 1 13:15: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 2A3EF3A6A05; Fri, 1 Feb 2008 13:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcgT2Mm+T-NS; Fri, 1 Feb 2008 13:15:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C8B5D3A69FA; Fri, 1 Feb 2008 13:15:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL358-0000o4-HJ for namedroppers-data@psg.com; Fri, 01 Feb 2008 21:05:54 +0000 Received: from [129.9.168.76] (helo=shvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL356-0000ng-4P for namedroppers@ops.ietf.org; Fri, 01 Feb 2008 21:05:53 +0000 Received: from shnavip4-hme0.shdc.chrysler.com (unknown [53.231.141.98]) by shvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id E05CD110262 for ; Fri, 1 Feb 2008 15:56:12 -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 M2008020116055010983 for ; Fri, 01 Feb 2008 16:05:50 -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 m11L5o2Y019866 for ; Fri, 1 Feb 2008 16:05:50 -0500 (EST) Message-ID: <47A389AE.4070400@chrysler.com> Date: Fri, 01 Feb 2008 16:05:50 -0500 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <479FBDD3.4030206@chrysler.com> <20080201105931.GC15412@nic.fr> In-Reply-To: <20080201105931.GC15412@nic.fr> 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 Stephane Bortzmeyer wrote: > On Tue, Jan 29, 2008 at 06:59:15PM -0500, > Kevin Darcy wrote > a message of 31 lines which said: > > >> So, if an authoritative nameserver responds to a QTYPE=SOA query, >> with the SOA RR in the Answer Section, but cannot fit all of the >> apex NS records of the zone into the Authority Section, should it >> set TC or not? >> > > IMHO, yes, strong YES. Doing otherwise would violate the atomicity of > the NS RRset. > > I admit I was not able to find text in an RFC about this atomicity > (RFC 2181, 5.1, only talks about the Answer section). Somehting to add > to the "profile" document? Thou MUST NOT split a RRset *or* set TC if > you do? > Sorry, I wasn't completely clear. The two alternatives, as kre has point out, are: 1) Authority Section empty, TC clear 2) Authority Section has a partial RRset, TC set Option #2 will cause most (all?) implementations to automatically retry via TCP, which is unnecessary if the SOA RR (the answer to the question) was returned in the Answer Section. - 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 gborow@optonline.com Fri Feb 1 13:37: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 D41BF3A6987 for ; Fri, 1 Feb 2008 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 92.705 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=92.705 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_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=1, 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, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 5.0 GB_ROLEX BODY: I don't need a new watch! * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: dhueiije.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: dhueiije.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: dhueiije.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: dhueiije.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: dhueiije.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: dhueiije.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [190.188.140.173 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4mHI5yunB3H for ; Fri, 1 Feb 2008 13:37:52 -0800 (PST) Received: from 173-140-188-190.cab.prima.net.ar (unknown [190.188.140.173]) by core3.amsl.com (Postfix) with ESMTP id 038B63A6936 for ; Fri, 1 Feb 2008 13:37:46 -0800 (PST) Message-ID: <000a01c8651a$0759b893$b1089782@dscsfxh> From: "kippie bardolph" To: Subject: ***SPAM*** 92.705 (5) Perfectly crafted luxury timepieces Date: Fri, 01 Feb 2008 19:51:34 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8651A.0757588C" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8651A.0757588C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at low prices. Start 2008 in stunning fashion with our perfect range of upgraded 2008 = replicas. Thousands of different models to choose from! Watches Rolex DatejustBvlgariCartierChanelPatek Philippe PENS Mont Blanc RollerballMont Blanc BallpointMont Blanc FountainLV = BallpointLV Rollerball Jewelry Tiffany & Co Jewelry=20 http://www.dhueiije.com/ ------=_NextPart_000_0007_01C8651A.0757588C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Perfectly crafted luxury = timepieces, all at low prices.
Start 2008 in stunning fashion = with our perfect range of upgraded 2008 replicas.
Thousands of different models to choose from!
Watches
  • Rolex Datejust
  • Bvlgari
  • Cartier
  • Chanel
  • Patek Philippe
 PENS
  • Mont Blanc Rollerball
  • Mont Blanc Ballpoint
  • Mont Blanc Fountain
  • LV Ballpoint
  • LV Rollerball
 Jewelry
  • Tiffany & Co Jewelry

>> | configuration of the particular DNS implementation in question to >>> add an | NS record at the apex of the zone for every "peer" server. >>> >>> That is OK, and even sounds correct, but ... >>> >>> | We're up to 142 NS records at the apex of this particular zone. >>> >>> That's insane. What benefit can anyone possibly achieve by having >>> that many peer servers? You'd be better to use anycast, and have just >>> one server name for a whole subset of those 142 - that way at least the >>> routing system can help clients (resolvers) select a rational one of >>> those servers to query. >>> >>> And yes, that is very poor configuration (not in the server adding the >>> NS records, but in having that many peers in the first place - how >>> frequently >>> do you verify that they're all working correctly???) >>> >>> | That's what gives rise to the TC bit being set, >>> >>> Yes, it would - and you get the option of either setting TC, and forcing >>> a retry (using TCP) for the SOA to be fetched, or of simply putting none >>> of the NS records in the reply - the server faced with this absurd zone >>> zone config has no other choice. >>> >>> | not the size of the SOA RR itself (as you | >>> theorized/hypothesized later in your message). >>> >>> For that I was just suggesting that in some cases the NS list (of a >>> sanely configured NS list) may be carefully chosen to fit in a UDP >>> reply when an NS query (or referral) is performed, but just fail to fit >>> in the presence of a larg(ish) answer section - like perhaps a SOA >>> record - I was not intending any specific comment on your particular >>> situation. >>> >>> | It's more like "bad design" than "poor configuration". >>> >>> You mean bad design that it is possible to have so many peers? How >>> would >>> you possibly prevent it? Or bad design that having the peers causes >>> them >>> to be listed in NS records (I suppose maybe). >>> >>> | But I'm trying | hard not to point fingers at specific >>> implementations, >>> >>> No, nor was I (though perhaps at whoever decided so many peers was >>> sane) - and .. >>> >>> | since I'm | attempting to raise a protocol-conformance issue, >>> not just criticize | particular implementations for their >>> discretionary choices. >>> >>> I agree, which is what I said last time (and you quoted from my previous >>> message) ... >>> >>>> so the best we can do is to make sure that things are handled sanely >>>> when there is a poor config. >>> >>> That is, the protocol has to cope with the stupid, no matter whose >>> stupidity it is, and making sure that it does is a perfectly reasonable >>> thing to do. >>> >>> kre >> >> There are many solutions to improving the design of the architected or >> mis-architected configuration, but the protocol needs to work for all >> situations including this one. So setting the TC bit is the correct >> answer. > Non sequitur. The protocol "works" whether TC is clear or not: if it's > clear, the client takes the answer as it finds it and queries the > "missing" NS records as necessary; if TC is set, then the client > (typically) will retry the query using TCP, thus obtaining the answer > and all of the NS records that wouldn't fit in the initial response. > > The main question is whether an implementation which sets TC under these > circumstances conforms to RFC 2181. A follow-on question would be > whether RFC 2181 needs to be amended for situations such as this one. > Why would you change an RFC for a poor infrastructure. Fix the infrastructure not the protocol which is working just fine. 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 Feb 2 00:18: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 8AEA93A6A21; Sat, 2 Feb 2008 00:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuPlYQeV0qOe; Sat, 2 Feb 2008 00:18:33 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C4BE73A69D2; Sat, 2 Feb 2008 00:18:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLDMm-000D1u-0X for namedroppers-data@psg.com; Sat, 02 Feb 2008 08:04:48 +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 1JLDMi-000D1b-Rd for namedroppers@ops.ietf.org; Sat, 02 Feb 2008 08:04:46 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m1284aOh026132; Sat, 2 Feb 2008 10:04:36 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m1284a53026128; Sat, 2 Feb 2008 10:04:36 +0200 Date: Sat, 2 Feb 2008 10:04:35 +0200 (EET) From: Pekka Savola To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) In-Reply-To: <47A389AE.4070400@chrysler.com> Message-ID: References: <479FBDD3.4030206@chrysler.com> <20080201105931.GC15412@nic.fr> <47A389AE.4070400@chrysler.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/5649/Sat Feb 2 02:54:58 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Fri, 1 Feb 2008, Kevin Darcy wrote: > Sorry, I wasn't completely clear. The two alternatives, as kre has point out, > are: > > 1) Authority Section empty, TC clear > 2) Authority Section has a partial RRset, TC set > > Option #2 will cause most (all?) implementations to automatically retry via > TCP, which is unnecessary if the SOA RR (the answer to the question) was > returned in the Answer Section. We had this discussion though from a slightly different perspective when we were writing RFC 4472; section 4.4 and appendix B may be of interest. One of the key points here is that RFC2181 says an implementation should _discard_ the response that came with TC bit set and retry with TCP. If TCP fails, you have no answer -- in contrast to option 1) above where two UDP queries would succeed. So, option 1) seems like a more robust approach from the practical perspective. -- 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 Sat Feb 2 12:39: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 E082E3A6AB1; Sat, 2 Feb 2008 12:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuvP3C8RHCRC; Sat, 2 Feb 2008 12:39:14 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1640D3A696F; Sat, 2 Feb 2008 12:39:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLOrh-000KAG-DC for namedroppers-data@psg.com; Sat, 02 Feb 2008 20:21:29 +0000 Received: from [208.218.130.12] (helo=gis.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLOre-000K9h-Kh for namedroppers@ops.ietf.org; Sat, 02 Feb 2008 20:21:27 +0000 Received: from [10.10.10.100] ([63.209.227.203]) by mx04.gis.net; Sat, 02 Feb 2008 15:21:18 -0500 Message-ID: <47A4D0BF.30309@gis.net> Date: Sat, 02 Feb 2008 15:21:19 -0500 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kevin Darcy CC: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> <47A2D2AC.4050609@nlnetlabs.nl> <47A38A72.9090208@chrysler.com> In-Reply-To: <47A38A72.9090208@chrysler.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 Kevin Darcy wrote: > Wouter Wijngaards wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Kevin Darcy wrote: >> | Danny Mayer wrote: >> |> There are many solutions to improving the design of the architected or >> |> mis-architected configuration, but the protocol needs to work for all >> |> situations including this one. So setting the TC bit is the correct >> |> answer. >> >> I agree with Danny. >> >> | Non sequitur. The protocol "works" whether TC is clear or not: if it's >> | clear, the client takes the answer as it finds it and queries the >> | "missing" NS records as necessary; if TC is set, then the client >> | (typically) will retry the query using TCP, thus obtaining the answer >> | and all of the NS records that wouldn't fit in the initial response. >> >> Well, your use of the protocol works without the NS records. The DNS is >> robust. The DNS protocol as widely used, needs those NS records to help >> resolvers find nameservers more efficiently. So what is querying for the >> SOA record that cannot retry with TCP? (This is your local subnet, so >> speed is not that much of a problem?) >> >> Can you deploy EDNS? That is the other obvious solution. > Already deployed. The advertised buffer size is 2048 which is still not > big enough to fit all of the NS records. >> >> | The main question is whether an implementation which sets TC under >> these >> | circumstances conforms to RFC 2181. A follow-on question would be >> | whether RFC 2181 needs to be amended for situations such as this one. >> >> What is the problem with a TC bit on a SOA answer? > Besides the wastefulness of an unnecessary TCP retry, it causes > execution of a code branch that has an unfortunate end result. > > But, I don't want to whine about the coding of a particular > implementation. My focus here is on the question of standards > conformance. Apparently we still don't have a consensus answer on that. I think we *do* have consensus on it. You just don't want to accept it. I have seen no response indicating that the RFC should be changed. 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 Mon Feb 4 13:16: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 8A3763A6DC7; Mon, 4 Feb 2008 13:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6vjz2JinbLM; Mon, 4 Feb 2008 13:16:43 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id CF2673A6CA9; Mon, 4 Feb 2008 13:16:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM8Po-000KDe-DJ for namedroppers-data@psg.com; Mon, 04 Feb 2008 20:59: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 1JM8Pl-000KDJ-MG for namedroppers@ops.ietf.org; Mon, 04 Feb 2008 20:59:43 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m14KxXxk043344; Mon, 4 Feb 2008 15:59:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 4 Feb 2008 15:59:30 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: AXFR and TCP Cc: ed.lewis@neustar.biz 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 I am going over the AXFR on TCP part of the -07 draft. Reading some comments and contrasting with some on this list I wanted to find out what's really happening now as opposed to what could be. My vision of an AXFR session is, client opens a connection, asks, gets, closes connection, session over. That seems quite trivial, something I can do with dig, etc. It's possible to chain and multiplex zone transfers on the connection if the TCP connection management is independent of the AXFR session management. I know this can be done. But does any code do this now? With the cheapness of just doing non-AXFR queries over UDP, why would a client go out of its way to use an open TCP connection (if its there) or go out of its way to open and sustain an TCP connection instead of just sending via UDP? It seems too much work for me to have to keep a list of machines with which I have an open TCP session so I know if I shoulf shunt a query to the UDP or TCP transport managers. So - does any code today multiplex zone transfers (between a pair of processes) or use the TCP connection for more than AXFR (and TC induced retries)? Does any code maintain open TCP connections with other servers when "idle?" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 wahsab1969@20host.com Tue Feb 5 10:34:07 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 724FD3A6D46; Tue, 5 Feb 2008 10:53:01 -0800 (PST) Received: from 164-157-21-190.adsl.terra.cl (164-157-21-190.adsl.terra.cl [190.21.157.164]) by mail.ietf.org (Postfix) with ESMTP id 735E028D42C for ; Tue, 5 Feb 2008 08:21:48 -0800 (PST) Message-ID: <001001c867f1$fb5610c0$a49d15be@desktop> From: "Nelda Dimkovski" To: dnsext-archive@lists.ietf.org Subject: Don't wait Get our 100% all natural pen1s enlargement pills and join millions with renewed confidence with women Date: Tue, 5 Feb 2008 13:23:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C867FA.5D1A78C0" 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 ----------=_NextPart_000_000C_01C867FA.5D1A78C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don't disappoint your Valentine's Day date Get your enlargement pills = today ----------=_NextPart_000_000C_01C867FA.5D1A78C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don't disappoint your Valentine's = Day date G et your enlargement pills today ----------=_NextPart_000_000C_01C867FA.5D1A78C0-- From owner-namedroppers@ops.ietf.org Tue Feb 5 10:34:46 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 8D8743A6AB4; Tue, 5 Feb 2008 10:52:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id BA75C3A8416; Mon, 4 Feb 2008 20:49:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFeR-000MoH-D6 for namedroppers-data@psg.com; Tue, 05 Feb 2008 04:43:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JMFeO-000Mo0-Vc for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 04:43:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9CD581142E; Tue, 5 Feb 2008 04:43:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mark Andrews cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP In-Reply-To: Your message of "Tue, 05 Feb 2008 10:53:27 +1100." <200802042353.m14NrR1o018135@drugs.dv.isc.org> References: <200802042353.m14NrR1o018135@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 05 Feb 2008 04:43:16 +0000 Message-ID: <54653.1202186596@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > ... > > the spec does not prohibit parallelism. a conforming implementation > > could spew requests down a TCP session, suck up the responses that come > > back (in any order), demux based on query-ID, and get "query windowing"; > > however, that implementation would not be widely interoperable at this > > time, and the spec should probably be updated to prohibit parallelism > > and demultiplexing. > > Why? The spec will out live any broken implementations. then we should update the spec to say, this might not work, here's what it could look like when you try it, here's what you should do when it fails. > A server that doesn't support multiplexed responses will > just serialise the response. If a client doesn't want to > handle multipleplexed responses will just wait until the > final soa to ask the query. Each side is independently > capable of enforcing what it supports without any extensions. if a server can answer in order A-C-B when asked questions in order A-B-C, then a client who does not look at the query-ID since it "knows" that the order will be respected, will fail, and might have no backoff capability. (granted, such a client would be unlikely to send request B before getting response A, but the spec is a minefield that could make that look safe.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From livingiz20@nphfweb.org Tue Feb 5 10:34:51 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id ABB613A7FC7; Tue, 5 Feb 2008 10:53:02 -0800 (PST) Received: from static-178-54-235-87.ipcom.comunitel.net (unknown [87.235.54.178]) by mail.ietf.org (Postfix) with ESMTP id DC1293A6ECF for ; Mon, 4 Feb 2008 13:56:55 -0800 (PST) Received: from [87.235.54.178] by nphfweb.org; Mon, 4 Feb 2008 22:58:30 +0100 Message-ID: <01c86781$7582af00$b236eb57@livingiz20> From: "Isiah Marsh" To: Subject: InternetPricesForCustomersPills Date: Mon, 4 Feb 2008 22:58:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 100mgBestQualityMoreinfo http://couldarm.com From ImogenecoffeeKeen@groklaw.net Tue Feb 5 10:34:57 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D02E43A7FD4; Tue, 5 Feb 2008 10:53:02 -0800 (PST) Received: from poste04.mshome.net (unknown [41.201.107.173]) by mail.ietf.org (Postfix) with SMTP id DBF323A988B; Tue, 5 Feb 2008 02:59:03 -0800 (PST) Received: from hemorrhoid by groklaw.net with SMTP id M75mCsiYLE for ; Tue, 5 Feb 2008 12:00:12 -0100 From: "Sondra Nadeau" To: Cc: , Date: Tue, 5 Feb 2008 02:59:03 -0800 (PST) Your own privater Vegas! We know how to treat our players - how about a $2400 welcome bonmus when you join? Free money free fun. Come find out. http://bearth.net.cn/ From owner-namedroppers@ops.ietf.org Tue Feb 5 10:37:21 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 898693A713F; Tue, 5 Feb 2008 10:52:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id CF78C28D3AF; Tue, 5 Feb 2008 08:19:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMQJ0-000Fxx-T4 for namedroppers-data@psg.com; Tue, 05 Feb 2008 16:05:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, RDNS_NONE autolearn=no version=3.2.3 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 1JMQIt-000FxB-HI for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 16:05:49 +0000 Received: from hlid.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m15G5gAW050674 for ; Tue, 5 Feb 2008 11:05:42 -0500 (EST) (envelope-from namedroppers@hlid.ogud.com) Received: (from namedroppers@localhost) by hlid.ogud.com (8.13.1/8.13.1/Submit) id m15G5gcp050673 for namedroppers@ops.ietf.org; Tue, 5 Feb 2008 11:05:42 -0500 (EST) (envelope-from namedroppers) Received: from [2001:4f8:3:bb:2e0:81ff:fe52:9971] (helo=mail2.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL6xq-000ASv-6Q for namedroppers@ops.ietf.org; Sat, 02 Feb 2008 01:14:39 +0000 Received: from 65-86-158-146.client.dsl.net (65-86-158-146.client.dsl.net [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 362EC398FF; Sat, 2 Feb 2008 01:14:37 +0000 (UTC) (envelope-from mayer@ntp.isc.org) Received: from cust-63-209-227-203.bos-dynamic.gis.net ([63.209.227.203] helo=[10.10.10.100]) by 65-86-158-146.client.dsl.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JL6wz-0004qT-TA; Fri, 01 Feb 2008 20:13:46 -0500 Message-ID: <47A3C3C7.6090405@ntp.isc.org> Date: Fri, 01 Feb 2008 20:13:43 -0500 From: Danny Mayer Reply-To: mayer@ntp.isc.org User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> In-Reply-To: <47A28F95.3020706@chrysler.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@ntp.isc.org 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. ] Kevin Darcy wrote: > Danny Mayer wrote: >> Robert Elz wrote: >>> Date: Wed, 30 Jan 2008 22:15:14 -0500 >>> From: Kevin Darcy >>> Message-ID: <47A13D42.6010408@chrysler.com> >>> >>> | Actually, I wouldn't say "poor configuration". It's the *default* >>> | configuration of the particular DNS implementation in question to >>> add an | NS record at the apex of the zone for every "peer" server. >>> >>> That is OK, and even sounds correct, but ... >>> >>> | We're up to 142 NS records at the apex of this particular zone. >>> >>> That's insane. What benefit can anyone possibly achieve by having >>> that many peer servers? You'd be better to use anycast, and have just >>> one server name for a whole subset of those 142 - that way at least the >>> routing system can help clients (resolvers) select a rational one of >>> those servers to query. >>> >>> And yes, that is very poor configuration (not in the server adding the >>> NS records, but in having that many peers in the first place - how >>> frequently >>> do you verify that they're all working correctly???) >>> >>> | That's what gives rise to the TC bit being set, >>> >>> Yes, it would - and you get the option of either setting TC, and forcing >>> a retry (using TCP) for the SOA to be fetched, or of simply putting none >>> of the NS records in the reply - the server faced with this absurd zone >>> zone config has no other choice. >>> >>> | not the size of the SOA RR itself (as you | >>> theorized/hypothesized later in your message). >>> >>> For that I was just suggesting that in some cases the NS list (of a >>> sanely configured NS list) may be carefully chosen to fit in a UDP >>> reply when an NS query (or referral) is performed, but just fail to fit >>> in the presence of a larg(ish) answer section - like perhaps a SOA >>> record - I was not intending any specific comment on your particular >>> situation. >>> >>> | It's more like "bad design" than "poor configuration". >>> >>> You mean bad design that it is possible to have so many peers? How >>> would >>> you possibly prevent it? Or bad design that having the peers causes >>> them >>> to be listed in NS records (I suppose maybe). >>> >>> | But I'm trying | hard not to point fingers at specific >>> implementations, >>> >>> No, nor was I (though perhaps at whoever decided so many peers was >>> sane) - and .. >>> >>> | since I'm | attempting to raise a protocol-conformance issue, >>> not just criticize | particular implementations for their >>> discretionary choices. >>> >>> I agree, which is what I said last time (and you quoted from my previous >>> message) ... >>> >>>> so the best we can do is to make sure that things are handled sanely >>>> when there is a poor config. >>> >>> That is, the protocol has to cope with the stupid, no matter whose >>> stupidity it is, and making sure that it does is a perfectly reasonable >>> thing to do. >>> >>> kre >> >> There are many solutions to improving the design of the architected or >> mis-architected configuration, but the protocol needs to work for all >> situations including this one. So setting the TC bit is the correct >> answer. > Non sequitur. The protocol "works" whether TC is clear or not: if it's > clear, the client takes the answer as it finds it and queries the > "missing" NS records as necessary; if TC is set, then the client > (typically) will retry the query using TCP, thus obtaining the answer > and all of the NS records that wouldn't fit in the initial response. > > The main question is whether an implementation which sets TC under these > circumstances conforms to RFC 2181. A follow-on question would be > whether RFC 2181 needs to be amended for situations such as this one. > Why would you change an RFC for a poor infrastructure. Fix the infrastructure not the protocol which is working just fine. 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 1kilgore@abstractfaces.com Tue Feb 5 10:38:30 2008 Return-Path: <1kilgore@abstractfaces.com> X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4195528C770; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from 210.subnet125-161-143.speedy.telkom.net.id (unknown [125.161.138.13]) by mail.ietf.org (Postfix) with ESMTP id 337383A8892 for ; Mon, 4 Feb 2008 22:29:12 -0800 (PST) Message-ID: <000c01c867c0$a5a22d70$d28fa17d@RIKHO> From: "DEEPESH Kriek" <1kilgore@abstractfaces.com> To: dnsext-archive@ietf.org Subject: Realize all your partner's sexual dreams. click here Date: Tue, 5 Feb 2008 13:30:49 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C867FB.52010570" 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 ----------=_NextPart_000_0008_01C867FB.52010570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your secret to your new sexual life lies here. ----------=_NextPart_000_0008_01C867FB.52010570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your secret to your new sexual life = lies=20 here. ----------=_NextPart_000_0008_01C867FB.52010570-- From azehnder@moonblossom.net Tue Feb 5 10:38:37 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 218513A7B1C; Tue, 5 Feb 2008 10:52:53 -0800 (PST) Received: from h-66-167-1-49.lsanca54.covad.net (h-66-167-1-49.lsanca54.covad.net [66.167.1.49]) by mail.ietf.org (Postfix) with SMTP id 9E0FE3A71D0 for ; Mon, 4 Feb 2008 13:46:36 -0800 (PST) Received: (qmail 16500 invoked from network); Mon, 4 Feb 2008 13:47:42 -0800 Received: from unknown (HELO egq) (197.58.220.229) by h-66-167-1-49.lsanca54.covad.net with SMTP; Mon, 4 Feb 2008 13:47:42 -0800 Message-ID: <001901c86777$91943ec0$e5dc3ac5@egq> From: To: Subject: WeStock All ThePopularED_s Date: Mon, 4 Feb 2008 13:47:42 -0800 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 5.50.4133.2499 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2499 Make her tremble with passion! http://juu.andconsider.com From refund@usa.gov Tue Feb 5 10:42:46 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 959D93A9642; Tue, 5 Feb 2008 10:53:03 -0800 (PST) Received: from home-800.4webbs.com (cpe-67-49-120-63.socal.res.rr.com [67.49.120.63]) by mail.ietf.org (Postfix) with ESMTP id DEA603A9F79 for ; Tue, 5 Feb 2008 04:23:35 -0800 (PST) Received: from User ([151.12.152.26]) by home-800.4webbs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 04:25:08 -0800 Reply-To: From: "Internal Revenue Service U.S.A" Subject: Important Message From IRS Date: Tue, 5 Feb 2008 13.25.20 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 05 Feb 2008 12:25:08.0489 (UTC) FILETIME=[25420790:01C867F2] To: undisclosed-recipients:;

After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $93.60. Please submit the tax refund request and allow us 6-9 days in order to process it.

A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline.

To access your tax refund online, please click here

Regards,
Internal Revenue Service
 
  © Copyright 2007, Internal Revenue Service U.S.A. All rights reserved..
From hirvisep1960@GOLDMAX.COM Tue Feb 5 10:43:51 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 042493A7C37; Tue, 5 Feb 2008 10:37:53 -0800 (PST) Received: from ppp-175-78.32-151.iol.it (ppp-175-78.32-151.iol.it [151.32.78.175]) by mail.ietf.org (Postfix) with ESMTP id E482328CB02 for ; Tue, 5 Feb 2008 06:15:45 -0800 (PST) Message-ID: <001001c86801$d0c979e0$af4e2097@PC302821663923> From: "Gavril Gastero" To: dnsext-archive@ietf.org Subject: She gives me head EVERY night now that I have such a large pecker Date: Tue, 5 Feb 2008 15:17:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C8680A.328DE1E0" 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 ----------=_NextPart_000_000C_01C8680A.328DE1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Love her the right way, the hard way - the LONG AND DEEP way. ----------=_NextPart_000_000C_01C8680A.328DE1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Love her the right way, the hard = way - the=20 LONG AND DEEP way. ----------=_NextPart_000_000C_01C8680A.328DE1E0-- From RandalperturbationClayton@signbabies.com Tue Feb 5 10:44:39 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 793803A6BD5; Tue, 5 Feb 2008 10:49:18 -0800 (PST) Received: from desktop.domain.invalid (unknown [190.166.77.108]) by mail.ietf.org (Postfix) with SMTP id 0449828D97D; Tue, 5 Feb 2008 09:56:49 -0800 (PST) Message-ID: <021a01c86791$7e9f3120$0200000a@desktop> From: "Rolando Park" To: , =20
If you have your own = business and=20 require IMMEDIATE ready money to spend ANY way you like or require Extra = money=20 to give your company a boost or wish A low interest loan - NO STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 credit will not disqualify you!
=20
http://beartd.net.cn/
------=_NextPart_000_0216_01C86791.7E9F3120-- From owner-namedroppers@ops.ietf.org Tue Feb 5 10:45:31 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 781D63A7363; Tue, 5 Feb 2008 10:43:09 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 59D5D3A837D; Mon, 4 Feb 2008 20:33:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFN3-000KMF-3n for namedroppers-data@psg.com; Tue, 05 Feb 2008 04:25:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 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 1JMFN0-000KLh-OX for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 04:25:19 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m154OxDb046322; Mon, 4 Feb 2008 23:25:00 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802050046.m150kXZ1018895@drugs.dv.isc.org> References: <200802050046.m150kXZ1018895@drugs.dv.isc.org> Date: Mon, 4 Feb 2008 23:24:53 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: AXFR and TCP Cc: Edward Lewis , Paul Vixie , namedroppers@ops.ietf.org 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 11:46 +1100 2/5/08, Mark Andrews wrote: > Handling one request at a time just serialises the response. > I presume that what you mean by "single threaded on a TCP > connection". No, I meant that it is conceivable that a server might assign a connection (=BSD socket) to a thread and that thread isn't always reading data. I'm just thinking of possible ways a server might be handling the connection in ways that might make multiplexing not work. Or worse, a multiplexing client might confuse and kill the server process. Dunno, just thinking now. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 5 10:45:41 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 8DBCB3A7A85; Tue, 5 Feb 2008 10:53:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 408333A769F; Mon, 4 Feb 2008 16:01:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMB87-000DmT-Cc for namedroppers-data@psg.com; Mon, 04 Feb 2008 23:53:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JMB84-000Dkg-7J for namedroppers@ops.ietf.org; Mon, 04 Feb 2008 23:53:38 +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 m14NrR1o018135; Tue, 5 Feb 2008 10:53:27 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802042353.m14NrR1o018135@drugs.dv.isc.org> To: Paul Vixie Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: AXFR and TCP In-reply-to: Your message of "Mon, 04 Feb 2008 22:18:27 -0000." <35857.1202163507@sa.vix.com> Date: Tue, 05 Feb 2008 10:53:27 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > It's possible to chain and multiplex zone transfers on the connection if > > the TCP connection management is independent of the AXFR session > > management. I know this can be done. But does any code do this now? > > it's common to open a TCP session, ask the SOA query, and then, using > the same TCP session, ask for an AXFR. i know of implementations like > that. i do not know of any current implementation that reuses the TCP > session again after an AXFR, but the spec allows it. > > it's also possible, using a widely popular stub resolver implementation, > to open a TCP session and use it for a multiple queries. > > none of this is parallelized in any implementation i'm aware of. so, > the query ID of the response isn't being used to demultiplex against > multiple outstanding requests. one of the reasons we don't do that is > that some DNS TCP implementations do not put the query ID into every > message of an AXFR response. > > the spec does not prohibit parallelism. a conforming implementation > could spew requests down a TCP session, suck up the responses that come > back (in any order), demux based on query-ID, and get "query windowing"; > however, that implementation would not be widely interoperable at this > time, and the spec should probably be updated to prohibit parallelism > and demultiplexing. Why? The spec will out live any broken implementations. Within a couple of years of a definitive spec being out there the vast majority of servers will have been fixed if they have not already been fixed. For the few remaining ones you will have a flag that says don't do it for this machine. If this had got out in 2002 we would already be able to use it by now. How many people really need to set "transfer-format one-answer;" anymore? A server that doesn't support multiplexed responses will just serialise the response. If a client doesn't want to handle multipleplexed responses will just wait until the final soa to ask the query. Each side is independently capable of enforcing what it supports without any extensions. > > With the cheapness of just doing non-AXFR queries over UDP, why would a > > client go out of its way to use an open TCP connection (if its there) or go > > out of its way to open and sustain an TCP connection instead of just > > sending via UDP? > > long story, many possible answers. there are valid reasons to do this. > > > It seems too much work for me to have to keep a list of machines with which > > I have an open TCP session so I know if I shoulf shunt a query to the UDP > > or TCP transport managers. > > then when you are acting as an implementor, you should not do it that way. > > > So - does any code today multiplex zone transfers (between a pair of > > processes) or use the TCP connection for more than AXFR (and TC induced > > retries)? Does any code maintain open TCP connections with other servers > > when "idle?" > > see above. it's possible that a number of things not prohibited by the > current spec need to get prohibited since they would not actually work. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- 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 CarolinecarraraDickey@bloggingstocks.com Tue Feb 5 10:45:41 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id CB1133A68BB; Tue, 5 Feb 2008 10:52:58 -0800 (PST) Received: from student3.mshome.net (pool-71-97-207-145.aubnin.dsl-w.verizon.net [71.97.207.145]) by mail.ietf.org (Postfix) with SMTP id 808833A8D9D; Mon, 4 Feb 2008 23:53:51 -0800 (PST) Message-ID: From: "Jo Self" To: , =20
If you have your own = business and=20 need IMMEDIATE money to spend ANY way you like or wish Extra money to = give the=20 business a boost or need A low interest loan - NO STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 credit history will not disqualify you!
=20
http://beartc.com.cn/
------=_NextPart_000_D2C6_01C867CC.723F75D0-- From owner-namedroppers@ops.ietf.org Tue Feb 5 10:45:57 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 11D523A70F0; Tue, 5 Feb 2008 10:52:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id BDF1E28C24F; Tue, 5 Feb 2008 05:19:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMNaT-000EyO-Di for namedroppers-data@psg.com; Tue, 05 Feb 2008 13:11:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 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 1JMNaK-000EvI-26 for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 13:11:43 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m15DBLBM066839; Tue, 5 Feb 2008 14:11:21 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47A86079.3020400@nlnetlabs.nl> Date: Tue, 05 Feb 2008 14:11:21 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP References: <200802042332.m14NVxPN017889@drugs.dv.isc.org> In-Reply-To: <200802042332.m14NVxPN017889@drugs.dv.isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 05 Feb 2008 14:11:21 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Quick notes about what NSD does. |> My vision of an AXFR session is, client opens a connection, asks, |> gets, closes connection, session over. That seems quite trivial, |> something I can do with dig, etc. This is what NSD does on the AXFR-TCP on the query side. open, transfer, close. |> It's possible to chain and multiplex zone transfers on the connection |> if the TCP connection management is independent of the AXFR session |> management. I know this can be done. But does any code do this now? NSD does not. Not even the SOA query (uses UDP, so as to not tie up TCP resources). |> With the cheapness of just doing non-AXFR queries over UDP, why would |> a client go out of its way to use an open TCP connection (if its |> there) or go out of its way to open and sustain an TCP connection |> instead of just sending via UDP? NSD prefers IXFR over UDP but some situations, as Paul alludes to, require AXFR (and thus TCP). |> It seems too much work for me to have to keep a list of machines with |> which I have an open TCP session so I know if I shoulf shunt a query |> to the UDP or TCP transport managers. | | A nameserver usually keeps this list as a by product of | having the TCP session open. There is no extra work to | keep the list, just a litte extra code to use it instead of | opening a new session. Check, NSD also keeps this (sort of) list as a by product of having the TCP session open. | We definitely have transfers that queue awaiting TCP sockets | being able to use a existing TCP connection will help. Same here, long queues can form with transfers waiting for TCP sockets. Operators complained about the long waiting times that it causes, together with the overhead of startup and teardown of the TCP sessions. Still, this is an issue in corner case situations only. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHqGB5kDLqNwOhpPgRAh4aAKC0F3eslQw+boLNDxJEbA8HI52wJgCeNCnT wCR8gHsYVTgf335oVJRiBuc= =6vPQ -----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 pzznnnxpmeqxxn@mailinator.com Tue Feb 5 10:46:25 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 8E3833A7787; Tue, 5 Feb 2008 10:38:00 -0800 (PST) Received: from dsl-244-217-97.telkomadsl.co.za (dsl-244-217-97.telkomadsl.co.za [41.244.217.97]) by mail.ietf.org (Postfix) with SMTP id 77F263A88D2 for ; Mon, 4 Feb 2008 22:32:51 -0800 (PST) Received: from ojq ([145.182.24.130]) by dsl-244-217-97.telkomadsl.co.za (8.13.1/8.13.1) with SMTP id m156ZSEY059201; Tue, 5 Feb 2008 08:35:28 +0200 Message-ID: <001601c867c1$26ee2730$8218b691@ojq> From: To: Subject: Our Love is Free Date: Tue, 5 Feb 2008 08:34:25 +0200 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 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 The Moon & Stars http://98.193.18.226/ From refedfxm@thekissnergroup.com Tue Feb 5 10:46:33 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 6456B3A73C9; Tue, 5 Feb 2008 10:37:56 -0800 (PST) Received: from [211.112.69.45] (unknown [211.112.69.45]) by mail.ietf.org (Postfix) with ESMTP id 817AD3A8509 for ; Mon, 4 Feb 2008 21:08:19 -0800 (PST) Received: from [211.112.69.45] by mail.thekissnergroup.com; Tue, 5 Feb 2008 14:09:52 +0900 From: "Ivan Logan" To: Subject: BernardoJumboPenis Date: Tue, 5 Feb 2008 14:09:52 +0900 Message-ID: <01c86800$c685b800$2d4570d3@refedfxm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal MarissaErectileorganProdigious http://www.pokerfast.com From owner-namedroppers@ops.ietf.org Tue Feb 5 10:46:46 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 213DE3A6B71; Tue, 5 Feb 2008 10:38:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id D32103A8447; Mon, 4 Feb 2008 20:50:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFdV-000MhB-D9 for namedroppers-data@psg.com; Tue, 05 Feb 2008 04:42:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JMFdS-000Mgo-MR for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 04:42:20 +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 m154g8vt088454; Tue, 5 Feb 2008 15:42:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802050442.m154g8vt088454@drugs.dv.isc.org> To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: AXFR and TCP In-reply-to: Your message of "Mon, 04 Feb 2008 23:24:53 CDT." Date: Tue, 05 Feb 2008 15:42:08 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 11:46 +1100 2/5/08, Mark Andrews wrote: > > > Handling one request at a time just serialises the response. > > I presume that what you mean by "single threaded on a TCP > > connection". > > No, I meant that it is conceivable that a server might assign a > connection (=BSD socket) to a thread and that thread isn't always > reading data. Well if it is not reading it won't respond to the next query until it decides to read the socket again. Today servers have to ensure that reply messages are written in a atomic manner even if there are multiple readers. It also has to ensure questions are read in a atomic manner. Think multiple PTR queries down a TCP socket from netstat. Mark > I'm just thinking of possible ways a server might be handling the > connection in ways that might make multiplexing not work. Or worse, > a multiplexing client might confuse and kill the server process. > Dunno, just thinking now. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. -- 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 jqyumleonhardt@damon.isd.esc4.net Tue Feb 5 10:46:53 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D3FB83A6921; Tue, 5 Feb 2008 10:47:46 -0800 (PST) Received: from usfamily.net (unknown [212.45.26.222]) by mail.ietf.org (Postfix) with SMTP id 2047C3A6871 for ; Tue, 5 Feb 2008 03:58:32 -0800 (PST) Received: from 69.20.116.102 (HELO server56.appriver.com) by lists.ietf.org with esmtp (WYKCWBDMEMSP MAYGDM) id qw3peT-j0ds5W-R2 for dnsext-archive@lists.ietf.org; Tue, 05 Feb 2008 14:59:55 +0300 Message-ID: <20db01c867ee$9f82dc90$c0a800a1@Lessie> From: "Lessie Waldron" To: "Madge Cho" Subject: Do you have dcks that are too small Date: Tue, 05 Feb 2008 14:59:55 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_8409_2143_01C86807.C4D01490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1441 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 This is a multi-part message in MIME format. ------=_NextPart_8409_2143_01C86807.C4D01490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your phallus grows into the powerful, thickest, hardest, and most bigg= est tool=20 you`ve ever imagined - the one you`ve always interested about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - GUARANTEED}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PEN|S OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! ENTER HERE NOW TO GAIN THE LONGEST AND HARDEST PHALLUS IN THIS YEAR! http://nbnibsee=2Ecom/ blood=2E No worries," he said=2Ethese words, the President of France, Jac= ques ChiracIn all, 14 journalists in all have been kidnapped in insurance coverage=2EBank of China Governor Zhou Xiaochuan and Minister o= f ------=_NextPart_8409_2143_01C86807.C4D01490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
VPXL+: THE WORLD'S #1 PEN|S= EN'L@RGEMENT PREPARATION!

In just= a few short weeks,=20 you`ll watch with amazement as your phallus
grows into the powerful, = thickest, hardest, and most biggest tool
you`ve ever imagined - the one you`ve always interested about
having!= No pen!s en`l@rgement=20 system is faster, easier to use, or
more effective than VPXL+= - GUARANTEED!

VPXL+ IS=20 GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PE= N|S OR=20 YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARG= E TODAY!

ENTER HERE NOW TO GAIN THE LONGES= T AND HARDEST PHALLUS IN THIS YEAR!



years of Manchester United participating in Europeanyears to redu= ce the public spending on health care=2E A
Ronaldinho, Henrik Larsson, and Ronaldo=2Eblood=2E No worries," he said=2E=
these words, the President of France, Jacques ChiracIn all, 14 journa= lists in all have been kidnapped in
insurance coverage=2EBank of China= Governor Zhou Xiaochuan and Minister of ------=_NextPart_8409_2143_01C86807.C4D01490-- From jquon@sapiens.com Tue Feb 5 10:47:19 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4D9963A6E63; Tue, 5 Feb 2008 10:52:53 -0800 (PST) Received: from pD9E4434B.dip.t-dialin.net (pD9E4434B.dip.t-dialin.net [217.228.67.75]) by mail.ietf.org (Postfix) with SMTP id 9A0033A9597 for ; Tue, 5 Feb 2008 02:26:51 -0800 (PST) Received: from 209.88.187.39 (HELO extranet.sapiens.com) by ietf.org with esmtp (TEWDRHJBXKW JRYHE) id QSRv2R-lC7BeJ-Ge for dnsext-archive@ietf.org; Tue, 05 Feb 2008 11:28:28 +0100 Message-ID: <2f4101c867e1$d91120a0$4b43e4d9@Krista> From: "Krista Albright" To: "Cristina Murdock" Subject: Do you want to change your life? Date: Tue, 05 Feb 2008 11:28:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_12095_2FA9_01C867EA.3AD588A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_12095_2FA9_01C867EA.3AD588A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your pen!s grows into the hardest, biggest, ,thickest and most powerfu= l tool=20 you`ve ever imagined - the one you`ve always dreamed about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - THE BEST}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PEN|S OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! ENTER HERE NOW TO SUBSTANTIALLY IMPROVE YOUR MALE PACKAGE IN THIS YEAR! http://nbnibsee=2Ecom/ to young George=2Einstilling in the boy a sense of his own self-worth, Ti= vadar bolsteredOnce Soros understood that it was impossible to escape the= searchlights of finality, was Tivadars legacy to his son=2E So was being pragmatic=2Eb= oy would learn how to overcome great odds, how to handle tumultuous ------=_NextPart_12095_2FA9_01C867EA.3AD588A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
VPXL+: THE WORLD'S #1 PEN|S= EN'L@RGEMENT PREPARATION!

In just= a few short weeks,=20 you`ll watch with amazement as your pen!s
grows into the hardest, big= gest, ,thickest and most powerful tool
you`ve ever imagined - the one you`ve always dreamed about
having! No= pen!s en`l@rgement=20 system is faster, easier to use, or
more effective than VPXL+= - THE BEST!

VPXL+ IS=20 GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PE= N|S OR=20 YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARG= E TODAY!

ENTER HERE NOW TO SUBSTANTIALLY I= MPROVE YOUR MALE PACKAGE IN THIS YEAR!



The greatest gift Tivadar bestowed on his younger son, however,he= was the worlds highest-paid critic=2E The term suggested something of minimum investment of at least $1 million=2E It was also a hedge fund,to = young George=2E
instilling in the boy a sense of his own self-worth, T= ivadar bolsteredOnce Soros understood that it was impossible to escape th= e searchlights
of finality, was Tivadars legacy to his son=2E So was b= eing pragmatic=2Eboy would learn how to overcome great odds, how to handl= e tumultuous ------=_NextPart_12095_2FA9_01C867EA.3AD588A0-- From -w@abf.ch Tue Feb 5 10:48:28 2008 Return-Path: <-w@abf.ch> X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id EDD373A6908; Tue, 5 Feb 2008 10:38:00 -0800 (PST) Received: from 11.11.74-86.rev.gaoland.net (unknown [86.74.11.11]) by mail.ietf.org (Postfix) with ESMTP id 7FD803A7C25 for ; Mon, 4 Feb 2008 18:11:41 -0800 (PST) Message-ID: <000901c8679c$01767363$0dc17f8e@xgehhwyp> From: "emmerich missirli" <-w@abf.ch> To: Subject: Medical news Date: Tue, 05 Feb 2008 00:26:19 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8679C.01711B31" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C8679C.01711B31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Medical news Click here ------=_NextPart_000_0006_01C8679C.01711B31 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Medical news
Click here ------=_NextPart_000_0006_01C8679C.01711B31-- From owner-namedroppers@ops.ietf.org Tue Feb 5 10:48:33 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 60EC63A72EC; Tue, 5 Feb 2008 10:37:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id A77423A7789; Mon, 4 Feb 2008 16:25:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMBVe-000Gnp-Ar for namedroppers-data@psg.com; Tue, 05 Feb 2008 00:17:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 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 1JMBVb-000GnU-FK for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 00:17:57 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m150HfpT044677; Mon, 4 Feb 2008 19:17:41 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802042353.m14NrR1o018135@drugs.dv.isc.org> References: <200802042353.m14NrR1o018135@drugs.dv.isc.org> Date: Mon, 4 Feb 2008 19:15:39 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: AXFR and TCP Cc: Paul Vixie , Edward Lewis , namedroppers@ops.ietf.org 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:53 +1100 2/5/08, Mark Andrews wrote: > Why? The spec will out live any broken implementations. Especially if it keeps getting derailed... > Within a couple of years of a definitive spec being out > there the vast majority of servers will have been fixed if > they have not already been fixed. For the few remaining > ones you will have a flag that says don't do it for this > machine. My real motivation for asking what I asked is that my hope is to write a strawman approach which makes this new definition backwards compatible with the old. (We can skip new client - new server and old client - old server and skip to the mixed cases.) A new server will have no problem dealing with an old client in this case as this is basically a case of the client getting more aggressive. An old client will be a degenerate form of a new client. How will a new client know it can get away with the new behavior? Alternatively the question can be how will it know if it has to behave the old way? I'm trying to run through my mind a scenario in which a new client sends two AXFR requests down the pipe, and/or a bunch of other requests, etc. I think the only serious problem is the multiple concurrent responses without query IDs or question sections. > A server that doesn't support multiplexed responses will > just serialise the response. If a client doesn't want to > handle multipleplexed responses will just wait until the > final soa to ask the query. Each side is independently > capable of enforcing what it supports without any extensions. I can imagine that an old server might have a different failure mode or two, such as being single threaded on a TCP connection or being taught to panic if two requests come in. That's why I'm asking. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 incarcerated5@informationsphere.com Tue Feb 5 10:48:48 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id A00B73A78F8; Tue, 5 Feb 2008 10:38:00 -0800 (PST) Received: from rrcs-24-106-169-201.se.biz.rr.com (rrcs-24-106-169-201.se.biz.rr.com [24.106.169.201]) by mail.ietf.org (Postfix) with ESMTP id 7F1CA3A7208 for ; Mon, 4 Feb 2008 13:53:56 -0800 (PST) Received: from [24.106.169.201] by mail.informationsphere.com; Mon, 4 Feb 2008 16:55:31 -0500 From: "Dustin Hurley" To: Subject: FuckstickPuffyLogan Date: Mon, 4 Feb 2008 16:55:31 -0500 Message-ID: <01c8674e$c0370380$c9a96a18@incarcerated5> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 Importance: Normal X-Antivirus: avast! (VPS 080123-2, 01/23/2008), Outbound message X-Antivirus-Status: Clean DickMonstrousLionel http://www.rockosmro.com From fyuqg@adelphia.com Tue Feb 5 10:48:52 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 9540E3A6EA7; Tue, 5 Feb 2008 10:52:51 -0800 (PST) Received: from pool-71-114-55-36.washdc.dsl-w.verizon.net (pool-71-114-55-36.washdc.dsl-w.verizon.net [71.114.55.36]) by mail.ietf.org (Postfix) with ESMTP id 65F823A7959 for ; Mon, 4 Feb 2008 17:08:06 -0800 (PST) Message-ID: <000601c86793$04010680$148ec99c@wtbqq> From: "bartram madhu" To: Subject: Wide spectrum of boner enlargers! Date: Mon, 04 Feb 2008 23:19:45 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C86793.03FDC4FD" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C86793.03FDC4FD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =09The meds you need, reliable and hassle free!=20 =09Top products of top brands. Low pricing, discounts, flawless customer = support. =09Millions of customers just can't be wrong! =09thusstill.com =09 =20 ------=_NextPart_000_0003_01C86793.03FDC4FD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=09

The meds = you need, reliable and hassle free!
=09Top products of top brands. Low pricing, discounts, flawless customer = support.
=20 =09Millions of customers just can't be wrong!

=09 =09
------=_NextPart_000_0003_01C86793.03FDC4FD-- From havelock@myrealbox.com Tue Feb 5 10:49:07 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id F237F3A7281; Tue, 5 Feb 2008 10:42:18 -0800 (PST) Received: from 201.20.242.214.user.ajato.com.br (201.20.242.214.user.ajato.com.br [201.20.242.214]) by mail.ietf.org (Postfix) with ESMTP id 9CC3A28DA95 for ; Tue, 5 Feb 2008 10:13:14 -0800 (PST) Message-ID: <000801c86822$0354d9b1$552d6d98@pfbdcrxh> From: "kelvin miki" To: Subject: CIA-LIS - From a pharmacy that believes in providing excellent services and the cheapest pr_ic_es Date: Tue, 05 Feb 2008 16:27:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C86822.034F174E" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C86822.034F174E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is not known whether tadalafil passes into breast milk. Tadalafil = should not be taken by women. CIA-LIS - From a pharmacy that believes in providing excellent services = and the cheapest pr_ic_es best onliine dru-gstore ------=_NextPart_000_0005_01C86822.034F174E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is not known whether tadalafil passes into breast milk. Tadalafil = should not be taken by women.

CIA-LIS - From a = pharmacy that believes in providing excellent services and the cheapest = pr_ic_es best onliine dru-gstore

------=_NextPart_000_0005_01C86822.034F174E-- From uneasinessxgp@stefsegers.com Tue Feb 5 10:53:39 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id C87903A77BC; Tue, 5 Feb 2008 10:37:55 -0800 (PST) Received: from 87-248-184-53.starnet.md (unknown [87.248.184.53]) by mail.ietf.org (Postfix) with ESMTP id C6EF528D554 for ; Tue, 5 Feb 2008 08:40:16 -0800 (PST) Received: from [87.248.184.53] by mail.stefsegers.com; Tue, 4 Feb 2008 18:41:50 +0200 Message-ID: <01c8675d$9a652b00$35b8f857@uneasinessxgp> From: "Marcel Robison" To: Subject: Out of the 5,000 males who participated, the average gain after 5 months was 3.02 inches! Date: Tue, 4 Feb 2008 18:41:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8675D.9A652B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8675D.9A652B00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Fifth/Sixth month you will notice an increase in penis size of up to 4 in= ches, plus a increase in Girth (Width) of 20%, plus all the benefits of t= he first month. You can expect an increase ranging from 1 to 4 inches in = length after a 4 month supply, but we do recommend the 6 month package fo= r better results and higher savings.http://duddiest.comFirst month you wi= ll notice an increase in penis size of up to 1/2 inch, you will also noti= ce an increase in sexual desire, stronger erections and more enjoyable se= x. ------=_NextPart_000_0007_01C8675D.9A652B00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Fifth/Sixth month you will notice an inc= rease in penis size of up to 4 inches, plus a increase in Girth (Width) o= f 20%, plus all the benefits of the first month. You can expect an increa= se ranging from 1 to 4 inches in length after a 4 month supply, but we do= recommend the 6 month package for better results and higher savings.
First month you will notice an increase = in penis size of up to 1/2 inch, you will also notice an increase in sexu= al desire, stronger erections and more enjoyable sex.
 
------=_NextPart_000_0007_01C8675D.9A652B00-- From owner-namedroppers@ops.ietf.org Tue Feb 5 10:54:12 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id DA3713A76C6; Tue, 5 Feb 2008 10:38:02 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id DEC3E3A84ED; Mon, 4 Feb 2008 21:09:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFwf-000Ptl-Ol for namedroppers-data@psg.com; Tue, 05 Feb 2008 05:02:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 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 1JMFwZ-000PqL-Ke for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 05:02:08 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m15506dC008844; Tue, 5 Feb 2008 12:00:06 +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 m1550M6m000671; Tue, 5 Feb 2008 12:00:24 +0700 (ICT) From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) In-Reply-To: <47A7DF09.9030101@chrysler.com> References: <47A7DF09.9030101@chrysler.com> <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> <47A2D2AC.4050609@nlnetlabs.nl> <47A38A72.9090208@chrysler.com> <47A4D0BF.30309@gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Feb 2008 12:00:22 +0700 Message-ID: <2216.1202187622@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Mon, 04 Feb 2008 22:59:05 -0500 From: Kevin Darcy Message-ID: <47A7DF09.9030101@chrysler.com> | My interpretation is that, since the NS RRset is not "required" in this | response, then TC shouldn't be set. You're right, provided that you make it clear that none of the NS RRSet is actually included in the message in this case. I think you're seeing an argument against that which doesn't really exist, and was all based upon a misunderstanding of the situation. | As a fanciful analogy, setting TC=1 and triggering a TCP retry in this | case strikes me as similar to one's significant-other saying: "Thanks, | honey, for making the emergency run to the drug store to get my | life-saving prescription pills, but since you didn't also bring the | chocolate bar that you usually buy when you shop at that store, I'm | going to have to send you back on another trip. See you in another 15 | minutes". Actually, that's a very poor analogy. The right one along the same lines would be: "honey" arrives at the pharmacy to get the pills, and discovers that (s)he doesn't have enough space in his/her pockets/purse (or perhaps insufficient finances) for both the pills and the chocolate bar that always comes home too (though there would have been space/money for either one alone). So, "honey" returns home with nothing, changes to clothes with more pockets (or a larger purse, or more cash) returns to the pharmacy, obtains both pills and chocolate, then returns home to be told "thanks honey, but I didn't really need that chocolate today, just the pills". (And then if you want to over-dramatise, "pity I died waiting for those pills while you were running around backwards and forwards...") | If "non-conformant" is the consensus of the WG, while at the same time | folks want to condone the behavior of the particular implementation in | question, There is no need to condone it, but we do need to recognise that it exists (broken implementations in the DNS world have mostly been the norm rather than the exception) and live with it. 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 DarinwithdrawalClayton@jessicacosmetics.com Tue Feb 5 10:55:04 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 873ED3A6E84; Tue, 5 Feb 2008 10:52:52 -0800 (PST) Received: from aelvdpo96ebcic.home (unknown [88.231.180.52]) by mail.ietf.org (Postfix) with SMTP id 6BBE03A79DC; Mon, 4 Feb 2008 17:16:23 -0800 (PST) Received: from abscess by jessicacosmetics.com with SMTP id 9CRk2J9tH7 for ; Tue, 5 Feb 2008 03:17:50 -0200 From: "Timmy Huff" To: Subject: Your own privater Vegas! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080205011624.6BBE03A79DC@mail.ietf.org> Date: Mon, 4 Feb 2008 17:16:23 -0800 (PST) Get $2400 you download our casino. Get $2400 you download our casino. Come find out. Win $$$ instead of throwing it all away at other casinos. http://bearte.net.cn/ From BrettleftwardCastillo@indepthinfo.com Tue Feb 5 10:55:47 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 21AE93A7EB4; Tue, 5 Feb 2008 10:38:05 -0800 (PST) Received: from pc874327538168.home (unknown [86.159.51.68]) by mail.ietf.org (Postfix) with SMTP id 0E7333A7409; Mon, 4 Feb 2008 15:10:35 -0800 (PST) Message-ID: <16a1501c86783$5c67eab0$4b01a8c0@PC874327538168> From: "Ben Fields" To: Subject: Fast Business Loans Date: Mon, 4 Feb 2008 23:11:58 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_16A11_01C86783.5C67EAB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 This is a multi-part message in MIME format. ------=_NextPart_000_16A11_01C86783.5C67EAB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE cash to spend ANY = way you like or require Extra money to give your business a boost or = need A low interest loan - NO STRINGS ATTACHED! Don't worry about approval... your credit will not disqualify you! http://bearte.com.cn/ ------=_NextPart_000_16A11_01C86783.5C67EAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
If you have your own = business and=20 wish IMMEDIATE cash to spend ANY way you like or wish Extra money to = give the=20 business a boost or want A low interest loan - NO STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 your credit report will not disqualify you!
=20
http://bearte.com.cn/
------=_NextPart_000_16A11_01C86783.5C67EAB0-- From owner-namedroppers@ops.ietf.org Tue Feb 5 10:55:58 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E8FDD3A7CFF; Tue, 5 Feb 2008 10:38:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 7691F3A6FC2; Mon, 4 Feb 2008 14:26:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM9e8-0002tO-AN for namedroppers-data@psg.com; Mon, 04 Feb 2008 22:18:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JM9e5-0002t6-FF for namedroppers@ops.ietf.org; Mon, 04 Feb 2008 22:18:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7DCC11143C; Mon, 4 Feb 2008 22:18:27 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: AXFR and TCP In-Reply-To: Your message of "Mon, 04 Feb 2008 15:59:30 EST." References: X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 04 Feb 2008 22:18:27 +0000 Message-ID: <35857.1202163507@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > It's possible to chain and multiplex zone transfers on the connection if > the TCP connection management is independent of the AXFR session > management. I know this can be done. But does any code do this now? it's common to open a TCP session, ask the SOA query, and then, using the same TCP session, ask for an AXFR. i know of implementations like that. i do not know of any current implementation that reuses the TCP session again after an AXFR, but the spec allows it. it's also possible, using a widely popular stub resolver implementation, to open a TCP session and use it for a multiple queries. none of this is parallelized in any implementation i'm aware of. so, the query ID of the response isn't being used to demultiplex against multiple outstanding requests. one of the reasons we don't do that is that some DNS TCP implementations do not put the query ID into every message of an AXFR response. the spec does not prohibit parallelism. a conforming implementation could spew requests down a TCP session, suck up the responses that come back (in any order), demux based on query-ID, and get "query windowing"; however, that implementation would not be widely interoperable at this time, and the spec should probably be updated to prohibit parallelism and demultiplexing. > With the cheapness of just doing non-AXFR queries over UDP, why would a > client go out of its way to use an open TCP connection (if its there) or go > out of its way to open and sustain an TCP connection instead of just > sending via UDP? long story, many possible answers. there are valid reasons to do this. > It seems too much work for me to have to keep a list of machines with which > I have an open TCP session so I know if I shoulf shunt a query to the UDP > or TCP transport managers. then when you are acting as an implementor, you should not do it that way. > So - does any code today multiplex zone transfers (between a pair of > processes) or use the TCP connection for more than AXFR (and TC induced > retries)? Does any code maintain open TCP connections with other servers > when "idle?" see above. it's possible that a number of things not prohibited by the current spec need to get prohibited since they would not actually work. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From RosannewombBlackman@eyecandypromo.com Tue Feb 5 10:56:48 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 8096E3A6E2F; Tue, 5 Feb 2008 10:38:00 -0800 (PST) Received: from user6106bd3de2.hsd1.md.comcast.net (c-68-55-245-160.hsd1.md.comcast.net [68.55.245.160]) by mail.ietf.org (Postfix) with SMTP id 761F228C1FA; Tue, 5 Feb 2008 05:14:28 -0800 (PST) Received: from cluster by eyecandypromo.com with SMTP id kE4aNRmMHs for ; Tue, 5 Feb 2008 08:15:18 +0500 From: "Josefa Rudd" To: Subject: Slots, multi-hand, and single-hand blackjack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080205131428.761F228C1FA@mail.ietf.org> Date: Tue, 5 Feb 2008 05:14:28 -0800 (PST) Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. After thatit's only fun and winning. Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. Our safe, secure games will get you smiling when you start seeing dollars pouring in. http://bearti.cn/ From indonesianhrdj58@mezzaninespa.com Tue Feb 5 10:57:33 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 256D83A7E5C; Tue, 5 Feb 2008 10:52:49 -0800 (PST) Received: from [88.227.89.60] (unknown [88.227.89.60]) by mail.ietf.org (Postfix) with ESMTP id B12353A7BE8 for ; Mon, 4 Feb 2008 18:06:58 -0800 (PST) Received: from [88.227.89.60] by mx01-dom.earthlink.net; Tue, 5 Feb 2008 04:08:31 +0200 Message-ID: <01c867ac$c4920980$3c59e358@indonesianhrdj58> From: "Daren Grimm" To: Subject: NewOfferEmedsYourHealth Date: Tue, 5 Feb 2008 04:08:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 ForOurCustomersVisaAcceptedSoftTabs http://walkfield.com From maoistsyvd15@kidneyportal.com Tue Feb 5 10:57:53 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 90AE83A7FFB; Tue, 5 Feb 2008 10:37:54 -0800 (PST) Received: from 85-95-173-114.saransk.ru (85-95-173-114.saransk.ru [85.95.173.114]) by mail.ietf.org (Postfix) with ESMTP id E36D828CB88 for ; Tue, 5 Feb 2008 06:23:22 -0800 (PST) Received: from [85.95.173.114] by smtp.secureserver.net; Tue, 5 Feb 2008 17:24:56 +0300 From: "Nettie Foreman" To: Subject: JerryBroadShlong Date: Tue, 5 Feb 2008 17:24:56 +0300 Message-ID: <01c8681c$06a66400$72ad5f55@maoistsyvd15> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal MonumentalErectileorganClarice http://www.verybestoff.com From clydetroubling4982079@yahoo.com Tue Feb 5 11:00:03 2008 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4F7A53A68B9; Tue, 5 Feb 2008 10:53:01 -0800 (PST) Received: from host13-213-dynamic.15-87-r.retail.telecomitalia.it (host13-213-dynamic.15-87-r.retail.telecomitalia.it [87.15.213.13]) by mail.ietf.org (Postfix) with SMTP id A85D83AA28F; Tue, 5 Feb 2008 05:01:28 -0800 (PST) Received: from 102.126.240.168 by 87.15.213.13; Tue, 05 Feb 2008 07:59:54 -0500 Message-ID: From: "Jed Varner" Reply-To: "Jed Varner" To: dhcwg-request@ietf.org Subject: Repl1ca watch is a perfect gift! Date: Tue, 05 Feb 2008 08:03:54 -0500 MIME-Version: 1.0 X-Antivirus: avast! (VPS 080131-1, 31/01/2008), Outbound message X-Antivirus-Status: Clean Newest 2008 repl1ca watch3s collection! 15% off in February and huge choose of repl1cas! http://www.oisoiske.com/ From owner-namedroppers@ops.ietf.org Tue Feb 5 11:01:22 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 1A44E3A6F03; Tue, 5 Feb 2008 10:52:53 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 90DD83AA234; Tue, 5 Feb 2008 04:55:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMN7V-000Aks-9T for namedroppers-data@psg.com; Tue, 05 Feb 2008 12:41:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMN7P-000Ak9-JH for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 12:41:44 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35182) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1JMN7E-0008WN-NL (Exim 4.67) (return-path ); Tue, 05 Feb 2008 12:41:32 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1JMN7E-00082m-76 (Exim 4.67) (return-path ); Tue, 05 Feb 2008 12:41:32 +0000 Date: Tue, 5 Feb 2008 12:41:32 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Vixie cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP In-Reply-To: <35857.1202163507@sa.vix.com> Message-ID: References: <35857.1202163507@sa.vix.com> User-Agent: Alpine 1.00 (LSU 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mon, 4 Feb 2008, Paul Vixie wrote: > > none of this is parallelized in any implementation i'm aware of. so, > the query ID of the response isn't being used to demultiplex against > multiple outstanding requests. ADNS can have multiple outstanding queries on a TCP connection. > Edward Lewis wrote: > > > > With the cheapness of just doing non-AXFR queries over UDP, why would a > > client go out of its way to use an open TCP connection (if its there) or go > > out of its way to open and sustain an TCP connection instead of just > > sending via UDP? ADNS keeps the TCP connection open so it is ready to handle fallback queries for truncated replies. > however, that implementation would not be widely interoperable at this > time, It has been doing this for over 10 years and there have been no bug reports about its TCP behaviour. ADNS doesn't do AXFR, and because it only uses TCP for TC fallback, it doesn't usually depend heavily on concurrent TCP queries. Tony. -- f.a.n.finch http://dotat.at/ TYNE DOGGER: SOUTHWEST VEERING NORTHWEST 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN DOGGER. MODERATE OR ROUGH. SHOWERS. GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From AdrianpensiveGarrett@thehistoryof.net Tue Feb 5 11:01:40 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id F21EE3A7C50; Tue, 5 Feb 2008 10:52:47 -0800 (PST) Received: from thuiswbjonywsg.belkin (a100030.upc-a.chello.nl [62.163.100.30]) by mail.ietf.org (Postfix) with SMTP id 2B74D28D1D7; Tue, 5 Feb 2008 07:56:02 -0800 (PST) Message-ID: <195dc01c8680f$d278f640$0602a8c0@thuiswbjonywsg> From: "Mitchell Morrison" To: Cc: , =20
If you have your own = business and=20 want IMMEDIATE money to spend ANY way you like or require Extra money to = give=20 the company a boost or require A low interest loan - NO STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 your credit report will not disqualify you!
=20
http://beartd.com.cn/
------=_NextPart_000_195D8_01C8680F.D278F640-- From owner-namedroppers@ops.ietf.org Tue Feb 5 11:01:58 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D01C63A7A71; Tue, 5 Feb 2008 10:43:10 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 5692D3A78B1; Mon, 4 Feb 2008 16:54:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMBxV-000JsD-Ta for namedroppers-data@psg.com; Tue, 05 Feb 2008 00:46:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JMBxS-000Jrb-VP for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 00:46:44 +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 m150kXZ1018895; Tue, 5 Feb 2008 11:46:34 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802050046.m150kXZ1018895@drugs.dv.isc.org> To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: AXFR and TCP In-reply-to: Your message of "Mon, 04 Feb 2008 19:15:39 CDT." Date: Tue, 05 Feb 2008 11:46:33 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > A server that doesn't support multiplexed responses will > > just serialise the response. If a client doesn't want to > > handle multipleplexed responses will just wait until the > > final soa to ask the query. Each side is independently > > capable of enforcing what it supports without any extensions. > > I can imagine that an old server might have a different failure mode > or two, such as being single threaded on a TCP connection or being > taught to panic if two requests come in. That's why I'm asking. A client that panics with two requests is already broken and is ripe for a DoS attack. Handling one request at a time just serialises the response. I presume that what you mean by "single threaded on a TCP connection". 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 Tue Feb 5 11:02:36 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D23A23A7C7A; Tue, 5 Feb 2008 10:37:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id E28213A8499; Mon, 4 Feb 2008 21:00:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFpX-000OYK-9R for namedroppers-data@psg.com; Tue, 05 Feb 2008 04:54:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JMFpU-000OXz-D1 for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 04:54: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 m154sZAu096969; Tue, 5 Feb 2008 15:54:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802050454.m154sZAu096969@drugs.dv.isc.org> To: Paul Vixie Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: AXFR and TCP In-reply-to: Your message of "Tue, 05 Feb 2008 04:43:16 -0000." <54653.1202186596@sa.vix.com> Date: Tue, 05 Feb 2008 15:54:35 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > > ... > > > the spec does not prohibit parallelism. a conforming implementation > > > could spew requests down a TCP session, suck up the responses that come > > > back (in any order), demux based on query-ID, and get "query windowing"; > > > however, that implementation would not be widely interoperable at this > > > time, and the spec should probably be updated to prohibit parallelism > > > and demultiplexing. > > > > Why? The spec will out live any broken implementations. > > then we should update the spec to say, this might not work, here's what it > could look like when you try it, here's what you should do when it fails. > > > A server that doesn't support multiplexed responses will > > just serialise the response. If a client doesn't want to > > handle multipleplexed responses will just wait until the > > final soa to ask the query. Each side is independently > > capable of enforcing what it supports without any extensions. > > if a server can answer in order A-C-B when asked questions in order A-B-C, > then a client who does not look at the query-ID since it "knows" that the > order will be respected, will fail, and might have no backoff capability. > (granted, such a client would be unlikely to send request B before getting > response A, but the spec is a minefield that could make that look safe.) netstat did just that. If it timed out waiting for the server it would ask for C even if it hadn't a reply for B. This all works for ordinary queries. Even BIND 4 did this right for ordinary queries. The only time when things get messy is when you start throwing in AXFR responses that don't follow the basic requirements of DNS (response id = query id). 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 yermi1964@ACKATTACK.COM Tue Feb 5 11:02:46 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 1785E3A801A; Tue, 5 Feb 2008 10:37:55 -0800 (PST) Received: from static-76-161-226-88.dsl.cavtel.net (static-76-161-226-88.dsl.cavtel.net [76.161.226.88]) by mail.ietf.org (Postfix) with ESMTP id C617F3A8484 for ; Mon, 4 Feb 2008 20:55:32 -0800 (PST) Message-ID: <000c01c867b3$8e5919b0$58e2a14c@leonarddbbc8e5> From: "Robert ernestberg" To: dnsext-archive@lists.ietf.org Subject: Gain several inches on your weener with this new medical discovery. Date: Mon, 4 Feb 2008 23:57:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C86789.A58311B0" 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 ----------=_NextPart_000_0008_01C86789.A58311B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never feel inadequate again with your brand new huge p3nis. ----------=_NextPart_000_0008_01C86789.A58311B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never feel inadequate again with = your brand=20 new huge p3nis. ----------=_NextPart_000_0008_01C86789.A58311B0-- From MaispySkaggs@mississippistudios.com Tue Feb 5 11:03:31 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 3B8B73A6EBB; Tue, 5 Feb 2008 10:37:57 -0800 (PST) Received: from yourno383kfcix.kornet (unknown [121.185.221.2]) by mail.ietf.org (Postfix) with SMTP id 84A6728C3D0; Tue, 5 Feb 2008 05:27:57 -0800 (PST) Message-ID: <195ff01c867fb$24b91260$02ddb979@yourno383kfcix> From: "Enid Pereira" To: Cc: , =20
If you have your own = business and=20 need IMMEDIATE ready money to spend ANY way you like or wish Extra money = to=20 give your business a boost or require A low interest loan - NO = STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 credit score will not disqualify you!
=20
http://beartd.cn/
------=_NextPart_000_195FB_01C867FB.24B91260-- From owner-namedroppers@ops.ietf.org Tue Feb 5 11:04:17 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 12D7B3A696C; Tue, 5 Feb 2008 10:37:59 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id AD22B3A8285; Mon, 4 Feb 2008 20:11:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMExh-000HEb-O4 for namedroppers-data@psg.com; Tue, 05 Feb 2008 03:59:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [129.9.40.82] (helo=odvirpr6.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMExe-000HE5-VP for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 03:59:08 +0000 Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.99.241]) by odvirpr6.extra.daimlerchrysler.com (Postfix) with SMTP id 6E3F6162193 for ; Mon, 4 Feb 2008 22:59:05 -0500 (EST) Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008020422590517736 for ; Mon, 04 Feb 2008 22:59:05 -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 m153x5XE023544 for ; Mon, 4 Feb 2008 22:59:05 -0500 (EST) Message-ID: <47A7DF09.9030101@chrysler.com> Date: Mon, 04 Feb 2008 22:59:05 -0500 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> <47A2D2AC.4050609@nlnetlabs.nl> <47A38A72.9090208@chrysler.com> <47A4D0BF.30309@gis.net> In-Reply-To: <47A4D0BF.30309@gis.net> 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 Danny Mayer wrote: > Kevin Darcy wrote: >> Wouter Wijngaards wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Kevin Darcy wrote: >>> | Danny Mayer wrote: >>> |> There are many solutions to improving the design of the >>> architected or >>> |> mis-architected configuration, but the protocol needs to work for >>> all >>> |> situations including this one. So setting the TC bit is the correct >>> |> answer. >>> >>> I agree with Danny. >>> >>> | Non sequitur. The protocol "works" whether TC is clear or not: if >>> it's >>> | clear, the client takes the answer as it finds it and queries the >>> | "missing" NS records as necessary; if TC is set, then the client >>> | (typically) will retry the query using TCP, thus obtaining the answer >>> | and all of the NS records that wouldn't fit in the initial response. >>> >>> Well, your use of the protocol works without the NS records. The DNS is >>> robust. The DNS protocol as widely used, needs those NS records to help >>> resolvers find nameservers more efficiently. So what is querying for >>> the >>> SOA record that cannot retry with TCP? (This is your local subnet, so >>> speed is not that much of a problem?) >>> >>> Can you deploy EDNS? That is the other obvious solution. >> Already deployed. The advertised buffer size is 2048 which is still >> not big enough to fit all of the NS records. >>> >>> | The main question is whether an implementation which sets TC under >>> these >>> | circumstances conforms to RFC 2181. A follow-on question would be >>> | whether RFC 2181 needs to be amended for situations such as this one. >>> >>> What is the problem with a TC bit on a SOA answer? >> Besides the wastefulness of an unnecessary TCP retry, it causes >> execution of a code branch that has an unfortunate end result. >> >> But, I don't want to whine about the coding of a particular >> implementation. My focus here is on the question of standards >> conformance. Apparently we still don't have a consensus answer on that. > > I think we *do* have consensus on it. You just don't want to accept > it. I have seen no response indicating that the RFC should be changed. > True, we don't have anyone suggesting, so far, that RFC 2181 be changed. But, there have been diverse opinions on whether the behavior I described conforms to the RFC or not. We don't, as I see it, have a consensus on that question. Again, I quote the language (Section 9): The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. and ask: Does a nameserver implementation which can fit an answering RRset in the Answer Section of a response, given the EDNS0 buffer size in effect, and is configured to normally also provide the apex NS RRset of the zone in the Authority Section, but cannot, for this specific response, due to the fact that the RRset is too large to fit, have license to set TC=1, with the answering RRset in the Answer Section and an empty Authority Section? My interpretation is that, since the NS RRset is not "required" in this response, then TC shouldn't be set. The "extra information" referred to by the RFC 2181 verbiage is stated to "include[] the results of additional section processing", but I don't see it as *limited* to that. So presumably it also applies to "extra information" that might normally be provided in the Authority Section. To my knowledge, the only information in an Authority Section which is ever *required* is o an NS RRset in a referral response o one or more DNSSEC-related records (? again, showing my DNSSEC ignorance) neither of which apply in the case in question. As a fanciful analogy, setting TC=1 and triggering a TCP retry in this case strikes me as similar to one's significant-other saying: "Thanks, honey, for making the emergency run to the drug store to get my life-saving prescription pills, but since you didn't also bring the chocolate bar that you usually buy when you shop at that store, I'm going to have to send you back on another trip. See you in another 15 minutes". If "non-conformant" is the consensus of the WG, while at the same time folks want to condone the behavior of the particular implementation in question, then RFC 2181 would need to be amended to allow it. (Generally speaking, I have a dim view of amending standards-track RFCs in order to accommodate the quirks of individual implementations; code should conform to standards, not the other way around). - 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 Tue Feb 5 11:04:38 2008 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 489C53A7296; Tue, 5 Feb 2008 10:38:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 7D46A3A7564; Mon, 4 Feb 2008 15:38:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMAnQ-000BQZ-Kn for namedroppers-data@psg.com; Mon, 04 Feb 2008 23:32:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 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 1JMAnN-000BOZ-DK for namedroppers@ops.ietf.org; Mon, 04 Feb 2008 23:32:15 +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 m14NVxPN017889; Tue, 5 Feb 2008 10:32:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802042332.m14NVxPN017889@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: AXFR and TCP In-reply-to: Your message of "Mon, 04 Feb 2008 15:59:30 CDT." Date: Tue, 05 Feb 2008 10:31:59 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I am going over the AXFR on TCP part of the -07 draft. Reading some > comments and contrasting with some on this list I wanted to find out > what's really happening now as opposed to what could be. > > My vision of an AXFR session is, client opens a connection, asks, > gets, closes connection, session over. That seems quite trivial, > something I can do with dig, etc. You should be asking what nameservers need. dig's requirements are trivial compared to a nameserver's requirements. > It's possible to chain and multiplex zone transfers on the connection > if the TCP connection management is independent of the AXFR session > management. I know this can be done. But does any code do this now? Not that I am aware of. It's been one of my plans for a long time. It should provide benifits for nameservers that slave lots of zones from the same master. > With the cheapness of just doing non-AXFR queries over UDP, why would > a client go out of its way to use an open TCP connection (if its > there) or go out of its way to open and sustain an TCP connection > instead of just sending via UDP? Because sending a IXFR query over a open TCP session always succeeds. IXFR over UDP may tell you to use TCP. Once the connection is available there is almost zero cost to use it. UDP queries put all the retry logic in the server. IXFR+EDNS+UDP requires a lot retry logic to handle packet loss and broken firewalls. > It seems too much work for me to have to keep a list of machines with > which I have an open TCP session so I know if I shoulf shunt a query > to the UDP or TCP transport managers. A nameserver usually keeps this list as a by product of having the TCP session open. There is no extra work to keep the list, just a litte extra code to use it instead of opening a new session. > So - does any code today multiplex zone transfers (between a pair of > processes) or use the TCP connection for more than AXFR (and TC > induced retries)? Does any code maintain open TCP connections with > other servers when "idle?" We definitely have transfers that queue awaiting TCP sockets being able to use a existing TCP connection will help. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: -- 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 Feb 5 14:04: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 4A9673A72B5; Tue, 5 Feb 2008 14:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.465 X-Spam-Level: X-Spam-Status: No, score=-4.465 tagged_above=-999 required=5 tests=[AWL=1.834, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7F1o4TqI6ZQ; Tue, 5 Feb 2008 14:04:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4A85D3A88E1; Tue, 5 Feb 2008 13:44:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMUn5-0006HR-VL for namedroppers-data@psg.com; Tue, 05 Feb 2008 20:53:15 +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 1JMUn2-0006H2-Pa for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 20:53:14 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m15KquAf052697; Tue, 5 Feb 2008 15:52:57 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200801241202.NAA10663@TR-Sys.de> References: <200801241202.NAA10663@TR-Sys.de> Date: Tue, 5 Feb 2008 15:48:11 -0500 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Edward Lewis Subject: Re: draft-ietf-dnsext-axfr-clarify-06 Cc: ed.lewis@neustar.biz, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Just a few notes... At 13:02 +0100 1/24/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >(3) Section 2 > >(3a) 3rd paragraph > >I suggest to make the style of quotations to other RFCs consistent >within the document and with common use: I made wholesale changes to that section, placing the titles of the RFCs in the text. Partly because I want to emphasize the meanings behind the RFC numbers. > >Finally, I suggest moving the second pararaph (with message length >considerations) behind this paragraph or to the end of the section, >because it contains more specific information. It's funny to read this because, after making all the changes above, I thought to myself that I needed to do this. Then I read the suggestion. Good timing. >(9) Section 3.2 > >(9a) 1st paragraph > > In RFC 1034, section 4.2.1, this text appears (keep in mind that the > word "should" in the quotation is now deemed to be a "SHOULD" subject > to the interpretation in section 1.1): > "The RRs that describe cuts ... should be exactly the same as the > corresponding RRs in the top node of the subzone." > There has been some controversy over this statement and the impact on > which NS resource records are included in a zone transfer. Also, > DNSSEC [RFC4033] [RFC4034] [RFC4035] specifies particular Resource > Records to be inserted at delegation points in secure zones, and at > the apex of secure zones, respectively, which makes the above > statement inappropriate. In this case I think your edits are reading too much into the situation. The "RRs that describe the cuts" refers to the NS and glue only, generally, and I'll change text to make that explicit. Even before DNSSEC there are deviations between the cut point and the apex, e.g., the SOA record, possible MX, and in the older days, RP and other records. The point was to hit at the issue of whether, given a server that has both parent and child, or can get the child, should insert the child's NS set if there is a difference from the parent's. As far as I could figure, that was the root of the hottest debate on this 5 years ago. DJB wanted to "optimize" the safety of the network by automatically correcting any inconsistency and I understand his motivation. OTOH, good protocol engineering tells me otherwise, that making the error explicit is better for maintenance, troubleshooting, etc. It's a tug of war between theory and practice. So, I don't want to drag DNSSEC in, but I'll have to explain better that this is the issue about differing NS sets. Let me know if that isn't satisfactory. >(11b) >More importantly, I am in serious doubt whether the capability added >by the final sentence is worth the protocol complications it requires. > >To my knowledge (admittedly a bit aged), typical AXFR client >implementations anyway perform the AXFR and local database update >in a dedicated process or thread that does not also perform other >DNS queries. Therefore, a dedicated TCP connection will be used >for one or more AXFRs. That was my general understanding too. But Mark Andrews has been pounding down on me that the open TCP connection is to be used for anything. I don't know why he's so adamant about it but he makes is sound like a matter of life and/or death. I think he's just trying to find more fault with the practice of dropping TCP connections as a defense against unwanted AXFR queries. That's been attributed to DJB but come to think of it, I don't know if even his code does that. I do know he won't answer when it's a lame situation, but that's over UDP. >Serial reuse of a TCP connection for multiple AXFRs (AXFR chaining >on a connection) or even using a (semi-)persistent TCP connection >for other queries/responses in a serialized manner therefore might >be a reasonable feature that can be supported without protocol >complications and/or serious backwards compatibility issues. > >On the other hand, interleaving multi-message AXFR responses with >other DNS query/response traffic seems to be unnecessary and >unnecessarily complicated. Keep in mind that query/response >traffic over UDP can be sustained in parallel without a need >for this extension. Also, paragraph 2 of Section 5 indicates >that regularly, the set of AXFR clients allowed will be restricted >very much, and other queries between sibling authoritative servers >needing TCP are considered less likely. > >That said, my subsequent change proposals nevertheless will carry >on support for this protocol extension. I agree with you. Given a subsequent discussion (which I launched after you sent this but before I read this, i.e., I sat on this a while), I'm going to move the UDP to a separate document. >(12) Section 4.1 I've pretty much completely overhauled the transport text based on discussions, so most of your comments will be used when I prepare the AXFR over UDP document. >(15) Section 5 > >(15a) 1st paragraph > >Please do not omit the most stringent and important restriction >to be observed today: LAW ! I'm a little iffy on that because I'm not a lawyer and am not sure what a "legal requirement is." But I added the change and see if anyone complains. >(15b) last paragraph > >I simply do not understand the sense and purpose of the last sentence: > > An implementation SHOULD allow access to be open to all requests. > >Please supply more specific text, or drop this sentence. It means that an implementation should give the the operator the option to say that anyone can request an AXFR. Like "allow-transfer { all; };" >(17) Section 12 >- Please use > (or any mirrored or derived file) as the base for content, style, > and punctuation in entries of the References section. That's what I did...I used the rfc-index file I guess. That's what there are those insane "."'s all over the place. I'll take a look at that in the next spin. (I wanted to have another version out now before my other work hits.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 5 14:35: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 047633A6F40; Tue, 5 Feb 2008 14:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRqdmtqOfEKU; Tue, 5 Feb 2008 14:35:14 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id ACC333A696C; Tue, 5 Feb 2008 14:13:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMVre-000Gdt-I7 for namedroppers-data@psg.com; Tue, 05 Feb 2008 22:02:02 +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 1JMVrW-000Gct-Q4 for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 22:02:00 +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 m15M1fv5046437; Wed, 6 Feb 2008 09:01:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802052201.m15M1fv5046437@drugs.dv.isc.org> To: Edward Lewis Cc: Alfred =?hp-roman8?B?SM5uZXM=?= , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-axfr-clarify-06 In-reply-to: Your message of "Tue, 05 Feb 2008 15:48:11 CDT." Date: Wed, 06 Feb 2008 09:01:41 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Just a few notes... > > At 13:02 +0100 1/24/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: > >(3) Section 2 > > > >(3a) 3rd paragraph > > > >I suggest to make the style of quotations to other RFCs consistent > >within the document and with common use: > > I made wholesale changes to that section, placing the titles of the > RFCs in the text. Partly because I want to emphasize the meanings > behind the RFC numbers. > > > >Finally, I suggest moving the second pararaph (with message length > >considerations) behind this paragraph or to the end of the section, > >because it contains more specific information. > > It's funny to read this because, after making all the changes above, > I thought to myself that I needed to do this. Then I read the > suggestion. Good timing. > > >(9) Section 3.2 > > > >(9a) 1st paragraph > > > > In RFC 1034, section 4.2.1, this text appears (keep in mind that the > > word "should" in the quotation is now deemed to be a "SHOULD" subject > > to the interpretation in section 1.1): > > "The RRs that describe cuts ... should be exactly the same as the > > corresponding RRs in the top node of the subzone." > > There has been some controversy over this statement and the impact on > > which NS resource records are included in a zone transfer. Also, > > DNSSEC [RFC4033] [RFC4034] [RFC4035] specifies particular Resource > > Records to be inserted at delegation points in secure zones, and at > > the apex of secure zones, respectively, which makes the above > > statement inappropriate. > > In this case I think your edits are reading too much into the > situation. The "RRs that describe the cuts" refers to the NS and > glue only, generally, and I'll change text to make that explicit. > Even before DNSSEC there are deviations between the cut point and the > apex, e.g., the SOA record, possible MX, and in the older days, RP > and other records. > > The point was to hit at the issue of whether, given a server that has > both parent and child, or can get the child, should insert the > child's NS set if there is a difference from the parent's. As far as > I could figure, that was the root of the hottest debate on this 5 > years ago. DJB wanted to "optimize" the safety of the network by > automatically correcting any inconsistency and I understand his > motivation. OTOH, good protocol engineering tells me otherwise, that > making the error explicit is better for maintenance, troubleshooting, > etc. It's a tug of war between theory and practice. It didn't make the network "safer". It didn't "optimise" anything. It just makes everything worse as the nameservers were no longer doing what they were explicitly told to do. There is a difference between AXFR and NS queries. The latter alway comes from the child zone and is what is required by RFC 1034 when you select the zone to answer the query from. AXFR preserves what it loaded / transfered in and returns this. This includes records that are not below the zone apex. If you don't do that you end up with records that exist only in slaves and in neither of the masters. Having to regularly recover from the effects of merging zone content (which both BIND 4 and BIND 8 did) I know what the correct answer is (and it isn't merge). S1 S2 S3 PARENT -> PARENT CHILD -> CHILD S3 would regularly end up with the wrong NS RRset or glue A records especially when the email informing the admins of S2 of the change arrived before the zone transfer happened. S2 was often a stealth slave so it's transfer was only controled by the SOA timers. I would regularly have to contact the S2's administators and get them to bump the SOA record for PARENT so that another AXFR would be triggered and so all the S3's would re-transfer. Note there were about 80 different S1's all run by different administators. BIND 8 atleast merged the content in a deterministic manner. BIND 4 merge depended on load order and could return different answer before and after reload. I've been there, done that and don't want to go back to chaos. > So, I don't want to drag DNSSEC in, but I'll have to explain better > that this is the issue about differing NS sets. > > Let me know if that isn't satisfactory. > > >(11b) > >More importantly, I am in serious doubt whether the capability added > >by the final sentence is worth the protocol complications it requires. > > > >To my knowledge (admittedly a bit aged), typical AXFR client > >implementations anyway perform the AXFR and local database update > >in a dedicated process or thread that does not also perform other > >DNS queries. Therefore, a dedicated TCP connection will be used > >for one or more AXFRs. > > That was my general understanding too. But Mark Andrews has been > pounding down on me that the open TCP connection is to be used for > anything. I don't know why he's so adamant about it but he makes is > sound like a matter of life and/or death. > > I think he's just trying to find more fault with the practice of > dropping TCP connections as a defense against unwanted AXFR queries. > That's been attributed to DJB but come to think of it, I don't know > if even his code does that. I do know he won't answer when it's a > lame situation, but that's over UDP. > > >Serial reuse of a TCP connection for multiple AXFRs (AXFR chaining > >on a connection) or even using a (semi-)persistent TCP connection > >for other queries/responses in a serialized manner therefore might > >be a reasonable feature that can be supported without protocol > >complications and/or serious backwards compatibility issues. > > > >On the other hand, interleaving multi-message AXFR responses with > >other DNS query/response traffic seems to be unnecessary and > >unnecessarily complicated. Keep in mind that query/response > >traffic over UDP can be sustained in parallel without a need > >for this extension. Also, paragraph 2 of Section 5 indicates > >that regularly, the set of AXFR clients allowed will be restricted > >very much, and other queries between sibling authoritative servers > >needing TCP are considered less likely. > > > >That said, my subsequent change proposals nevertheless will carry > >on support for this protocol extension. > > I agree with you. Given a subsequent discussion (which I launched > after you sent this but before I read this, i.e., I sat on this a > while), I'm going to move the UDP to a separate document. > > >(12) Section 4.1 > > I've pretty much completely overhauled the transport text based on > discussions, so most of your comments will be used when I prepare the > AXFR over UDP document. > > >(15) Section 5 > > > >(15a) 1st paragraph > > > >Please do not omit the most stringent and important restriction > >to be observed today: LAW ! > > I'm a little iffy on that because I'm not a lawyer and am not sure > what a "legal requirement is." But I added the change and see if > anyone complains. > > >(15b) last paragraph > > > >I simply do not understand the sense and purpose of the last sentence: > > > > An implementation SHOULD allow access to be open to all requests. > > > >Please supply more specific text, or drop this sentence. > > It means that an implementation should give the the operator the > option to say that anyone can request an AXFR. Like "allow-transfer > { all; };" > > >(17) Section 12 > > >- Please use > > (or any mirrored or derived file) as the base for content, style, > > and punctuation in entries of the References section. > > That's what I did...I used the rfc-index file I guess. That's what > there are those insane "."'s all over the place. I'll take a look at > that in the next > spin. (I wanted to have another version out now before my other work hits.) > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: -- 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 Feb 5 14:35: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 20CCA3A7286; Tue, 5 Feb 2008 14:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=1.525, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHO2ZMaVx9YS; Tue, 5 Feb 2008 14:35:53 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B0E663A8287; Tue, 5 Feb 2008 14:19:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMW2G-000Ign-6m for namedroppers-data@psg.com; Tue, 05 Feb 2008 22:13:00 +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 1JMW2C-000Ifw-TK for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 22:12:58 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m15MCmQS053356; Tue, 5 Feb 2008 17:12:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802052201.m15M1fv5046437@drugs.dv.isc.org> References: <200802052201.m15M1fv5046437@drugs.dv.isc.org> Date: Tue, 5 Feb 2008 17:12:12 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: draft-ietf-dnsext-axfr-clarify-06 Cc: Edward Lewis 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 9:01 +1100 2/6/08, Mark Andrews wrote: > It didn't make the network "safer". It didn't "optimise" > anything. It just makes everything worse as the nameservers > were no longer doing what they were explicitly told to do. And I know *that* is your opinion. What I wrote is my understanding of DJB's opinion. > I've been there, done that and don't want to go back to chaos. Then let it go. There's no need to repeat your view every time you hear a viewpoint that you do not agree with. Wait and read what's in the -07, I just submitted it. Make comments on the current document and not on history. Let's be polite and civil. Let others have their say. The process of putting into words the definitions we all assume is hard enough without having to fear that someone is going to get angry or raise emotions over the work. There are many rounds of review to go, many viewpoints to listen to. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 5 15:22: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 5034F3A6CC3; Tue, 5 Feb 2008 15:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uo6BKBmu10M; Tue, 5 Feb 2008 15:22:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B98953A6E2D; Tue, 5 Feb 2008 15:04:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMWhp-000PQQ-NH for namedroppers-data@psg.com; Tue, 05 Feb 2008 22:55: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 1JMWhn-000PQ6-6e for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 22:55:56 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m15MtkNT053732; Tue, 5 Feb 2008 17:55:47 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 5 Feb 2008 17:55:45 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: axfr-clarify-07 and axfr-udp-00 submitted Cc: ed.lewis@neustar.biz 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 FYI, two documents submitted. The latter is as an individual submission. I don't think I'll have time to update them again before the cutoffs for the Philly meeting but comments and discussion are welcome of course. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 5 19:47: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 EEBAD3A6800; Tue, 5 Feb 2008 19:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=-3.163, BAYES_50=0.001, FB_SAVE_PERSC=3.199, GB_PHARMACY=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGUYlbBVAqAG; Tue, 5 Feb 2008 19:47:02 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 16B993A67FE; Tue, 5 Feb 2008 19:47:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMb3f-0009JF-SO for namedroppers-data@psg.com; Wed, 06 Feb 2008 03:34:47 +0000 Received: from [129.9.168.76] (helo=shvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMb3d-0009Iy-29 for namedroppers@ops.ietf.org; Wed, 06 Feb 2008 03:34:46 +0000 Received: from shnavip4-hme0.shdc.chrysler.com (unknown [53.231.141.98]) by shvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id 847C810FEE2 for ; Tue, 5 Feb 2008 22:24:59 -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 M2008020522344311922 for ; Tue, 05 Feb 2008 22:34:43 -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 m163Yhkn025283 for ; Tue, 5 Feb 2008 22:34:43 -0500 (EST) Message-ID: <47A92AD3.9010401@chrysler.com> Date: Tue, 05 Feb 2008 22:34:43 -0500 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Clarification Request (Truncation) References: <47A7DF09.9030101@chrysler.com> <47A13D42.6010408@chrysler.com> <200801300931.m0U9VlNk040366@drugs.dv.isc.org> <29787.1201701154@epsilon.noi.kre.to> <6167.1201766291@epsilon.noi.kre.to> <47A2875C.4050801@gis.net> <47A28F95.3020706@chrysler.com> <47A2D2AC.4050609@nlnetlabs.nl> <47A38A72.9090208@chrysler.com> <47A4D0BF.30309@gis.net> <2216.1202187622@epsilon.noi.kre.to> In-Reply-To: <2216.1202187622@epsilon.noi.kre.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 Robert Elz wrote: > Date: Mon, 04 Feb 2008 22:59:05 -0500 > From: Kevin Darcy > Message-ID: <47A7DF09.9030101@chrysler.com> > > | My interpretation is that, since the NS RRset is not "required" in this > | response, then TC shouldn't be set. > > You're right, provided that you make it clear that none of the NS RRSet > is actually included in the message in this case. > > I think you're seeing an argument against that which doesn't really > exist, and was all based upon a misunderstanding of the situation. > > | As a fanciful analogy, setting TC=1 and triggering a TCP retry in this > | case strikes me as similar to one's significant-other saying: "Thanks, > | honey, for making the emergency run to the drug store to get my > | life-saving prescription pills, but since you didn't also bring the > | chocolate bar that you usually buy when you shop at that store, I'm > | going to have to send you back on another trip. See you in another 15 > | minutes". > > Actually, that's a very poor analogy. The right one along the same > lines would be: "honey" arrives at the pharmacy to get the pills, and > discovers that (s)he doesn't have enough space in his/her pockets/purse > (or perhaps insufficient finances) for both the pills and the chocolate bar > that always comes home too (though there would have been space/money for > either one alone). > > So, "honey" returns home with nothing, changes to clothes with more > pockets (or a larger purse, or more cash) returns to the pharmacy, obtains > both pills and chocolate, then returns home to be told "thanks honey, but > I didn't really need that chocolate today, just the pills". (And then > if you want to over-dramatise, "pity I died waiting for those pills while > you were running around backwards and forwards...") > I don't agree with that change to the analogy. The response wasn't *empty*. An answer *was* given (honey came home with the pills), but it was considered suspect because TC=1 (oh, I don't know, maybe honey is a chronic prescription drug abuser and there's a palpable suspicion he/she may have diverted some of the pills to his/her own use). If there is ever a RFC2181bis, I'd probably argue that an exception should probably be made for TC=1 responses that are still usable. This is possible when, for instance, the QTYPE is a "singleton" type --QTYPE=SOA in my original example -- so there is no fear that there might be missing RRs from the Answer Section (instead of pills, maybe the prescription is for a single vial of injectable liquid). (Have we beaten this silly analogy of mine to death yet? :-) > | If "non-conformant" is the consensus of the WG, while at the same time > | folks want to condone the behavior of the particular implementation in > | question, > > There is no need to condone it, but we do need to recognise that it > exists (broken implementations in the DNS world have mostly been the > norm rather than the exception) and live with it. > Again, I'm not out to skewer anyone or anything, I'm just trying to clarify which parts of the behavior with which I've been confronted are standards-conformance issues and which parts are questionable/debatable design choices or mere coding quirks. - 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 Tue Feb 5 20:26: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 508A13A6915; Tue, 5 Feb 2008 20:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd0s85xJFltm; Tue, 5 Feb 2008 20:26:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6A5033A67FE; Tue, 5 Feb 2008 20:26:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMblr-000EsA-Bs for namedroppers-data@psg.com; Wed, 06 Feb 2008 04:20:27 +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 1JMblo-000Erp-5f for namedroppers@ops.ietf.org; Wed, 06 Feb 2008 04:20:26 +0000 Received: from hlid.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m164KJbG055621 for ; Tue, 5 Feb 2008 23:20:19 -0500 (EST) (envelope-from namedroppers@hlid.ogud.com) Received: (from namedroppers@localhost) by hlid.ogud.com (8.13.1/8.13.1/Submit) id m164KJQf055620 for namedroppers@ops.ietf.org; Tue, 5 Feb 2008 23:20:19 -0500 (EST) (envelope-from namedroppers) Received: from [212.13.197.229] (helo=chiark.greenend.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMTkp-000Lze-E5 for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 19:46:52 +0000 Received: from [172.18.45.6] (helo=davenant.greenend.org.uk ident=mail) by chiark.greenend.org.uk (Debian Exim 3.36 #1) with esmtp (return-path ian@davenant.greenend.org.uk) id 1JMTkl-0007qz-00; Tue, 05 Feb 2008 19:46:47 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.36 #1) id 1JMTkQ-0001Bh-00 (Debian); Tue, 05 Feb 2008 19:46:26 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18344.48402.621772.272604@davenant.relativity.greenend.org.uk> Date: Tue, 5 Feb 2008 19:46:26 +0000 To: Paul Vixie Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: <35857.1202163507@sa.vix.com> References: <35857.1202163507@sa.vix.com> X-Mailer: VM 7.03 under Emacs 19.34.1 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. ] Paul Vixie writes ("Re: AXFR and TCP "): > none of this is parallelized in any implementation i'm aware of. so, > the query ID of the response isn't being used to demultiplex against > multiple outstanding requests. one of the reasons we don't do that is > that some DNS TCP implementations do not put the query ID into every > message of an AXFR response. As Tony Finch has pointed out, the GNU adns stub resolver (of which I'm the author and maintainer) has been doing multiple outstanding queries on its TCP connections ever since I wrote it. No-one has ever reported any bugs or other problems from this. Normally adns only uses TCP to retry on truncated replies, but applications are free to pass a flag asking it to always use TCP. > the spec does not prohibit parallelism. a conforming implementation > could spew requests down a TCP session, suck up the responses that come > back (in any order), demux based on query-ID, and get "query windowing"; This is exactly what adns does. > however, that implementation would not be widely interoperable at this > time, and the spec should probably be updated to prohibit parallelism > and demultiplexing. It seems interoperable from where I'm sitting. If there is any doubt in anyone's mind that this is permitted, the spec should be clarified. Ian. -- to unsubscribe send a message to namedroppers-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 Feb 5 20:27: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 32CCA3A67FE; Tue, 5 Feb 2008 20:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmPIBT7j+xcz; Tue, 5 Feb 2008 20:27:51 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 77F8A3A67F5; Tue, 5 Feb 2008 20:27:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMbmB-000EuI-GE for namedroppers-data@psg.com; Wed, 06 Feb 2008 04:20:47 +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 1JMbm8-000Eu2-HU for namedroppers@ops.ietf.org; Wed, 06 Feb 2008 04:20:46 +0000 Received: from hlid.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m164KfYf055627 for ; Tue, 5 Feb 2008 23:20:41 -0500 (EST) (envelope-from namedroppers@hlid.ogud.com) Received: (from namedroppers@localhost) by hlid.ogud.com (8.13.1/8.13.1/Submit) id m164KfGM055626 for namedroppers@ops.ietf.org; Tue, 5 Feb 2008 23:20:41 -0500 (EST) (envelope-from namedroppers) Received: from [212.13.197.229] (helo=chiark.greenend.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMTlg-000M5F-St for namedroppers@ops.ietf.org; Tue, 05 Feb 2008 19:47:46 +0000 Received: from [172.18.45.6] (helo=davenant.greenend.org.uk ident=mail) by chiark.greenend.org.uk (Debian Exim 3.36 #1) with esmtp (return-path ian@davenant.greenend.org.uk) id 1JMTlf-00085w-00; Tue, 05 Feb 2008 19:47:43 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.36 #1) id 1JMTlK-0001CU-00 (Debian); Tue, 05 Feb 2008 19:47:22 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18344.48458.756043.807550@davenant.relativity.greenend.org.uk> Date: Tue, 5 Feb 2008 19:47:22 +0000 To: Mark Andrews Cc: Paul Vixie , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: <200802050454.m154sZAu096969@drugs.dv.isc.org> References: <54653.1202186596@sa.vix.com> <200802050454.m154sZAu096969@drugs.dv.isc.org> X-Mailer: VM 7.03 under Emacs 19.34.1 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. ] Mark Andrews writes ("Re: AXFR and TCP "): > The only time when things get messy is when you start > throwing in AXFR responses that don't follow the basic > requirements of DNS (response id = query id). Quite so. adns doesn't do axfr so that isn't an issue; if I were to add axfr as a feature (which is unlikely) it would use a separate connection. Ian. -- to unsubscribe send a message to namedroppers-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 Feb 7 06:19: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 69C7F3A752E; Thu, 7 Feb 2008 06:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xI2+c+BNzpn; Thu, 7 Feb 2008 06:19:03 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C54953A78F3; Thu, 7 Feb 2008 06:19:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JN7M2-000NHS-8F for namedroppers-data@psg.com; Thu, 07 Feb 2008 14:03: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 1JN7Lv-000NGy-IK for namedroppers@ops.ietf.org; Thu, 07 Feb 2008 14:03:48 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m17E3i5N091823 for ; Thu, 7 Feb 2008 09:03:44 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200802071403.m17E3i5N091823@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Feb 2008 09:03:35 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Meeting at IETF-71 ? Mime-Version: 1.0 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 We have a few new active drafts right now, do you see a need for a face to face meeting? I will decide by Monday if DNSEXT is meeting. 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 Feb 7 06:39: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 C18AC3A7858; Thu, 7 Feb 2008 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q956BNH17B72; Thu, 7 Feb 2008 06:39:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E32213A6EE9; Thu, 7 Feb 2008 06:39:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JN7nY-0000Kd-J9 for namedroppers-data@psg.com; Thu, 07 Feb 2008 14:32:20 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JN7nV-0000Ht-TM for namedroppers@ops.ietf.org; Thu, 07 Feb 2008 14:32:19 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id B64161C015B; Thu, 7 Feb 2008 15:32:16 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B153D1C013B; Thu, 7 Feb 2008 15:32:16 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A4F8558EBEB; Thu, 7 Feb 2008 15:32:16 +0100 (CET) Date: Thu, 7 Feb 2008 15:32:16 +0100 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: Re: Meeting at IETF-71 ? Message-ID: <20080207143216.GA19204@nic.fr> References: <200802071403.m17E3i5N091823@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200802071403.m17E3i5N091823@ogud.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-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 Thu, Feb 07, 2008 at 09:03:35AM -0500, Ólafur Guðmundsson /DNSEXT chair wrote a message of 12 lines which said: > We have a few new active drafts right now, do you see a need for a > face to face meeting? Yes, for "profile". And for a serious discussion on truncation (AXFR and reponse size documents). -- to unsubscribe send a message to namedroppers-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 Feb 7 10:09: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 760CE3A79D6; Thu, 7 Feb 2008 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.835 X-Spam-Level: X-Spam-Status: No, score=-4.835 tagged_above=-999 required=5 tests=[AWL=1.764, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au2BXpqw5rfH; Thu, 7 Feb 2008 10:09:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 29FE33A798B; Thu, 7 Feb 2008 10:09:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNB09-000PuE-NF for namedroppers-data@psg.com; Thu, 07 Feb 2008 17:57:33 +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 1JNB07-000Ptj-2C for namedroppers@ops.ietf.org; Thu, 07 Feb 2008 17:57:32 +0000 Received: from [10.31.65.89] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m17HvNdW093288; Thu, 7 Feb 2008 12:57:23 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 7 Feb 2008 12:54:47 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: axfr-clarify-07 and axfr-udp-00 submitted Cc: namedroppers@ops.ietf.org, ed.lewis@neustar.biz 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 I swear I sent them in... At 17:55 -0500 2/5/08, Edward Lewis wrote: >FYI, two documents submitted. > >The latter is as an individual submission. > >I don't think I'll have time to update them again before the cutoffs for >the Philly meeting but comments and discussion are welcome of course. > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Feb 7 14:49: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 EBFB43A7CD7; Thu, 7 Feb 2008 14:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvFj505suzj8; Thu, 7 Feb 2008 14:49:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7FF9A3A7CD9; Thu, 7 Feb 2008 14:49:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNFP8-000At7-GT for namedroppers-data@psg.com; Thu, 07 Feb 2008 22:39:38 +0000 Received: from [2001:1890:1112:1:21c:23ff:fecf:10ec] (helo=core3.amsl.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNFOo-000Aly-03 for namedroppers@ops.ietf.org; Thu, 07 Feb 2008 22:39:37 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2EA353A79EC; Thu, 7 Feb 2008 14:37:02 -0800 (PST) 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-09.txt Message-Id: <20080207223702.2EA353A79EC@core3.amsl.com> Date: Thu, 7 Feb 2008 14:37:02 -0800 (PST) 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-09.txt Pages : 16 Date : 2008-2-7 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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2672bis-dname-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-7143512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-7143512.I-D@ietf.org> --OtherAccess-- --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 Thu Feb 7 16:29: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 0E74B3A6E29; Thu, 7 Feb 2008 16:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO3LP85SPJ7u; Thu, 7 Feb 2008 16:29:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4943C3A69A4; Thu, 7 Feb 2008 16:29:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNGyK-000NpD-5Q for namedroppers-data@psg.com; Fri, 08 Feb 2008 00:20:04 +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 1JNGyH-000NoF-J8 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 00:20:02 +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 m180Jwfp006353 for ; Fri, 8 Feb 2008 11:19:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080019.m180Jwfp006353@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Thu, 07 Feb 2008 14:37:02 -0800." <20080207223702.2EA353A79EC@core3.amsl.com> Date: Fri, 08 Feb 2008 11:19:58 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Section 2.4 and 5.2 are contradictory. The 2nd and 3rd paragraphs of 5.2 should be deleted. It is legal to add/delete records below a NS (and should be for DNAME) they just won't be visible until the DNAME or NS RRsets are remove. In the NS case A and AAAA are visible as glue. You have to allow obscured records to be loaded. 2.4 currently prevents this. Mark 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 SHOULD refuse to load a zone that has data at a domain name subordinate to a domain name owning a DNAME RR. 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 restrictions related to dynamic update. 5.2. Dynamic Update and DNAME Dynamic update for DNAME records works similar to dynamic update for delegating NS records. For example, adding a DNAME obscures names in the zone. DNAME records can be added, changed and removed. Zones containing a DNAME RR MUST NOT accept a dynamic update message that would add a record or delegation with a name existing under a DNAME. A server MUST return an error message with RCODE=YXDOMAIN [RFC2136] in response to a dynamic update message that would add a resource record under a DNAME in the zone. This is similar to a dynamic update request to add a resource record under a delegation NS in a zone. -- 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 Feb 7 16:44: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 B95033A7954; Thu, 7 Feb 2008 16:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuGCN0CTHm-F; Thu, 7 Feb 2008 16:44:08 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 05F413A6A71; Thu, 7 Feb 2008 16:44:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNHEO-000Pko-HQ for namedroppers-data@psg.com; Fri, 08 Feb 2008 00:36:40 +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 1JNHEM-000PkR-0S for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 00:36:39 +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 m180aaM8006465 for ; Fri, 8 Feb 2008 11:36:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080036.m180aaM8006465@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 11:19:58 +1100." Date: Fri, 08 Feb 2008 11:36:36 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I suggest we leave the last paragraph of 3.2. CNAME synthesis out. Servers MUST be able to answer a query for a synthesized CNAME. An answer containing the synthesized CNAME cannot contain an error (since a CNAME has been followed), as per RFC 1034 CNAME rules. The part of RFC 1034 that says this make authoritative and recursive servers inconsistant. I prevents a recursive server have a local copy of a zone which has a CNAME that points to a non-existant name, directly or indirectly. I believe this part of RFC 1034 need to be cleaned up. If we leave the last paragraph out we don't need to revisit this document when we clean up RFC 1034. 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 Thu Feb 7 17:04: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 B61F53A7E76; Thu, 7 Feb 2008 17:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBKCd5VHP3sA; Thu, 7 Feb 2008 17:04:11 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3FAF23A67FC; Thu, 7 Feb 2008 17:03:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNHVb-0001sv-Cn for namedroppers-data@psg.com; Fri, 08 Feb 2008 00:54:27 +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 1JNHVY-0001sZ-OL for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 00:54:26 +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 m180sNt1006595 for ; Fri, 8 Feb 2008 11:54:23 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080054.m180sNt1006595@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 11:36:36 +1100." <200802080036.m180aaM8006465@drugs.dv.isc.org> Date: Fri, 08 Feb 2008 11:54:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > I suggest we leave the last paragraph of 3.2. CNAME synthesis > out. > > Servers MUST be able to answer a query for a synthesized CNAME. An > answer containing the synthesized CNAME cannot contain an error > (since a CNAME has been followed), as per RFC 1034 CNAME rules. > > The part of RFC 1034 that says this make authoritative and > recursive servers inconsistant. I prevents a recursive > server have a local copy of a zone which has a CNAME that > points to a non-existant name, directly or indirectly. I > believe this part of RFC 1034 need to be cleaned up. > > If we leave the last paragraph out we don't need to revisit > this document when we clean up RFC 1034. > > Mark Given the offending text from RFC 1034 is repeated in this document we need to address this issue now rather than wait. 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 Thu Feb 7 17:09: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 2CE3B3A74BF; Thu, 7 Feb 2008 17:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+fmKQ5xjkVx; Thu, 7 Feb 2008 17:09:27 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 705363A72DF; Thu, 7 Feb 2008 17:09:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNHcV-0002fj-7I for namedroppers-data@psg.com; Fri, 08 Feb 2008 01:01:35 +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 1JNHcS-0002ey-6s for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 01:01:34 +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 m1811TCU006831 for ; Fri, 8 Feb 2008 12:01:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080101.m1811TCU006831@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 11:54:23 +1100." Date: Fri, 08 Feb 2008 12:01:29 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Given the offending text from RFC 1034 is repeated in this > document we need to address this issue now rather than > wait. The offending text for reference. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME or DNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit. -- 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 Feb 7 17:28: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 4F0BE3A6A00; Thu, 7 Feb 2008 17:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJJXcOPe3PsL; Thu, 7 Feb 2008 17:28:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 930143A684C; Thu, 7 Feb 2008 17:28:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNHtv-0004Ui-2Q for namedroppers-data@psg.com; Fri, 08 Feb 2008 01:19:35 +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 1JNHts-0004UJ-Dd for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 01:19:33 +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 m181JUc2024071 for ; Fri, 8 Feb 2008 12:19:30 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080119.m181JUc2024071@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 12:01:29 +1100." Date: Fri, 08 Feb 2008 12:19:30 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > Given the offending text from RFC 1034 is repeated in this > > document we need to address this issue now rather than > > wait. > > The offending text for reference. > > If the "*" label does not exist, check whether the name we > are looking for is the original QNAME in the query or a name > we have followed due to a CNAME or DNAME. If the name is > original, set an authoritative name error in the response and > exit. Otherwise just exit. Note we could theoretically fix this for CNAME records by banning CNAMEs that point to non-existant names. We can't however do that for DNAME as there will almost certainly be synthsised CNAMEs that point to non-existant names. If anyone can provide a rational for the quoted text I'd like to hear it. 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 Thu Feb 7 19:15: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 82C6C3A6FD5; Thu, 7 Feb 2008 19:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.392 X-Spam-Level: X-Spam-Status: No, score=-4.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+NnTD+kPs2d; Thu, 7 Feb 2008 19:15:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A311E3A7C9E; Thu, 7 Feb 2008 19:15:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNJY8-000Fwm-Jd for namedroppers-data@psg.com; Fri, 08 Feb 2008 03:05: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 1JNJY5-000FwT-QF for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 03:05:11 +0000 Received: from [192.168.1.106] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1834pJt011808; Thu, 7 Feb 2008 22:04:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802080019.m180Jwfp006353@drugs.dv.isc.org> References: <200802080019.m180Jwfp006353@drugs.dv.isc.org> Date: Thu, 7 Feb 2008 22:03:39 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-1009682602==_ma============" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --============_-1009682602==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:19 +1100 2/8/08, Mark Andrews wrote: > Section 2.4 and 5.2 are contradictory. I'm going to disagree. I see what you are tripping over though. Dynamic update for NS records are quite different from DNAME. For instance, it is fine to add and delete NS records so long as the set is neither brought into existence or deleted altogether. DNAME is a singleton type (i.e., RR set is limited to 1 record). RFC2136, rule 7.6 says "it is not possible to create a zone using this protocol" and rule 7.13 adds "if deleting RRsets, it is not possible to delete either SOA or NS RRsets at the top of a zone." And then there's the sticky case of glue. I was going to argue that similar != the same, but the fact is that DNAME dynamic update is quite different from NS dynamic update. > The 2nd and 3rd paragraphs of 5.2 should be deleted. I think the problem is the wording of the first sentence of 5.2, not the latter two paragraphs. > It is legal to add/delete records below a NS (and should > be for DNAME) they just won't be visible until the DNAME > or NS RRsets are remove. In the NS case A and AAAA are > visible as glue. > > You have to allow obscured records to be loaded. 2.4 > currently prevents this. I don't agree that we have to allow obscured records to be loaded. Why do we "have to"? Why "(and should be for DNAME)?" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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. --============_-1009682602==_ma============ Content-Type: text/html; charset="us-ascii" Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt
At 11:19 +1100 2/8/08, Mark Andrews wrote:
>       Section 2.4 and 5.2 are contradictory.

I'm going to disagree. I see what you are tripping over though.

Dynamic update for NS records are quite different from DNAME. For instance, it is fine to add and delete NS records so long as the set is neither brought into existence or deleted altogether.  DNAME is a singleton type (i.e., RR set is limited to 1 record).

RFC2136, rule 7.6 says "it is not possible to create a zone using this protocol" and rule 7.13 adds "if deleting RRsets, it is not possible to delete either SOA or NS RRsets at the top of a zone."  And then there's the sticky case of glue.

I was going to argue that similar != the same, but the fact is that DNAME dynamic update is quite different from NS dynamic update.

>       The 2nd and 3rd paragraphs of 5.2 should be deleted.

I think the problem is the wording of the first sentence of 5.2, not the latter two paragraphs.

>       It is legal to add/delete records below a NS (and should
>       be for DNAME) they just won't be visible until the DNAME
>       or NS RRsets are remove.  In the NS case A and AAAA are
>       visible as glue.
>
>       You have to allow obscured records to be loaded.  2.4
>       currently prevents this.
I don't agree that we have to allow obscured records to be loaded.  Why do we "have to"?  Why "(and should be for DNAME)?"


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
--============_-1009682602==_ma============-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 7 19:19: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 975F53A7DD4; Thu, 7 Feb 2008 19:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLwMbdfkCn3R; Thu, 7 Feb 2008 19:19:14 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C42483A6FD5; Thu, 7 Feb 2008 19:19:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNJg7-000Gnh-Cc for namedroppers-data@psg.com; Fri, 08 Feb 2008 03:13:27 +0000 Received: from [202.12.29.58] (helo=mint.apnic.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNJg5-000GnN-0W for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 03:13:26 +0000 Received: from dhcp152.apnic.net (dhcp152.apnic.net [202.12.29.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id ECD5DD5F33 for ; Fri, 8 Feb 2008 13:13:23 +1000 (EST) Message-Id: From: George Michaelson To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: call for contributors to the dns-profile document edit process Date: Fri, 8 Feb 2008 13:13:24 +1000 X-Mailer: Apple Mail (2.915) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion I am in the process of bringing up a subversion repository and tracker for the profile draft, and would like to solicit help from people to work on sections. This is in line with Olafur's suggestion of an edit process. -The document has been split out into files/dirs by the XML section blocks, so they can be edited more easily by a group of people. If you are willing to take control of a section, and flesh it out, please can you contact me off-list. I will coordinate and then hand out subversion access. Apart from the general and authoritative server sections, substantive text is needed for the resolvers and middle boxes sections, which could be worked on independently. The internet submission deadline for the 02+ drafts is the 25th of February, so I need your input as quickly as possible if we are to make substantive progress for an 02 draft. I will work on the mails received so far, to put into an issue tracker against the subversion state. I am trying to incrementally include people's texts that I see either converging, or without disagreement, but there are still several outstanding issues around text, and document structure which will probably have to be resolved via the tracker, or face to face in philly. Many thanks for your help to date, -George -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 7 19:22: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 D038C3A6A00; Thu, 7 Feb 2008 19:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[AWL=1.664, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCmA10u76HIR; Thu, 7 Feb 2008 19:22:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D0D823A7E76; Thu, 7 Feb 2008 19:21:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNJhl-000GyQ-9W for namedroppers-data@psg.com; Fri, 08 Feb 2008 03:15: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 1JNJhi-000Gxy-P8 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 03:15:08 +0000 Received: from [192.168.1.106] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m183EnSk011905; Thu, 7 Feb 2008 22:14:51 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802080119.m181JUc2024071@drugs.dv.isc.org> References: <200802080119.m181JUc2024071@drugs.dv.isc.org> Date: Thu, 7 Feb 2008 22:09:20 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 12:19 +1100 2/8/08, Mark Andrews wrote: > Note we could theoretically fix this for CNAME records by > banning CNAMEs that point to non-existant names. It is impossible to definitely decide, in the most general case, if the domain name in the RDATA of the CNAME exists (for the zone's managing process). I.e., if the name is like this: onename.example. CNAME onename.tld. With example. and tld. not mutually served authoritatively by any name server. > If anyone can provide a rational for the quoted text I'd > like to hear it. I assume the quoted text is this: >> If the "*" label does not exist, check whether the name we >> are looking for is the original QNAME in the query or a name >> we have followed due to a CNAME or DNAME. If the name is >> original, set an authoritative name error in the response and >> exit. Otherwise just exit. That text is quite unclear, because what is the status of a name that is below a DNAME? In CNAME it is clear, if you followed a CNAME you were at a name along the way, hence there's something in the answer section. But DNAME the query is rewritten from "some other" name. One way to scratch your head over it is whether a name comes into existence because there's a CNAME record generated by the DNAME? Whether explicitly or implicitly. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Feb 7 19:35: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 E13F33A7E56; Thu, 7 Feb 2008 19:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9ple50r247B; Thu, 7 Feb 2008 19:35:26 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 278673A703D; Thu, 7 Feb 2008 19:35:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNJsr-000IHT-LY for namedroppers-data@psg.com; Fri, 08 Feb 2008 03:26:37 +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 1JNJso-000IH2-Sh for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 03:26:36 +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 m183QTJo045227; Fri, 8 Feb 2008 14:26:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080326.m183QTJo045227@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Thu, 07 Feb 2008 22:03:39 CDT." Date: Fri, 08 Feb 2008 14:26:29 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > Section 2.4 and 5.2 are contradictory. > > I'm going to disagree. I see what you are tripping over though. > > Dynamic update for NS records are quite different from DNAME. For > instance, it is fine to add and delete NS records so long as the set > is neither brought into existence or deleted altogether. DNAME is a > singleton type (i.e., RR set is limited to 1 record). At the apex. It's perfect fine to add and delete NS RRsets at the bottom of zone. DNAME is always at bottom of zone even when it is at the apex. > RFC2136, rule 7.6 says "it is not possible to create a zone using > this protocol" and rule 7.13 adds "if deleting RRsets, it is not > possible to delete either SOA or NS RRsets at the top of a zone." > And then there's the sticky case of glue. > > I was going to argue that similar != the same, but the fact is that > DNAME dynamic update is quite different from NS dynamic update. > > > The 2nd and 3rd paragraphs of 5.2 should be deleted. > > I think the problem is the wording of the first sentence of 5.2, not > the latter two paragraphs. > > > It is legal to add/delete records below a NS (and should > > be for DNAME) they just won't be visible until the DNAME > > or NS RRsets are remove. In the NS case A and AAAA are > > visible as glue. > > > > You have to allow obscured records to be loaded. 2.4 > > currently prevents this. > > I don't agree that we have to allow obscured records to be loaded. > Why do we "have to"? Why "(and should be for DNAME)?" Because you can't ADD a DNAME which obscures some record then STOP and RESTART the server. 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 Feb 8 00:20: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 DDD3D28C11D; Fri, 8 Feb 2008 00:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihsYyRh6Ytb7; Fri, 8 Feb 2008 00:20:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E2AEA28C111; Fri, 8 Feb 2008 00:20:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNOIf-000O7N-ET for namedroppers-data@psg.com; Fri, 08 Feb 2008 08:09:33 +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 1JNOIc-000O72-M7 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 08:09:32 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1889J0O093268; Fri, 8 Feb 2008 09:09:19 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47AC0E2F.30906@nlnetlabs.nl> Date: Fri, 08 Feb 2008 09:09:19 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt References: <200802080326.m183QTJo045227@drugs.dv.isc.org> In-Reply-To: <200802080326.m183QTJo045227@drugs.dv.isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 08 Feb 2008 09:09:20 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: |> I don't agree that we have to allow obscured records to be loaded. |> Why do we "have to"? Why "(and should be for DNAME)?" | | Because you can't ADD a DNAME which obscures some record | then STOP and RESTART the server. | | Mark Hi Mark, Why do we need obscured records? Can't we rule that an added DNAME removes (not obscures) everything below it. And nothing can be added below a DNAME. That would make the draft consistent (but have to say that dynamic update for DNAME is different from NS). What is the current practice for DNAME and dynamic update in existing implementations? How do they handle this - that is what I as an editor want to know before introducing another implementation change :-) Is it handled exactly like NS records now? In that case - can you describe (in text) how that can be put in the draft? Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHrA4vkDLqNwOhpPgRAj9bAJ4oAdG82P5PVNRK8XXvA1s13W5WAgCfd558 cbMONewtfJI61tDCyhRFSSk= =fwIp -----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 Fri Feb 8 00:22: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 C801428C10B; Fri, 8 Feb 2008 00:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebgRfeEU0+41; Fri, 8 Feb 2008 00:22:27 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id F2F5E28C11D; Fri, 8 Feb 2008 00:21:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNONF-000OeM-U1 for namedroppers-data@psg.com; Fri, 08 Feb 2008 08:14:17 +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 1JNONC-000Ob1-SX for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 08:14:16 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m188E0XH093694; Fri, 8 Feb 2008 09:14:01 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47AC0F48.4050106@nlnetlabs.nl> Date: Fri, 08 Feb 2008 09:14:00 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Edward Lewis CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis References: <200802080119.m181JUc2024071@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 08 Feb 2008 09:14:01 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Lewis wrote: | At 12:19 +1100 2/8/08, Mark Andrews wrote: | |> Note we could theoretically fix this for CNAME records by |> banning CNAMEs that point to non-existant names. | | It is impossible to definitely decide, in the most general case, if the | domain name in the RDATA of the CNAME exists (for the zone's managing | process). I.e., if the name is like this: | | onename.example. CNAME onename.tld. | | With example. and tld. not mutually served authoritatively by any name | server. | |> If anyone can provide a rational for the quoted text I'd |> like to hear it. | | I assume the quoted text is this: | |>> If the "*" label does not exist, check whether the name we |>> are looking for is the original QNAME in the query or a name |>> we have followed due to a CNAME or DNAME. If the name is |>> original, set an authoritative name error in the response |>> and |>> exit. Otherwise just exit. | | That text is quite unclear, because what is the status of a name that is | below a DNAME? In CNAME it is clear, if you followed a CNAME you were | at a name along the way, hence there's something in the answer section. | But DNAME the query is rewritten from "some other" name. One way to | scratch your head over it is whether a name comes into existence because | there's a CNAME record generated by the DNAME? Whether explicitly or | implicitly. I think it is very clear. Once you add a CNAME (or DNAME) to the answer section, then the rcode will be NOERROR (not NXDOMAIN), even if the rdata of the CNAME does not exist. Since the answer section is not going to be empty. Even will be filled with the qname. And the name with a CNAME certainly exists. Thus the qname domain name exists. In my opinion, adding the rdata of the CNAME (following the CNAME chain) is an optional 'nicety' by the server, and therefore does not change the rcode. The real answer is the CNAME, which exists, which causes the name to exist, and rcode=NOERROR. A consequence is that all names below a DNAME come into existance. Anyway, my interpretation, which seems wildly different from yours :-) Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHrA9IkDLqNwOhpPgRAu81AJ0cF63I+Y3ENzF4YsOe3u3WHWZEcACgpybt fPsGS1xqccW5PZhCq7bY8AE= =wGdS -----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 Fri Feb 8 00:27: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 1A04E28C16E; Fri, 8 Feb 2008 00:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqjMpu7hdQ0M; Fri, 8 Feb 2008 00:27:03 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 37A4828C17D; Fri, 8 Feb 2008 00:26:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNORl-000P8Q-45 for namedroppers-data@psg.com; Fri, 08 Feb 2008 08:18:57 +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 1JNORe-000P7k-7N for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 08:18:51 +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 m188Idjk022139; Fri, 8 Feb 2008 19:18:39 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080818.m188Idjk022139@drugs.dv.isc.org> To: Wouter Wijngaards Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Fri, 08 Feb 2008 09:09:19 BST." <47AC0E2F.30906@nlnetlabs.nl> Date: Fri, 08 Feb 2008 19:18:39 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Mark Andrews wrote: > |> I don't agree that we have to allow obscured records to be loaded. > |> Why do we "have to"? Why "(and should be for DNAME)?" > | > | Because you can't ADD a DNAME which obscures some record > | then STOP and RESTART the server. > | > | Mark > > Hi Mark, > > Why do we need obscured records? * So that you can easily correct mistakes. * So you can build namespace before you remove a DNAME. > Can't we rule that an added DNAME removes (not obscures) everything > below it. And nothing can be added below a DNAME. > That would make the draft consistent (but have to say that dynamic > update for DNAME is different from NS). > > What is the current practice for DNAME and dynamic update in existing > implementations? How do they handle this - that is what I as an editor > want to know before introducing another implementation change :-) We obscure as that matched NS and preserved the DNAME semantics. > Is it handled exactly like NS records now? In that case - can you > describe (in text) how that can be put in the draft? You basically look for a DNAME the same way as you look for a NS record as you traverse down through a zone. > Best regards, > ~ Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHrA4vkDLqNwOhpPgRAj9bAJ4oAdG82P5PVNRK8XXvA1s13W5WAgCfd558 > cbMONewtfJI61tDCyhRFSSk= > =fwIp > -----END PGP SIGNATURE----- -- 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 Feb 8 00:32:31 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 8388C28C16E; Fri, 8 Feb 2008 00:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii56STeqmk6d; Fri, 8 Feb 2008 00:32:30 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7686128C1AD; Fri, 8 Feb 2008 00:32:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNOVV-000Pg8-7z for namedroppers-data@psg.com; Fri, 08 Feb 2008 08:22:49 +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 1JNOVR-000PfR-Vv for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 08:22:47 +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 m188MZsM022185; Fri, 8 Feb 2008 19:22:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802080822.m188MZsM022185@drugs.dv.isc.org> To: Wouter Wijngaards Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 09:14:00 BST." <47AC0F48.4050106@nlnetlabs.nl> Date: Fri, 08 Feb 2008 19:22:35 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Edward Lewis wrote: > | At 12:19 +1100 2/8/08, Mark Andrews wrote: > | > |> Note we could theoretically fix this for CNAME records by > |> banning CNAMEs that point to non-existant names. > | > | It is impossible to definitely decide, in the most general case, if the > | domain name in the RDATA of the CNAME exists (for the zone's managing > | process). I.e., if the name is like this: > | > | onename.example. CNAME onename.tld. > | > | With example. and tld. not mutually served authoritatively by any name > | server. > | > |> If anyone can provide a rational for the quoted text I'd > |> like to hear it. > | > | I assume the quoted text is this: > | > |>> If the "*" label does not exist, check whether the name we > |>> are looking for is the original QNAME in the query or a name > |>> we have followed due to a CNAME or DNAME. If the name is > |>> original, set an authoritative name error in the response > |>> and > |>> exit. Otherwise just exit. > | > | That text is quite unclear, because what is the status of a name that is > | below a DNAME? In CNAME it is clear, if you followed a CNAME you were > | at a name along the way, hence there's something in the answer section. > | But DNAME the query is rewritten from "some other" name. One way to > | scratch your head over it is whether a name comes into existence because > | there's a CNAME record generated by the DNAME? Whether explicitly or > | implicitly. > > I think it is very clear. Once you add a CNAME (or DNAME) to the answer > section, then the rcode will be NOERROR (not NXDOMAIN), even if the > rdata of the CNAME does not exist. > > Since the answer section is not going to be empty. Even will be filled > with the qname. And the name with a CNAME certainly exists. Thus the > qname domain name exists. > > In my opinion, adding the rdata of the CNAME (following the CNAME chain) > is an optional 'nicety' by the server, and therefore does not change the > rcode. The real answer is the CNAME, which exists, which causes the name > to exist, and rcode=NOERROR. > > A consequence is that all names below a DNAME come into existance. > > Anyway, my interpretation, which seems wildly different from yours :-) Yet if you make the same question of a cache you will get NXDOMAIN unless QTYPE is CNAME or ANY. > Best regards, > ~ Wouter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHrA9IkDLqNwOhpPgRAu81AJ0cF63I+Y3ENzF4YsOe3u3WHWZEcACgpybt > fPsGS1xqccW5PZhCq7bY8AE= > =wGdS > -----END PGP SIGNATURE----- -- 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 Feb 8 01:17: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 B0C2528C111; Fri, 8 Feb 2008 01:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1meGwpTJ03QQ; Fri, 8 Feb 2008 01:17:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EF6BB28C0FB; Fri, 8 Feb 2008 01:17:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNPEW-0006R7-Fy for namedroppers-data@psg.com; Fri, 08 Feb 2008 09:09:20 +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 1JNPET-0006Qg-NV for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 09:09:19 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m18996uk098197; Fri, 8 Feb 2008 10:09:07 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47AC1C32.1070208@nlnetlabs.nl> Date: Fri, 08 Feb 2008 10:09:06 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis References: <200802080822.m188MZsM022185@drugs.dv.isc.org> In-Reply-To: <200802080822.m188MZsM022185@drugs.dv.isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 08 Feb 2008 10:09:07 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: | Anyway, my interpretation, which seems wildly different from yours :-) | |> Yet if you make the same question of a cache you will get |> NXDOMAIN unless QTYPE is CNAME or ANY. Then the cache is wrong (I mean, RFC noncompliant)? Or does a cache use a different algorithm from the RFC specs? Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHrBwykDLqNwOhpPgRAhExAJ47ts9PKI+JV5vapcUMQhimYIgl2ACgn4TY c1pl70ZDqILk6iuM2OXhDTI= =2uzE -----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 Fri Feb 8 02:17: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 D4EF128C203; Fri, 8 Feb 2008 02:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCkJyyxGfjGR; Fri, 8 Feb 2008 02:17:26 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4247F3A6B05; Fri, 8 Feb 2008 02:16:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQAd-000EOp-OG for namedroppers-data@psg.com; Fri, 08 Feb 2008 10:09: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 1JNQAW-000EOD-C5 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 10:09:17 +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 m18A966C022761; Fri, 8 Feb 2008 21:09:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802081009.m18A966C022761@drugs.dv.isc.org> To: Wouter Wijngaards Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 10:09:06 BST." <47AC1C32.1070208@nlnetlabs.nl> Date: Fri, 08 Feb 2008 21:09:06 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Andrews wrote: > | Anyway, my interpretation, which seems wildly different from yours :-) > | > |> Yet if you make the same question of a cache you will get > |> NXDOMAIN unless QTYPE is CNAME or ANY. > > Then the cache is wrong (I mean, RFC noncompliant)? > Or does a cache use a different algorithm from the RFC specs? Note the second point below. If recursive service is requested and available, the recursive response to a query will be one of the following: - The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. - A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist. - A temporary error indication. Also note it is possible to argue that "authoritative name error" is "add SOA record to authority section". See 4.3.4. Negative response caching (Optional). Mark > Best regards, > ~ Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHrBwykDLqNwOhpPgRAhExAJ47ts9PKI+JV5vapcUMQhimYIgl2ACgn4TY > c1pl70ZDqILk6iuM2OXhDTI= > =2uzE > -----END PGP SIGNATURE----- -- 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 Feb 8 02:45: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 7BDDE28C211; Fri, 8 Feb 2008 02:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.296 X-Spam-Level: X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[AWL=2.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI3qthBmnpUZ; Fri, 8 Feb 2008 02:45:36 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AC58C28C20E; Fri, 8 Feb 2008 02:45:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQaC-000HZL-QA for namedroppers-data@psg.com; Fri, 08 Feb 2008 10:35:48 +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 1JNQa4-000HV9-5U for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 10:35:44 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m18ARclD020172; Fri, 8 Feb 2008 17:27:40 +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 m18ARVBt010842; Fri, 8 Feb 2008 17:27:31 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: <200802080822.m188MZsM022185@drugs.dv.isc.org> References: <200802080822.m188MZsM022185@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Feb 2008 17:27:31 +0700 Message-ID: <9897.1202466451@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Fri, 08 Feb 2008 19:22:35 +1100 From: Mark Andrews Message-ID: <200802080822.m188MZsM022185@drugs.dv.isc.org> | Yet if you make the same question of a cache you will get | NXDOMAIN unless QTYPE is CNAME or ANY. How can that possibly be? NXDOMAIN only occurs when the name being sought does not exist in the DNS at all, with any RR type (or descendants). If the name does exist, then NXDOMAIN is simply wrong, whatever RR type the name might own (including CNAME, and regardless of the value of the CNAME data field) - and I cannot even begin to imagine how getting the answer from a cache can possibly make any difference to that. 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 Fri Feb 8 02:59: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 378A528C20A; Fri, 8 Feb 2008 02:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW--pB+tBZmn; Fri, 8 Feb 2008 02:59:16 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4A86D3A6820; Fri, 8 Feb 2008 02:59:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQqa-000JoV-As for namedroppers-data@psg.com; Fri, 08 Feb 2008 10:52:44 +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 1JNQqX-000Jnw-Ds for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 10:52:43 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m18AqTLG006838; Fri, 8 Feb 2008 11:52:29 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47AC346D.7020202@nlnetlabs.nl> Date: Fri, 08 Feb 2008 11:52:29 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis References: <200802081009.m18A966C022761@drugs.dv.isc.org> In-Reply-To: <200802081009.m18A966C022761@drugs.dv.isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 08 Feb 2008 11:52:29 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: | Or does a cache use a different algorithm from the RFC specs? | |> Note the second point below. |> Also note it is possible to argue that "authoritative name |> error" is "add SOA record to authority section". See 4.3.4. |> Negative response caching (Optional). OK, you are right, it looks like the authoritative and cache algorithm differ there. That certainly is inconsistent. Back to the DNAME draft. It is not going to update RFC1034, but we can say something sensible there. Perhaps remove some lines and let 1034 handle it, change to 'handle DNAME like encountering a CNAME on the way'? Or is the text fine the way it is now? Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHrDRskDLqNwOhpPgRAmMrAJwIQ/KtbUpytFKc0DX8tDBqgaoMTgCghui2 4KwcHtlqxVjoyqI2KtrSTdY= =+5Vp -----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 Fri Feb 8 03:02: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 03BE828C1E7; Fri, 8 Feb 2008 03:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.584 X-Spam-Level: X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[AWL=2.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAkw67Q1D6ly; Fri, 8 Feb 2008 03:02:42 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0C51028C1CF; Fri, 8 Feb 2008 03:02:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQub-000KK3-4Y for namedroppers-data@psg.com; Fri, 08 Feb 2008 10:56:53 +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 1JNQuU-000KGE-LH for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 10:56:51 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m18An31g012551; Fri, 8 Feb 2008 17:49:03 +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 m18AnBvl011568; Fri, 8 Feb 2008 17:49:11 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: <200802081009.m18A966C022761@drugs.dv.isc.org> References: <200802081009.m18A966C022761@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Feb 2008 17:49:11 +0700 Message-ID: <9115.1202467751@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Fri, 08 Feb 2008 21:09:06 +1100 From: Mark Andrews Message-ID: <200802081009.m18A966C022761@drugs.dv.isc.org> | Note the second point below. I think that's a mistake in 1034. | If recursive service is requested and available, the recursive response | to a query will be one of the following: [...] | - A name error indicating that the name does not exist. This | may include CNAME RRs that indicate that the original query | name was an alias for a name which does not exist. Then see 1035, section 4.1.1 ... RCODE Response code - this 4 bit field is set as part of responses. The values have the following interpretation: 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. The bit about "only for responses from auth name server" is a bit obsolete now, we permit caching of NXDOMAIN, but the "the domain name referenced in the query does not exist." is really very clear, and has never been changed. What's more, even if things were to be extended to allow NXDOMAIN if the value of a CNAME is a non-existing domain, the difference isn't in whether the server is a cache or not (aka, whether recursive service is being provided or not), it would be whether or not the server in question has data about the existence (or not) of the result of a CNAME. We know that there is no rule that a non-recursive server must return only the CNAME if it receives an A lookup of a name that is an alias, if it has the A record for the canonical name, it returns that as well. So, if I have FOO IN CNAME BAR ; BAR IN A 10.10.10.10 ; deleted last week (and that was the only record for BAR), then an A lookup aimed at the server could (if this were the right thing to do, which I do not believe it is) return RCODE=NXDOMAIN (aka Name Error, aka 3) ANSWER="FOO IN CNAME BAR" which is exactly what you're saying a cache would return. The only place there's a difference is when the canonical name is (would be) in a zone for which the server is not auth - then if it isn't recursive, it won't be able to ascertain whether the canonical name exists or not, whereas if it is, it can. Lastly, aside from being absurd to even contemplate (and totally unenforceable) banning CNAME records containing non-existing names would not solve this problem (there still needs to be a behaviour defined), and is the wrong thing to do in any case. Let's just make it clear that 1035, 4.1.1 (quoted above) is correct, and RCODE==3 applies only when the name in the query section does not exist, and in absolutely no other cases whatever. 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 Fri Feb 8 04:44: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 3F0B528C281; Fri, 8 Feb 2008 04:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.238 X-Spam-Level: X-Spam-Status: No, score=-4.238 tagged_above=-999 required=5 tests=[AWL=2.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxLeH-j1YUFd; Fri, 8 Feb 2008 04:44:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 29F0628C28D; Fri, 8 Feb 2008 04:44:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNSSm-0006c7-Hm for namedroppers-data@psg.com; Fri, 08 Feb 2008 12:36:16 +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 1JNSSj-0006Yk-M3 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 12:36:15 +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 1JNSSf-0005zN-5v; Fri, 08 Feb 2008 13:36:09 +0100 Received: from fweimer by bfk.de with local id 1JNSR9-0006MI-TS; Fri, 08 Feb 2008 13:34:36 +0100 To: Edward Lewis Cc: Mark Andrews , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP References: <200802050046.m150kXZ1018895@drugs.dv.isc.org> From: Florian Weimer Date: Fri, 08 Feb 2008 13:34:35 +0100 In-Reply-To: (Edward Lewis's message of "Mon, 4 Feb 2008 23:24:53 -0500") Message-ID: <82zlub1vac.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: > I'm just thinking of possible ways a server might be handling the > connection in ways that might make multiplexing not work. This pattern might be fairly common: while 1: buffer =3D socket.read( 65538) plen =3D int16at(buffer, 0) packet =3D buffer[2:2 + plen] process(packet): It only works with half-duplex connections because the read call might gnaw into the subsequent packet if pipelining/full duplex is used. --=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 Feb 8 04:44: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 469A128C281; Fri, 8 Feb 2008 04:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=1.967, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE4WJopiqrr5; Fri, 8 Feb 2008 04:44:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 295F628C287; Fri, 8 Feb 2008 04:44:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNSPu-0006Fs-O7 for namedroppers-data@psg.com; Fri, 08 Feb 2008 12:33:18 +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 1JNSPn-0006Bi-Ov for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 12:33:12 +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 1JNSPg-0005ua-OP; Fri, 08 Feb 2008 13:33:04 +0100 Received: from fweimer by bfk.de with local id 1JNSOB-0005ks-M4; Fri, 08 Feb 2008 13:31:31 +0100 To: Mark Andrews Cc: Paul Vixie , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR and TCP References: <200802042353.m14NrR1o018135@drugs.dv.isc.org> From: Florian Weimer Date: Fri, 08 Feb 2008 13:31:31 +0100 In-Reply-To: <200802042353.m14NrR1o018135@drugs.dv.isc.org> (Mark Andrews's message of "Tue, 05 Feb 2008 10:53:27 +1100") Message-ID: <824pcj39zw.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 * Mark Andrews: > Why? The spec will out live any broken implementations. A spec that gives implementors a chance to end up with an interoperable implementation without too much tweaking is a worthwhile goal, I guess. For classic DNS, the days of prescriptive protocol work are gone. > Within a couple of years of a definitive spec being out > there the vast majority of servers will have been fixed if > they have not already been fixed. Not if it is a frivolous protocol change, without any operational advantage. --=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 Feb 8 04:47: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 E543B28C248; Fri, 8 Feb 2008 04:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.913 X-Spam-Level: X-Spam-Status: No, score=-4.913 tagged_above=-999 required=5 tests=[AWL=1.686, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IzZqugqWwzb; Fri, 8 Feb 2008 04:47:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 28FB428C267; Fri, 8 Feb 2008 04:46:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNSW7-00072L-JI for namedroppers-data@psg.com; Fri, 08 Feb 2008 12:39:43 +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 1JNSW5-00071y-0y for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 12:39:42 +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 1JNSW2-000654-2e; Fri, 08 Feb 2008 13:39:38 +0100 Received: from fweimer by bfk.de with local id 1JNSUW-0007K5-Vs; Fri, 08 Feb 2008 13:38:04 +0100 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: AXFR and TCP References: From: Florian Weimer Date: Fri, 08 Feb 2008 13:38:04 +0100 In-Reply-To: (Edward Lewis's message of "Mon, 4 Feb 2008 15:59:30 -0500") Message-ID: <82ve4z1v4j.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: > I am going over the AXFR on TCP part of the -07 draft. Reading some > comments and contrasting with some on this list I wanted to find out > what's really happening now as opposed to what could be. > > My vision of an AXFR session is, client opens a connection, asks, > gets, closes connection, session over. That seems quite trivial, > something I can do with dig, etc. My gut feeling is that this is fine, with a small extension: ordinary queries should be allowed on the connection before the AXFR session starts. --=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 Feb 8 05:22: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 94C2D28C2C3; Fri, 8 Feb 2008 05:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v4blJCNkNA3; Fri, 8 Feb 2008 05:22:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7C79B28C262; Fri, 8 Feb 2008 05:22:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNT4G-000BiT-QX for namedroppers-data@psg.com; Fri, 08 Feb 2008 13:15:00 +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 1JNT49-000BhG-N8 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 13:14:56 +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 m18DEYoq023801; Sat, 9 Feb 2008 00:14:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802081314.m18DEYoq023801@drugs.dv.isc.org> To: Robert Elz Cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 17:49:11 +0700." <9115.1202467751@epsilon.noi.kre.to> Date: Sat, 09 Feb 2008 00:14:34 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Date: Fri, 08 Feb 2008 21:09:06 +1100 > From: Mark Andrews > Message-ID: <200802081009.m18A966C022761@drugs.dv.isc.org> > > | Note the second point below. > > I think that's a mistake in 1034. > > | If recursive service is requested and available, the recursive response > | to a query will be one of the following: > [...] > > | - A name error indicating that the name does not exist. This > | may include CNAME RRs that indicate that the original query > | name was an alias for a name which does not exist. > > Then see 1035, section 4.1.1 ... > > RCODE Response code - this 4 bit field is set as part of > responses. The values have the following > interpretation: > > 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist. > > The bit about "only for responses from auth name server" is a bit > obsolete now, we permit caching of NXDOMAIN, but the > > "the domain name referenced in the query does not exist." > > is really very clear, and has never been changed. RFC 1034 allows a name error to be returned from a cache. RFC 2308 allows a authoritive name error to be returned from a cache. RFC 403[345] allow a name error to be cryptographically validiated in the response from a cache. In all case the name at the end of the CNAME chain is what is being referred to by the name error. Prior to RFC 2308 the cache had to make a new query each time you got to the end of the CNAME chain then "append" the result. The stub resolver was not expected to do this and no stub resolver, as far as I am aware, will issue a second query on a CNAME chain the terminates on with NoError. Also no stub resolver goes and follows the authority and additional sections to retrieve a NXDOMAIN response as you interpretation would require them to do as it precludes a caching resolver *ever* returning NXDOMAIN whether proceeded by CNAMEs or not. RFC 1034 and RFC 1035 have lots of errors in them. They also have lots of incomplete ideas. Negative caching was incomplete by RFC 1034's own admission and that seriously impacted on how NXDOMAIN responses were described including the text which started this thread. As for RFC 1035's definition of name error, whether it was initially correct or not, it has been superceeded by RFC 2308 which clearly allow for name error to be return from caches. It also makes no distiction between authoritative servers or caches and expects name error at the end of CNAMEs in both cases. > What's more, even if things were to be extended to allow NXDOMAIN if the > value of a CNAME is a non-existing domain, the difference isn't in whether > the server is a cache or not (aka, whether recursive service is being > provided or not), it would be whether or not the server in question has > data about the existence (or not) of the result of a CNAME. > > We know that there is no rule that a non-recursive server must return > only the CNAME if it receives an A lookup of a name that is an alias, > if it has the A record for the canonical name, it returns that as well. > > So, if I have > > FOO IN CNAME BAR > > ; BAR IN A 10.10.10.10 ; deleted last week > > (and that was the only record for BAR), then an A lookup aimed at > the server could (if this were the right thing to do, which I do not > believe it is) return > > RCODE=NXDOMAIN (aka Name Error, aka 3) > ANSWER="FOO IN CNAME BAR" > > which is exactly what you're saying a cache would return. The only > place there's a difference is when the canonical name is (would be) in > a zone for which the server is not auth - then if it isn't recursive, > it won't be able to ascertain whether the canonical name exists or not, > whereas if it is, it can. > > Lastly, aside from being absurd to even contemplate (and totally > unenforceable) banning CNAME records containing non-existing names > would not solve this problem (there still needs to be a behaviour > defined), and is the wrong thing to do in any case. > > Let's just make it clear that 1035, 4.1.1 (quoted above) is correct, > and RCODE==3 applies only when the name in the query section does not > exist, and in absolutely no other cases whatever. > > 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: -- 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 Feb 8 06:03: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 2A7A93A7C8A; Fri, 8 Feb 2008 06:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwH1ZFQOWRau; Fri, 8 Feb 2008 06:03:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EF6643A6A15; Fri, 8 Feb 2008 06:03:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNTeX-000H6h-8Q for namedroppers-data@psg.com; Fri, 08 Feb 2008 13:52:29 +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 1JNTeQ-000H4y-2r for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 13:52: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 m18Dq3Ys024093; Sat, 9 Feb 2008 00:52:04 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802081352.m18Dq3Ys024093@drugs.dv.isc.org> To: Florian Weimer Cc: Edward Lewis , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: AXFR and TCP In-reply-to: Your message of "Fri, 08 Feb 2008 13:34:35 BST." <82zlub1vac.fsf@mid.bfk.de> Date: Sat, 09 Feb 2008 00:52:03 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > * Edward Lewis: > > > I'm just thinking of possible ways a server might be handling the > > connection in ways that might make multiplexing not work. > > This pattern might be fairly common: > > while 1: > buffer =3D socket.read( 65538) > plen =3D int16at(buffer, 0) > packet =3D buffer[2:2 + plen] > process(packet): > > It only works with half-duplex connections because the read call might > gnaw into the subsequent packet if pipelining/full duplex is used. RFC 1034 does not preclude the client sending multiple queries without waiting for a answer. Such code is already broken as there are clients which don't always wait for a answer before send the next query. netstat could make libresolv have multiple outstanding queries. I first saw them 15+ years ago. > > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: 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 Feb 8 06:57: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 65E8128C2E1; Fri, 8 Feb 2008 06:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZrEhT6XNFo9; Fri, 8 Feb 2008 06:57:30 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 799CB28C343; Fri, 8 Feb 2008 06:57:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNUVx-0000If-2E for namedroppers-data@psg.com; Fri, 08 Feb 2008 14:47:41 +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 1JNUVq-0000Hp-SZ for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 14:47:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7BE6511460 for ; Fri, 8 Feb 2008 14:47:29 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: Your message of "Fri, 08 Feb 2008 17:49:11 +0700." <9115.1202467751@epsilon.noi.kre.to> References: <200802081009.m18A966C022761@drugs.dv.isc.org> <9115.1202467751@epsilon.noi.kre.to> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 08 Feb 2008 14:47:29 +0000 Message-ID: <2901.1202482049@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion [kre] > 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist. > > The bit about "only for responses from auth name server" is a bit > obsolete now, we permit caching of NXDOMAIN, but the > > "the domain name referenced in the query does not exist." > > is really very clear, and has never been changed. it's not clear to me at all. > What's more, even if things were to be extended to allow NXDOMAIN if the > value of a CNAME is a non-existing domain, ... you mean like this? ; <<>> DiG 9.4.1 <<>> somewhere.vix.com in a @::1 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40272 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;somewhere.vix.com. IN A ;; ANSWER SECTION: somewhere.vix.com. 3600 IN CNAME nowhere.vix.com. ;; Query time: 2 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Feb 8 14:31:13 2008 ;; MSG SIZE rcvd: 57 i can't think of any other way to signal this. (the above is from a recursive DNS implementation made by me from memory, without reference to BIND or RFCs.) > the difference isn't in whether the server is a cache or not (aka, whether > recursive service is being provided or not), it would be whether or not the > server in question has data about the existence (or not) of the result of a > CNAME. "has data" won't do, as a standard. a recursive server has to follow out-of-zone cnames and thus, will keep searching until there is a definitive answer. an authority server does not have to follow out-of-zone cnames and so, can return a dangling cname chain (ANCOUNT>0) and no error (RCODE=0) which is a partial, nondefinitive result. if the cname is in-zone, an authority server will give a definitive result very much like the one above (which i now realize probably ought to include an SOA RR in its authority.) > We know that there is no rule that a non-recursive server must return > only the CNAME if it receives an A lookup of a name that is an alias, > if it has the A record for the canonical name, it returns that as well. > > So, if I have > > FOO IN CNAME BAR > > ; BAR IN A 10.10.10.10 ; deleted last week > > (and that was the only record for BAR), then an A lookup aimed at > the server could (if this were the right thing to do, which I do not > believe it is) return > > RCODE=NXDOMAIN (aka Name Error, aka 3) > ANSWER="FOO IN CNAME BAR" > > which is exactly what you're saying a cache would return. that's what everybody does, and it's the only way that a recursive server who talks to that authority server is going to be able to build a complete CNAME chain when out-of-zone CNAMEs are allowed. when i put this question to PVM about ten years ago, he said "out-of-zone CNAME RRs were never part of my early thinking on DNS, so the spec is incomplete on that point" and "good luck storming the castle, boys!" > ... The only place there's a difference is when the canonical name is (would > be) in a zone for which the server is not auth - then if it isn't recursive, > it won't be able to ascertain whether the canonical name exists or not, > whereas if it is, it can. you mean like this? ; <<>> DiG 9.4.1 <<>> +bufsize=1500 elsewhere.vix.com in a ; @ns.lah1.vix.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64677 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 18 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;elsewhere.vix.com. IN A ;; ANSWER SECTION: elsewhere.vix.com. 3600 IN CNAME nowhere.munnari.oz.au. ;; AUTHORITY SECTION: . 518368 IN NS I.ROOT-SERVERS.NET. ... ;; ADDITIONAL SECTION: M.ROOT-SERVERS.NET. 604760 IN A 202.12.27.33 ... ;; Query time: 0 msec ;; SERVER: 204.152.188.234#53(204.152.188.234) ;; WHEN: Fri Feb 8 14:43:18 2008 ;; MSG SIZE rcvd: 624 > Lastly, aside from being absurd to even contemplate (and totally > unenforceable) banning CNAME records containing non-existing names > would not solve this problem (there still needs to be a behaviour > defined), and is the wrong thing to do in any case. right. > Let's just make it clear that 1035, 4.1.1 (quoted above) is correct, > and RCODE==3 applies only when the name in the query section does not > exist, and in absolutely no other cases whatever. how would an iterative resolver ever build a complete cname chain in that case, if out-of-zone CNAMEs are present? i think we have to make it clear that RFC 1035 did not know about out-of-zone CNAMEs and that when those are present we have to look at a larger picture than the definition of RCODE=3. -- to unsubscribe send a message to namedroppers-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 Feb 8 07:12: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 C08263A6B82; Fri, 8 Feb 2008 07:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wOx0TjhZjTt; Fri, 8 Feb 2008 07:12:42 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9199F3A6FDE; Fri, 8 Feb 2008 07:12:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNUiv-0002aD-UE for namedroppers-data@psg.com; Fri, 08 Feb 2008 15:01: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 1JNUio-0002Z8-RD for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 15:01:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6731F11434 for ; Fri, 8 Feb 2008 15:00:58 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-Reply-To: Your message of "Fri, 08 Feb 2008 09:09:19 +0100." <47AC0E2F.30906@nlnetlabs.nl> References: <200802080326.m183QTJo045227@drugs.dv.isc.org> <47AC0E2F.30906@nlnetlabs.nl> 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: Fri, 08 Feb 2008 15:00:58 +0000 Message-ID: <3562.1202482858@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --=-=-= > |> I don't agree that we have to allow obscured records to be loaded. > |> Why do we "have to"? Why "(and should be for DNAME)?" > | > | Because you can't ADD a DNAME which obscures some record > | then STOP and RESTART the server. > > Why do we need obscured records? > > Can't we rule that an added DNAME removes (not obscures) everything > below it. And nothing can be added below a DNAME. if the unix "mv" or "cp" command could ever behave like "rm -rf" then the natural error rate would be high enough, at scale, that a whole lot of data would get implicitly destroyed, and the behaviour would be changed. > That would make the draft consistent (but have to say that dynamic > update for DNAME is different from NS). we just can't have UPDATE doing implicit "rm -rf". anyone who wants that behaviour should code it as successive, explicit UPDATE operations. > What is the current practice for DNAME and dynamic update in existing > implementations? How do they handle this - that is what I as an editor > want to know before introducing another implementation change :-) > > Is it handled exactly like NS records now? In that case - can you > describe (in text) how that can be put in the draft? right now there are no special rules for UPDATE on DNAME RRs. unlike NS RR it is possible to delete the last DNAME at a zone apex, for example. (not that this matters, i'm just using it as an example.) so what we get at the moment is, if you add a DNAME then the zone beneath that point is unreachable by the authority server's search algo, and names/records below that point which have been cached, are still returnable from recursive servers, who aren't aware of the DNAME. if you're going to update the DNAME++ spec on this point, i'd say, adding a DNAME to an existing name (which has either records or children) is not permitted, and YXDOMAIN should be returned in this case. i thought that we had covered this adequately in an earlier thread here. see attached. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=3915 From: Paul Vixie To: Scott Rose cc: Wouter Wijngaards , Namedroppers Subject: Re: updated dname draft-08 In-Reply-To: Your message of "Mon, 14 Jan 2008 11:51:41 EST." <478B931D.3080306@nist.gov> References: <478B2AE0.2060108@nlnetlabs.nl> <62627.1200324912@sa.vix.com> <478B931D.3080306@nist.gov> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jan 2008 18:20:45 +0000 Message-ID: <70150.1200334845@sa.vix.com> Sender: vixie@sa.vix.com > Basically yes, but the changes are: thanks very much for this, and for wouter's answer to the same lazy question from me. > Server side > Old: > server generated CNAME RRs have TTL=0 > Always generated CNAMEs in response containing DNAME > > New: > server generated CNAME RRs have TTL = DNAME TTL (some implementations > already do this) > > Only generate CNAME RRs if the Understand DNAME (UD) bit is NOT set (EDNS0 > flags field - 2nd highest bit requested) so far so good. > Server MUST return RCODE=REFUSED to a dynamic update message that would add > any RR with a domain name under a DNAME RR's ownername. > > Server handles adding DNAME RRs much like adding a NS to a zone (removes > any domain names that would be under the DNAME ownername). these are both controversial. see below. > Client side > New: > If resolver understands DNAME RRs in a response (i.e. follow them without > the need of a CNAME) set the UD bit in the EDNS0 flags section. and presumably ignore any presented CNAMEs whose owner matches a presented DNAME (since not all servers will notice the UD). but since EDNS is hop/hop i'm going to ask whether recursive servers are allowed to synthesize CNAME if there is a cached DNAME and UD=0? (i don't need to know, it's fine with me either way, i just hope the draft covers this.) > If generated CNAMEs present, expect TTL = DNAME TTL or TTL = 0 how does an initiator know whether the presented CNAMEs are synthetic? > Caches: > Discussion only > > The rest of the draft is a discussion of DNAME including clarification and > pulling in sections of other drafts that discuss DNAME RRs. > > I think that's all. Would it help if this was expanded and included as an > appendix to the draft? yes, very much. --- now for the two controversial UPDATE issues first, RCODE=REFUSED is defined by RFC 2136 as follows: REFUSED 5 The name server refuses to perform the specified operation for policy or security reasons. every RCODE related to UPDATE failure that is dependent on pre-existing zone content is something other than REFUSED. by "policy" in the above text, we really meant something that had a configuration knob, where the knob was in the "wrong" or incompatible position. to use RCODE=REFUSED as a data-present zone content incompatibility would be, in my opinion, the wrong thing to do. i propose that RCODE=YXDOMAIN be used instead: YXDOMAIN 6 Some name that ought not to exist, does exist. here, we deliberately did not say that the name which does exist is, or is not, the same as a name being updated. it covers perfectly well the case you said: "would add any RR with a domain name under a DNAME RR's ownername." if this isn't reasonable, then i propose we allocate a new RCODE for this case, but that no matter what we do, we must not use RCODE=REFUSED. second, automatic removal of removal of domains below a DNAME. RFC 2136 does not, as far as i can tell by searching it, ask an UPDATE responder to delete names when an NS RR is added. in fact, this issue came up during the DNSIND discussions and we determined that since the zone searching algorythm used by QUERY would stop when searching downward from the apex upon encounter with an NS RRset, then it was theoretically possible to add an NS RR which would hide all data beneath its owner name, and then later delete that NS RRset causing all the previously hidden data to become visible. since DNAME has the same effect on QUERY's downward search as NS has (that is, the search stops), i think there is no reason to require any automatic deletion of data when a DNAME is added. sorry to be so late with this. i don't keep up with drafts like i used 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: From owner-namedroppers@ops.ietf.org Fri Feb 8 08:42: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 9AFBA3A7677; Fri, 8 Feb 2008 08:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.992 X-Spam-Level: X-Spam-Status: No, score=-4.992 tagged_above=-999 required=5 tests=[AWL=1.607, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM-mIUt4oXrO; Fri, 8 Feb 2008 08:42:37 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DF4D93A734A; Fri, 8 Feb 2008 08:42:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNW8Q-000HbG-Fc for namedroppers-data@psg.com; Fri, 08 Feb 2008 16:31:30 +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 1JNW8N-000Haq-Li for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 16:31:29 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18GV9tn019470; Fri, 8 Feb 2008 11:31:09 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802080326.m183QTJo045227@drugs.dv.isc.org> References: <200802080326.m183QTJo045227@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 11:23:43 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: Edward Lewis , namedroppers@ops.ietf.org 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 14:26 +1100 2/8/08, Mark Andrews wrote: > At the apex. It's perfect fine to add and delete NS RRsets > at the bottom of zone. DNAME is always at bottom of zone > even when it is at the apex. Ergo, NS processing is not "similar" to DNAME, right? DNAME can be at the apex or not, there's no difference. > Because you can't ADD a DNAME which obscures some record > then STOP and RESTART the server. I don't know how to read that. By the rules of DNAME, it isn't allowed to "obscure" domain names. So, no, you can't do that. Should we want to? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 08:50: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 B68EA3A6B82; Fri, 8 Feb 2008 08:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.546 X-Spam-Level: X-Spam-Status: No, score=-4.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDHKX4SEQNhf; Fri, 8 Feb 2008 08:50:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 705B028C2C1; Fri, 8 Feb 2008 08:50:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNWI7-000KXu-Sq for namedroppers-data@psg.com; Fri, 08 Feb 2008 16:41: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 1JNWI4-000KVL-LP for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 16:41:30 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18Gf6ES019538; Fri, 8 Feb 2008 11:41:07 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <47AC0F48.4050106@nlnetlabs.nl> References: <200802080119.m181JUc2024071@drugs.dv.isc.org> <47AC0F48.4050106@nlnetlabs.nl> Date: Fri, 8 Feb 2008 11:37:31 -0500 To: Wouter Wijngaards From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis Cc: Edward Lewis , Mark Andrews , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-1009633628==_ma============" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --============_-1009633628==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:14 +0100 2/8/08, Wouter Wijngaards wrote: >A consequence is that all names below a DNAME come into existance. What a wacky idea. When we came up with RFC 4592 we had to have a clearer definition of "existence." Just because a name appears in an answer doesn't mean it exists. (But then, how did it get into the answer?) Synthesized answers, of which wild cards are the one defined mechanism, are the alternative to answers from existing names. To avoid making this long, I won't paste in RFC 4592's section 2.2.3. "Yet Another Definition of Existence" section. But that defines existence as things "on the tree" and not "things in answers." Here's the conflicting "precedents." CNAME processing removes NXDOMAIN from answers that wind up at non-existing names - but the (first if a chain) CNAME owner has to equal the QNAME. Wild cards remove NXDOMAIN from any answer in their spheres of influence but that's because an answer is being synthesized to overlay the name error. However, wild cards don't cause names to come into being, if they did, the wild card would never be invoked (look carefully at RFC 1034, 4.3.2). It's not clear to me that I agree. Ergo, it's a wacky idea. >Anyway, my interpretation, which seems wildly different from yours :-) No, really, I asked because I hadn't thought of it before. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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. --============_-1009633628==_ma============ Content-Type: text/html; charset="us-ascii" Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synth
At 9:14 +0100 2/8/08, Wouter Wijngaards wrote:

>A consequence is that all names below a DNAME come into existance.

What a wacky idea.

When we came up with RFC 4592 we had to have a clearer definition of "existence."  Just because a name appears in an answer doesn't mean it exists.  (But then, how did it get into the answer?)  Synthesized answers, of which wild cards are the one defined mechanism, are the alternative to answers from existing names.

To avoid making this long, I won't paste in RFC 4592's section 2.2.3.  "Yet Another Definition of Existence" section.  But that defines existence as things "on the tree" and not "things in answers."

Here's the conflicting "precedents."  CNAME processing removes NXDOMAIN from answers that wind up at non-existing names - but the (first if a chain) CNAME owner has to equal the QNAME.  Wild cards remove NXDOMAIN from any answer in their spheres of influence but that's because an answer is being synthesized to overlay the name error.  However, wild cards don't cause names to come into being, if they did, the wild card would never be invoked (look carefully at RFC 1034, 4.3.2).

It's not clear to me that I agree.

Ergo, it's a wacky idea.

>Anyway, my interpretation, which seems wildly different from yours :-)

No, really, I asked because I hadn't thought of it before.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
--============_-1009633628==_ma============-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 08:59: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 C74FB28C38F; Fri, 8 Feb 2008 08:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=1.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4n97N-d02KB; Fri, 8 Feb 2008 08:59:29 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 766B828C2E9; Fri, 8 Feb 2008 08:59:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNWS3-000MFY-KV for namedroppers-data@psg.com; Fri, 08 Feb 2008 16:51:47 +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 1JNWS0-000MF9-NS for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 16:51:46 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18Gp6CM019608; Fri, 8 Feb 2008 11:51:15 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802080822.m188MZsM022185@drugs.dv.isc.org> References: <200802080822.m188MZsM022185@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 11:43:18 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis Cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 19:22 +1100 2/8/08, Mark Andrews wrote: > Yet if you make the same question of a cache you will get > NXDOMAIN unless QTYPE is CNAME or ANY. I should have included in the previous message, but the mailer sent it out. That's significant - existence of a name it transferrable from authoritative server to cache, synthesis rules are not. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 08:59: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 78AF028C2E9; Fri, 8 Feb 2008 08:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.127 X-Spam-Level: X-Spam-Status: No, score=-5.127 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8OcgYB6dnqP; Fri, 8 Feb 2008 08:59:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9308628C248; Fri, 8 Feb 2008 08:59:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNWRy-000MF3-Vj for namedroppers-data@psg.com; Fri, 08 Feb 2008 16:51:42 +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 1JNWRw-000MEa-Au for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 16:51:41 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18Gp6CO019608; Fri, 8 Feb 2008 11:51:26 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <47AC346D.7020202@nlnetlabs.nl> References: <200802081009.m18A966C022761@drugs.dv.isc.org> <47AC346D.7020202@nlnetlabs.nl> Date: Fri, 8 Feb 2008 11:48:04 -0500 To: Wouter Wijngaards From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis Cc: Mark Andrews , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 11:52 +0100 2/8/08, Wouter Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Mark Andrews wrote: >| Or does a cache use a different algorithm from the RFC specs? >| >|> Note the second point below. > >|> Also note it is possible to argue that "authoritative name >|> error" is "add SOA record to authority section". See 4.3.4. >|> Negative response caching (Optional). > >OK, you are right, it looks like the authoritative and cache algorithm >differ there. That certainly is inconsistent. > >Back to the DNAME draft. It is not going to update RFC1034, but we can >say something sensible there. Perhaps remove some lines and let 1034 >handle it, change to 'handle DNAME like encountering a CNAME on the way'? > >Or is the text fine the way it is now? Don't rely on analogy to define something ("DNAME like CNAME"). And it's clear to me after Robert Elz's point that: At 17:49 +0700 2/8/08, Robert Elz wrote: > "the domain name referenced in the query does not exist." > >is really very clear, and has never been changed. Still, I'm not satisfied with what I am thinking now...... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 09:02: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 2C64E28C377; Fri, 8 Feb 2008 09:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.172 X-Spam-Level: X-Spam-Status: No, score=-5.172 tagged_above=-999 required=5 tests=[AWL=1.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8Ryr39zPr93; Fri, 8 Feb 2008 09:02:51 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9550028C3BB; Fri, 8 Feb 2008 09:00:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNWRl-000MD8-Tu for namedroppers-data@psg.com; Fri, 08 Feb 2008 16:51: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 1JNWRi-000MCM-LI for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 16:51:28 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18Gp6CK019608; Fri, 8 Feb 2008 11:51:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802080818.m188Idjk022139@drugs.dv.isc.org> References: <200802080818.m188Idjk022139@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 11:41:25 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org 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 19:18 +1100 2/8/08, Mark Andrews wrote: > * So that you can easily correct mistakes. You can cover that via clever scripting. Once I added 100's of names incorrectly. I just modified the "add" to "delete" in the script and took them out. But granted, easy to fix would be nice. I question it is necessary. > * So you can build namespace before you remove a DNAME. But, atomicity of dynamic updates can solve that. "delete DNAME, add these" can be in one step. > We obscure as that matched NS and preserved the DNAME semantics. So you are saying that you implemented DNAME much like (similar?) NS? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 10:13: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 1FEE228C418; Fri, 8 Feb 2008 10:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.628 X-Spam-Level: X-Spam-Status: No, score=-4.628 tagged_above=-999 required=5 tests=[AWL=1.971, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M208fd09u-IF; Fri, 8 Feb 2008 10:13:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5218C28C362; Fri, 8 Feb 2008 10:13:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNXXa-0008Xs-OQ for namedroppers-data@psg.com; Fri, 08 Feb 2008 18:01:34 +0000 Received: from [2001:1890:1112:1:21c:23ff:fecf:10ec] (helo=core3.amsl.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNXXX-0008XP-Kw for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 18:01:33 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 54A663A79D3; Fri, 8 Feb 2008 10:00:01 -0800 (PST) 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-axfr-clarify-07.txt Message-Id: <20080208180001.54A663A79D3@core3.amsl.com> Date: Fri, 8 Feb 2008 10:00:01 -0800 (PST) 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 : DNS Zone Transfer Protocol (AXFR) Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-07.txt Pages : 0 Date : 2008-2-5 The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996. The base definition of these facilities, that of the AXFR, has proven insufficient in detail, resulting in no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-axfr-clarify-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-8095634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-8095634.I-D@ietf.org> --OtherAccess-- --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 Fri Feb 8 10:45: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 D23BC28C3D7; Fri, 8 Feb 2008 10:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.214 X-Spam-Level: X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=1.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+tzgeAysDvd; Fri, 8 Feb 2008 10:45:23 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EFB1F28C3C6; Fri, 8 Feb 2008 10:45:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNY4j-000DJe-Mv for namedroppers-data@psg.com; Fri, 08 Feb 2008 18:35:49 +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 1JNY4d-000DJ6-WF for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 18:35:48 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18IZbmP020526; Fri, 8 Feb 2008 13:35:37 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 8 Feb 2008 13:35:36 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: AXFR over UDP is available Cc: ed.lewis@neustar.biz 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 http://www.ietf.org/internet-drafts/draft-lewis-axfr-over-udp-00.txt Haven't seen the announcement yet, but the URL works. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 11:39: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 AB26C28C3A6; Fri, 8 Feb 2008 11:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsacoSJYA4s9; Fri, 8 Feb 2008 11:39:29 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E02BF28C3AC; Fri, 8 Feb 2008 11:39:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNYtw-000KZq-G2 for namedroppers-data@psg.com; Fri, 08 Feb 2008 19:28:44 +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 1JNYtt-000KZS-N9 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 19:28:43 +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 m18JSa1R025098 for ; Fri, 8 Feb 2008 14:28:36 -0500 Message-ID: <47ACAD64.6080802@nist.gov> Date: Fri, 08 Feb 2008 14:28:36 -0500 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt References: <200802080326.m183QTJo045227@drugs.dv.isc.org> In-Reply-To: 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 Edward Lewis wrote: > >> Because you can't ADD a DNAME which obscures some record >> then STOP and RESTART the server. > > I don't know how to read that. By the rules of DNAME, it isn't allowed > to "obscure" domain names. So, no, you can't do that. > > Should we want to? So when it comes to names under a DNAME - obscure/delete/remove all basically mean the same thing (in the protocol) and the only difference is in bookkeeping on the server side as to what to do with the actual RRs. Is that the point? In which case the first paragraph of Section 5.2 can be changed to read: DNAME resource records can be added, changed and removed. Adding a DNAME RR removes all domain names that would appear under the newly added DNAME RR. The zone data that is removed MAY still exist on the local server in some form but MUST NOT be used as zone data when responding to queries and MUST NOT be included in zone transfer operations. Then the following two paragraphs of Section 5.2. Removed can be interpreted as obscured, deleted, copied to another file, or some other operation - it is up to the implementation. -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Feb 8 12:06: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 9341328C4F5; Fri, 8 Feb 2008 12:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=1.791, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5suZ+mFsc2S; Fri, 8 Feb 2008 12:06:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 15B5828C56F; Fri, 8 Feb 2008 12:01:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNZHQ-000Ors-QK for namedroppers-data@psg.com; Fri, 08 Feb 2008 19:53:00 +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 1JNZHK-000Oqt-1L for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 19:52:59 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m18Jp5Dg010898; Sat, 9 Feb 2008 02:51:06 +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 m18JogOu015030; Sat, 9 Feb 2008 02:50:53 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: <2901.1202482049@sa.vix.com> References: <2901.1202482049@sa.vix.com> <200802081009.m18A966C022761@drugs.dv.isc.org> <9115.1202467751@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Feb 2008 02:50:42 +0700 Message-ID: <13566.1202500242@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Fri, 08 Feb 2008 14:47:29 +0000 From: Paul Vixie Message-ID: <2901.1202482049@sa.vix.com> | i can't think of any other way to signal this. Huh? What's difficult, you return the CNAME alone, RCODE==0 just as if it were an out of zone cname. If that comes from a non-recursive server, then just like any other incomplete answer from such a server, you make another query, this time using the canonical name, and you get the answer (data, no data, or NXDOMAIN as appropriate). If the answer above is from a recursive server (RA==RD==1) then you know you have the complete answer, as much as you need anyway, the name queried exists, but the data you're looking for does not exist (there's no A, or MX or whatever). That's all that's needed, there's no difference between that case, and the empty answer (plus SOA, not a referral, with NS records). There's no need to have a different kind of application error return for the case of a dangling CNAME, the data sought doesn't exist, that's the end of it. | "has data" won't do, as a standard. No, that was shorthand typing... I think you know what I meant (which there was just to point out that Mark's recursive vs non-recursive distinction for different answers being returned wasn't correct, that's not what would make the difference). | a recursive server has to follow out-of-zone cnames and thus, | will keep searching until there is a definitive answer. Of course. | an authority server does not have to follow out-of-zone cnames and | so, can return a dangling cname chain (ANCOUNT>0) and no error (RCODE=0) | which is a partial, nondefinitive result. Yes, of course. | if the cname is in-zone, an | authority server will give a definitive result very much like the one above That's what I don't think it should do, the name queried did exist, it should not be NXDOMAIN. | (which i now realize probably ought to include an SOA RR in its authority.) Yeah - but that's hardly relevant just now... | that's what everybody does, and it's the only way that a recursive server | who talks to that authority server is going to be able to build a | complete CNAME chain when out-of-zone CNAMEs are allowed. Really? I sure must be missing some problem, as that just doesn't sound that difficult to me (more packets than we'd like to send perhaps, but dangling CNAMES also, one hopes, aren't a very common disease.) | when i put this question to PVM about ten years ago, he said "out-of-zone | CNAME RRs were never part of my early thinking on DNS, so the spec is | incomplete on that point" and "good luck storming the castle, boys!" That's probably true, but it isn't out of zone CNAMEs that we're really discussing, what the auth server does there is pretty clear, and we agree on that I think, its in zone CNAMEs where we're disagreeing about what is the appropriate response. | you mean like this? Yes, but that's boring, and isn't really adding everything, we all agree (I hope) that that response is correct, | how would an iterative resolver ever build a complete cname chain in that | case, if out-of-zone CNAMEs are present? I can't believe that you're asking for a lesson on pointer chasing, so I won't give one, but ***really***! | i think we have to make it clear | that RFC 1035 did not know about out-of-zone CNAMEs and that when those are | present we have to look at a larger picture than the definition of RCODE=3. I think it would be OK to make that point somewhere (the first of your two points), but I'm also not sure it is relevant right now, as that's actually the easy case. I kind of suspect that people have been hung up on the idea that if the canonical name doesn't exist, then its alias cannot exist. To me that's just wrong, the alias exists, and no lookup of it should give name error. I never really paid a lot of attention to all of the DNSSEC stuff about proof of non-existance, but I can't even imagine the convoluted chain of logic that would be needed to attempt to authoritatively claim that a "name error" is correct for a name that demonstratively exists (and for which, a different query - type=CNAME - would be required to say "does exist"). That would just be perverse. 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 Fri Feb 8 12:27: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 8D02028C0F9; Fri, 8 Feb 2008 12:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itcBSQLPk3TO; Fri, 8 Feb 2008 12:27:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7D91428C53D; Fri, 8 Feb 2008 12:27:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNZi5-0002m4-24 for namedroppers-data@psg.com; Fri, 08 Feb 2008 20:20:33 +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 1JNZi1-0002kx-Fb for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 20:20:31 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m18KEjni024926; Sat, 9 Feb 2008 03:14:46 +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 m18KEau6015016; Sat, 9 Feb 2008 03:14:41 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: <200802081314.m18DEYoq023801@drugs.dv.isc.org> References: <200802081314.m18DEYoq023801@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Feb 2008 03:14:36 +0700 Message-ID: <15222.1202501676@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Sat, 09 Feb 2008 00:14:34 +1100 From: Mark Andrews Message-ID: <200802081314.m18DEYoq023801@drugs.dv.isc.org> | RFC 1034 allows a name error to be returned from a cache. | RFC 2308 allows a authoritive name error to be returned | from a cache. | RFC 403[345] allow a name error to be cryptographically | validiated in the response from a cache. Yes, I know, as I said, the part about "only relevant in an auth answer" is not the way things work, that part was wrong. | In all case the name at the end of the CNAME chain is what | is being referred to by the name error. That part I think is a mistake, it is logically wrong. | Prior to RFC 2308 the cache had to make a new query each | time you got to the end of the CNAME chain then "append" | the result. Yes. That's what it needs to do if the data hasn't been included in the answer - that's clearly needed for an out of zone CNAME reply from a non-recursive server (there's no other way forward, whether or not the canonical name exists), doing the same thing for an apparently in-zone CNAME doesn't seem to be a great burden to me ("apparently" as there isn't any way to tell (without a bunch of extra queries) if the canonical name is in the same zone as the alias or not, so there cannot really be different behaviours.) What's more, if the canonical name doesn't exist, then it is impossible to say that it would have been in the same zone had it existed, we cannot possibly know (we do sometimes know that it cannot have been in the same zone, but never that it must have been.) What I'm trying to say, is that if you get a noerror and a cname, and no record of the type being queried, then you always MUST do another query. By defining the rcode to relate to the end of the (included in the response, I assume) CNAME chain, all you're really doing is occasionally saving a query (in the comparatively unusual case of dangling CNAMEs). I don't believe that's worth the inconsistency it generates. | The stub resolver was not expected to do | this and no stub resolver, as far as I am aware, will issue | a second query on a CNAME chain the terminates on with NoError. No, and that's fine, its recursive server (since it returned an answer) has already done all the work - if there's no terminating type==A (or whatever the query type was) in the response, then it doesn't exist. That's no different than simply getting an empty answer, the fact that there is a CNAME floating in the ether doesn't really change anything. | Also no stub resolver goes and follows the authority and | additional sections to retrieve a NXDOMAIN response as you | interpretation would require them to do No I don't, why is a NXDOMAIN needed? All it needs to know is that the data it sought doesn't exist. When it fails to find that data in the response from its cache (back end resolver), it knows all it needs to know. | as it precludes a | caching resolver *ever* returning NXDOMAIN whether proceeded | by CNAMEs or not. No, I agree that negative answers from caches are fine (and I said that last time...) | RFC 1034 and RFC 1035 have lots of errors in them. Yes. We are discussing an inconsistency between them, so clearly one of them is wrong. The question is, which one? It has been a long time since I read 2308, I will look at it again. 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 Fri Feb 8 12:29: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 6CF8328C51F; Fri, 8 Feb 2008 12:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[AWL=1.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N22vco7q9Iou; Fri, 8 Feb 2008 12:29:32 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6B50C28C4A0; Fri, 8 Feb 2008 12:29:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNZdE-00021M-BC for namedroppers-data@psg.com; Fri, 08 Feb 2008 20:15:32 +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 1JNZdB-00020o-69 for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 20:15:30 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m18KFA00021197; Fri, 8 Feb 2008 15:15:11 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <47ACAD64.6080802@nist.gov> References: <200802080326.m183QTJo045227@drugs.dv.isc.org> <47ACAD64.6080802@nist.gov> Date: Fri, 8 Feb 2008 15:14:57 -0500 To: Scott Rose From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 14:28 -0500 2/8/08, Scott Rose wrote: >Edward Lewis wrote: >> >>> Because you can't ADD a DNAME which obscures some record >>> then STOP and RESTART the server. >> I don't know how to read that. By the rules of DNAME, it isn't >>allowed to "obscure" domain names. So, no, you can't do that. >> Should we want to? > >So when it comes to names under a DNAME - obscure/delete/remove all >basically mean the same thing (in the protocol) and the only >difference is in bookkeeping on the server side as to what to do >with the actual RRs. Is that the point? Not quite. If you choose the semantics of obscuring... When a DNAME is put "above" an (explicitly) existing name, subsequent searches will cross the DNAME (as if it were an NS - cut point) and be processed there. The obscured name is "dormant." If subsequently the DNAME is "removed" then the name in question returns to "live" action when it comes to query processing. If you prohibit the addition of DNAME above an existing name... You are "forcing" a delete of the below names before the DNAME can be added. Consequently, when ever the DNAME is removed, the old names are still gone. If you make the addition of a DNAME cause an implicit deletion of names below... You effectively create the same as the previous case, but without an error condition to check for. (Like "rm -f" vs. "rm") >In which case the first paragraph of Section 5.2 can be changed to read: > > DNAME resource records can be added, changed and removed. > Adding a DNAME RR removes all domain names that would appear > under the newly added DNAME RR. The zone data that is > removed MAY still exist on the local server in some form > but MUST NOT be used as zone data when responding to queries > and MUST NOT be included in zone transfer operations. Whether to remove or obscure, I am currently neutral. Obscure is the de jure method for NS changes. I don't know if it is in a specification, I know it is the way it has been implemented. I'm going to throw out a faded memory here, the reason for the choice was an implementation detail to handle the speed in which memory could be jostled when there were changes to zones (not a zone's data) on a server. I think it just worked it's way into being a "given." Although I have questioned Mark's statements about "we should obscure" I mean that to challenge the rationale and not the decision. Perhaps it is the right thing to do, but we shouldn't "have to do" it just because any one implementation (in this case BIND) has been doing it that way. If there's a reason why we should choose removing, we can. My objection to Mark's message was that the DNAMEbis document is consistent (minus the reference to NS processing being 'similar') with itself but is not consistent with the NS record semantics. And that's okay I think, unless there's a stronger reason to use the same semantics (obscure) for DNAME. >Then the following two paragraphs of Section 5.2. Removed can be interpreted >as obscured, deleted, copied to another file, or some other operation - it is >up to the implementation. Well, I don't think it's that simple. One reason this is not just an implementation issue is, what if, an operator has a BIND and a NSD server as master and slave. If one obscures and the other removes as a result of a dynamic update add of a DNAME, the two will fall out of sync if the DNAME is deleted (even under the same serial number). I encourage the editors and chair to take the suggestion to open up a debate on obscure vs. remove semantics and see what the group thinks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 12:39: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 4E48C28C4C3; Fri, 8 Feb 2008 12:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X1B8ljkKB+5; Fri, 8 Feb 2008 12:39:07 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8696A28C3A3; Fri, 8 Feb 2008 12:39:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNZnz-00040p-78 for namedroppers-data@psg.com; Fri, 08 Feb 2008 20:26:39 +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 1JNZnw-0003zq-KN for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 20:26:37 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4B9FF11496; Fri, 8 Feb 2008 20:26:36 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-Reply-To: Your message of "Fri, 08 Feb 2008 14:28:36 EST." <47ACAD64.6080802@nist.gov> References: <200802080326.m183QTJo045227@drugs.dv.isc.org> <47ACAD64.6080802@nist.gov> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 08 Feb 2008 20:26:36 +0000 Message-ID: <18549.1202502396@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > In which case the first paragraph of Section 5.2 can be changed to read: > > DNAME resource records can be added, changed and removed. > Adding a DNAME RR removes all domain names that would appear > under the newly added DNAME RR. The zone data that is > removed MAY still exist on the local server in some form > but MUST NOT be used as zone data when responding to queries > and MUST NOT be included in zone transfer operations. > > Then the following two paragraphs of Section 5.2. Removed can be > interpreted as obscured, deleted, copied to another file, or some other > operation - it is up to the implementation. i really think this is the wrong approach. if you try to add a DNAME to a name that has records or children, you should get a YXDOMAIN error. -- to unsubscribe send a message to namedroppers-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 Feb 8 16:14: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 1C27228C6B1; Fri, 8 Feb 2008 16:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfJRHH+wQ6z3; Fri, 8 Feb 2008 16:14:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0275728C3E8; Fri, 8 Feb 2008 16:14:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNd8Q-0007RN-NS for namedroppers-data@psg.com; Fri, 08 Feb 2008 23:59:58 +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 1JNd8N-0007R0-5E for namedroppers@ops.ietf.org; Fri, 08 Feb 2008 23:59:57 +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 m18NxgvG065654; Sat, 9 Feb 2008 10:59:44 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802082359.m18NxgvG065654@drugs.dv.isc.org> To: Robert Elz Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Sat, 09 Feb 2008 02:50:42 +0700." <13566.1202500242@epsilon.noi.kre.to> Date: Sat, 09 Feb 2008 10:59:42 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Date: Fri, 08 Feb 2008 14:47:29 +0000 > From: Paul Vixie > Message-ID: <2901.1202482049@sa.vix.com> > > | i can't think of any other way to signal this. > > Huh? What's difficult, you return the CNAME alone, RCODE==0 > just as if it were an out of zone cname. > > If that comes from a non-recursive server, then just like any other > incomplete answer from such a server, you make another query, this > time using the canonical name, and you get the answer (data, no data, > or NXDOMAIN as appropriate). > > If the answer above is from a recursive server (RA==RD==1) then you > know you have the complete answer, as much as you need anyway, the > name queried exists, but the data you're looking for does not exist > (there's no A, or MX or whatever). > > That's all that's needed, there's no difference between that case, > and the empty answer (plus SOA, not a referral, with NS records). > There's no need to have a different kind of application error return > for the case of a dangling CNAME, the data sought doesn't exist, > that's the end of it. > > | "has data" won't do, as a standard. > > No, that was shorthand typing... I think you know what I meant (which > there was just to point out that Mark's recursive vs non-recursive > distinction for different answers being returned wasn't correct, that's > not what would make the difference). Actually it was making the difference. You only get to that part of the algorithm if you recursion was not requested or not available (See step 1). ra=0 or rd=0 QNAME -> no-existant name in zone -> auth name error QNAME -> CNAME -> non-existant name in zone -> no error QNAME -> CNAME -> name not in zone -> referral QNAME -> existant name in zone but no data -> no error QNAME -> CNAME -> existant name in zone but no data -> no error ra=1 and rd=1 QNAME -> no-existant name in zone -> name error QNAME -> CNAME -> non-existant name in zone -> name error QNAME -> CNAME -> non-existant name on other server -> name error You will note that the following two answer are indistingishable. QNAME -> CNAME -> non-existant name in zone -> no error QNAME -> CNAME -> existant name in zone but no data -> no error I don't think that was ever intended. > | a recursive server has to follow out-of-zone cnames and thus, > | will keep searching until there is a definitive answer. > > Of course. > > | an authority server does not have to follow out-of-zone cnames and > | so, can return a dangling cname chain (ANCOUNT>0) and no error (RCODE=0) > | which is a partial, nondefinitive result. > > Yes, of course. > > | if the cname is in-zone, an > | authority server will give a definitive result very much like the one above > > That's what I don't think it should do, the name queried did exist, it > should not be NXDOMAIN. > > | (which i now realize probably ought to include an SOA RR in its authority.) > > Yeah - but that's hardly relevant just now... > > | that's what everybody does, and it's the only way that a recursive server > | who talks to that authority server is going to be able to build a > | complete CNAME chain when out-of-zone CNAMEs are allowed. > > Really? I sure must be missing some problem, as that just doesn't > sound that difficult to me (more packets than we'd like to send perhaps, > but dangling CNAMES also, one hopes, aren't a very common disease.) > > | when i put this question to PVM about ten years ago, he said "out-of-zone > | CNAME RRs were never part of my early thinking on DNS, so the spec is > | incomplete on that point" and "good luck storming the castle, boys!" > > That's probably true, but it isn't out of zone CNAMEs that we're really > discussing, what the auth server does there is pretty clear, and we agree > on that I think, its in zone CNAMEs where we're disagreeing about what is > the appropriate response. > > | you mean like this? > > Yes, but that's boring, and isn't really adding everything, we all > agree (I hope) that that response is correct, > > | how would an iterative resolver ever build a complete cname chain in that > | case, if out-of-zone CNAMEs are present? > > I can't believe that you're asking for a lesson on pointer chasing, so > I won't give one, but ***really***! > > | i think we have to make it clear > | that RFC 1035 did not know about out-of-zone CNAMEs and that when those are > | present we have to look at a larger picture than the definition of RCODE=3. > > I think it would be OK to make that point somewhere (the first of your > two points), but I'm also not sure it is relevant right now, as that's > actually the easy case. > > I kind of suspect that people have been hung up on the idea that if the > canonical name doesn't exist, then its alias cannot exist. To me that's > just wrong, the alias exists, and no lookup of it should give name error. > > I never really paid a lot of attention to all of the DNSSEC stuff about > proof of non-existance, but I can't even imagine the convoluted chain of > logic that would be needed to attempt to authoritatively claim that a > "name error" is correct for a name that demonstratively exists (and for > which, a different query - type=CNAME - would be required to say "does > exist"). That would just be perverse. > > 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: -- 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 Feb 8 17:19: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 5AF6328C3A8; Fri, 8 Feb 2008 17:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.291 X-Spam-Level: X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNBXAUr20tVY; Fri, 8 Feb 2008 17:19:46 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9DF0E28C2B9; Fri, 8 Feb 2008 17:19:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNeEc-000H0x-Vh for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:10:26 +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 1JNeEa-000Gzu-Dd for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 01:10:25 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m191AF7n023076; Fri, 8 Feb 2008 20:10:16 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802082359.m18NxgvG065654@drugs.dv.isc.org> References: <200802082359.m18NxgvG065654@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 20:10:14 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis Cc: ed.lewis@neustar.biz 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:59 +1100 2/9/08, Mark Andrews wrote: > ra=1 and rd=1 ...(for clarity, a server willing to do recursion and a query wanting it) > QNAME -> CNAME -> non-existant name in zone -> name error > QNAME -> CNAME -> non-existant name on other server -> name error The latter two sound incorrect according to RFC 1035, section 4.1.1 ... RCODE 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. Even if the recursion is done by a server that is authoritative for the QNAME, the QNAME has to exist for it to have a CNAME. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 17:32: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 F2FA028C86C; Fri, 8 Feb 2008 17:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+M03+2Zez8i; Fri, 8 Feb 2008 17:32:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7AB7728C8F7; Fri, 8 Feb 2008 17:29:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNeS8-000Iq9-A1 for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:24:24 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNeS5-000Ipn-K5 for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 01:24:23 +0000 Received: (qmail 13894 invoked from network); 9 Feb 2008 01:01:40 -0000 Received: from softbank219001188017.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.17) by necom830.hpcl.titech.ac.jp with SMTP; 9 Feb 2008 01:01:40 -0000 Message-ID: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> Date: Sat, 09 Feb 2008 09:10:46 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: AXFR over UDP is available References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Edward Lewis wrote: > http://www.ietf.org/internet-drafts/draft-lewis-axfr-over-udp-00.txt I'm afraid you completely misunderstand the previous discussion. First of all, you failed to convince us that changes to enable AXFR over UDP is desirable. But, let's ignore it for the rest of my message. RFC1995 says: When an IXFR request with an older version number is received, the IXFR server needs to send only the differences required to make that version current. Alternatively, the server may choose to transfer the entire zone just as in a normal full zone transfer. As full zone (AXFR) over UDP is already available with IXFR, the only thing we need to support AXFR over UDP is to disable differences (IXFR) over UDP. That is, an configuration option on IXFR servers to disable UDP differential transfer and to encourage UDP full transfer is just fine. An IXFR server which is incapable of any differential transfer is also fine. IXFR clients, against zone administrators policy to allow differential transfer, insisting on full transfer can ignore UDP differential transfer responses and initiate TCP AXFR, which causes no extra packet exchanges. There is absolutely no protocol work left. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 17:52: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 72EF828C3C1; Fri, 8 Feb 2008 17:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGr4MxYglLcJ; Fri, 8 Feb 2008 17:52:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 21BF83A6820; Fri, 8 Feb 2008 17:52:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNenz-000LdF-UY for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:46:59 +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 1JNenw-000Lcr-Ae for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 01:46:58 +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 m191kfag003878; Sat, 9 Feb 2008 12:46:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090146.m191kfag003878@drugs.dv.isc.org> To: Robert Elz Cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Sat, 09 Feb 2008 03:14:36 +0700." <15222.1202501676@epsilon.noi.kre.to> Date: Sat, 09 Feb 2008 12:46:41 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Date: Sat, 09 Feb 2008 00:14:34 +1100 > From: Mark Andrews > Message-ID: <200802081314.m18DEYoq023801@drugs.dv.isc.org> > > > | RFC 1034 allows a name error to be returned from a cache. > | RFC 2308 allows a authoritive name error to be returned > | from a cache. > | RFC 403[345] allow a name error to be cryptographically > | validiated in the response from a cache. > > Yes, I know, as I said, the part about "only relevant in an auth > answer" is not the way things work, that part was wrong. > > | In all case the name at the end of the CNAME chain is what > | is being referred to by the name error. > > That part I think is a mistake, it is logically wrong. > > | Prior to RFC 2308 the cache had to make a new query each > | time you got to the end of the CNAME chain then "append" > | the result. > > Yes. That's what it needs to do if the data hasn't been included in > the answer - that's clearly needed for an out of zone CNAME reply from > a non-recursive server (there's no other way forward, whether or not > the canonical name exists), doing the same thing for an apparently > in-zone CNAME doesn't seem to be a great burden to me ("apparently" > as there isn't any way to tell (without a bunch of extra queries) if > the canonical name is in the same zone as the alias or not, so there > cannot really be different behaviours.) Only if there is not a SOA add or a referral added or a NXDOMAIN rcode added. The real problem is that there wasn't a NODATA rcode. NODATA is inferred. It's a rare that none of these are done. > What's more, if the > canonical name doesn't exist, then it is impossible to say that > it would have been in the same zone had it existed, we cannot possibly > know (we do sometimes know that it cannot have been in the same zone, > but never that it must have been.) > > What I'm trying to say, is that if you get a noerror and a cname, and > no record of the type being queried, then you always MUST do another > query. By defining the rcode to relate to the end of the (included > in the response, I assume) CNAME chain, all you're really doing is > occasionally saving a query (in the comparatively unusual case of > dangling CNAMEs). I don't believe that's worth the inconsistency > it generates. > > | The stub resolver was not expected to do > | this and no stub resolver, as far as I am aware, will issue > | a second query on a CNAME chain the terminates on with NoError. > > No, and that's fine, its recursive server (since it returned an answer) > has already done all the work - if there's no terminating type==A (or > whatever the query type was) in the response, then it doesn't exist. > > | Also no stub resolver goes and follows the authority and > | additional sections to retrieve a NXDOMAIN response as you > | interpretation would require them to do > > No I don't, why is a NXDOMAIN needed? All it needs to know is that > the data it sought doesn't exist. When it fails to find that data > in the response from its cache (back end resolver), it knows all it > needs to know. If the stub resolver can't get this information then how is it to meet this requirement of RFC 1034? Think MTA and MX query response. 5.2. Client-resolver interface It is important to note that the functions for translating between host names and addresses may combine the "name error" and "data not found" error conditions into a single type of error return, but the general function should not. One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information; if the two errors are combined, then useless queries may slow the application. > | as it precludes a > | caching resolver *ever* returning NXDOMAIN whether proceeded > | by CNAMEs or not. > > No, I agree that negative answers from caches are fine (and I said > that last time...) > > | RFC 1034 and RFC 1035 have lots of errors in them. > > Yes. We are discussing an inconsistency between them, so clearly one > of them is wrong. The question is, which one? > > It has been a long time since I read 2308, I will look at it again. > > kre > -- 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 Feb 8 17:55: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 292CC3A6989; Fri, 8 Feb 2008 17:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQBoevTrcTrI; Fri, 8 Feb 2008 17:55:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5B8DC3A6820; Fri, 8 Feb 2008 17:55:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNerg-000MQr-4B for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:50:48 +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 1JNerc-000MQM-AS for namedroppers@ops.ietf.org; Sat, 09 Feb 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 m191oZ1A004031; Sat, 9 Feb 2008 12:50:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090150.m191oZ1A004031@drugs.dv.isc.org> To: Edward Lewis Cc: Wouter Wijngaards , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Fri, 08 Feb 2008 11:41:25 CDT." Date: Sat, 09 Feb 2008 12:50:35 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 19:18 +1100 2/8/08, Mark Andrews wrote: > > > * So that you can easily correct mistakes. > > You can cover that via clever scripting. Once I added 100's of names > incorrectly. I just modified the "add" to "delete" in the script and > took them out. > > But granted, easy to fix would be nice. I question it is necessary. > > > * So you can build namespace before you remove a DNAME. > > But, atomicity of dynamic updates can solve that. "delete DNAME, add > these" can be in one step. Try changing > 64K of zone data atomically. > > We obscure as that matched NS and preserved the DNAME semantics. > > So you are saying that you implemented DNAME much like (similar?) NS? > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. -- 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 Feb 8 18:00: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 B0FFE3A6FA0; Fri, 8 Feb 2008 18:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzlyfWw98sZa; Fri, 8 Feb 2008 18:00:27 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B72C83A74D4; Fri, 8 Feb 2008 18:00:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNevh-000N1m-SL for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:54:57 +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 1JNeve-000N18-Jh for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 01:54:56 +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 m191so3i004053; Sat, 9 Feb 2008 12:54:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090154.m191so3i004053@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Fri, 08 Feb 2008 11:23:43 CDT." Date: Sat, 09 Feb 2008 12:54:50 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 14:26 +1100 2/8/08, Mark Andrews wrote: > > > At the apex. It's perfect fine to add and delete NS RRsets > > at the bottom of zone. DNAME is always at bottom of zone > > even when it is at the apex. > > Ergo, NS processing is not "similar" to DNAME, right? DNAME can be > at the apex or not, there's no difference. There are NS records at the apex. There are NS records that delegate. The NS records that delegate are the one that obscure zone content. These NS RRsets behave similarly to DNAME. They are the only NS records which obscure data. > > Because you can't ADD a DNAME which obscures some record > > then STOP and RESTART the server. > > I don't know how to read that. By the rules of DNAME, it isn't > allowed to "obscure" domain names. So, no, you can't do that. > > Should we want to? Yes. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: -- 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 Feb 8 18:01: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 BBF4228C333; Fri, 8 Feb 2008 18:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiIjWb6mYLtj; Fri, 8 Feb 2008 18:01:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EC1A83A74D4; Fri, 8 Feb 2008 18:01:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNevq-000N2t-Qq for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:55:06 +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 1JNevf-000N1F-S2 for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 01:54:57 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m191siP2023427; Fri, 8 Feb 2008 20:54:45 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> References: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> Date: Fri, 8 Feb 2008 20:54:34 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: AXFR over UDP is available Cc: Edward Lewis 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 9:10 +0900 2/9/08, Masataka Ohta wrote: >Edward Lewis wrote: > >> http://www.ietf.org/internet-drafts/draft-lewis-axfr-over-udp-00.txt > >I'm afraid you completely misunderstand the previous discussion. No, but I clearly was judging the discussion through different eyes. >First of all, you failed to convince us that changes to enable >AXFR over UDP is desirable. But, let's ignore it for the rest of >my message. I wasn't trying to. I wanted to get flesh out the protocol to see first if it is viable. It's an engineering document, not a marketing one. The initial discussion convinced me that it is worth proposing. If the extension is viable, then a use case can be added. The reason I went forward on "weak evidence" of demand is that I know that if there's AXFR over UDP in a separate document, it will get the traction of people issuing RFPs for DNS and DNS-like service. There is a tendency for folks to do a quick search of titles for capability, rarely/never have I seen any one go inside an RFC and profile a set of services. >RFC1995 says: > > When an IXFR request with an older version number is received, the > IXFR server needs to send only the differences required to make that > version current. Alternatively, the server may choose to transfer > the entire zone just as in a normal full zone transfer. The problem with the above is that it either means: 1) You have to go to TCP 2) You attempt to do the transfer over UDP - but fall into the problems of mis-ordered packets, etc. (which I disucss in one of the two drafts, I forget which already) We'd have to clear that up in IXFR. >As full zone (AXFR) over UDP is already available with IXFR, the only >thing we need to support AXFR over UDP is to disable differences (IXFR) >over UDP. > >That is, an configuration option on IXFR servers to disable UDP >differential transfer and to encourage UDP full transfer is just >fine. > >An IXFR server which is incapable of any differential transfer is >also fine. > >IXFR clients, against zone administrators policy to allow differential >transfer, insisting on full transfer can ignore UDP differential >transfer responses and initiate TCP AXFR, which causes no extra packet >exchanges. > >There is absolutely no protocol work left. Except for what you prescribed in your message and clear up my note about the RFC 1995 passage. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 18:02: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 5EAE43A74D4; Fri, 8 Feb 2008 18:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOe9HGBN7LBP; Fri, 8 Feb 2008 18:02:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BF6643A6989; Fri, 8 Feb 2008 18:02:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNeyo-000NfP-Rw for namedroppers-data@psg.com; Sat, 09 Feb 2008 01:58: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 1JNeym-000Ndd-CM for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 01:58:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1983F1142F; Sat, 9 Feb 2008 01:58:08 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Masataka Ohta cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: AXFR over UDP is available In-Reply-To: Your message of "Sat, 09 Feb 2008 09:10:46 +0900." <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> References: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 09 Feb 2008 01:58:08 +0000 Message-ID: <32264.1202522288@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > There is absolutely no protocol work left. > > Masataka Ohta i agree. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 18:05: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 4709428C1C9; Fri, 8 Feb 2008 18:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf2Tbv8i5GCh; Fri, 8 Feb 2008 18:05:21 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8CE0528C6C6; Fri, 8 Feb 2008 18:05:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNf1A-000OE9-8l for namedroppers-data@psg.com; Sat, 09 Feb 2008 02:00:36 +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 1JNf17-000OD4-2j for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 02:00:34 +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 m1920NJS004182; Sat, 9 Feb 2008 13:00:23 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090200.m1920NJS004182@drugs.dv.isc.org> To: Edward Lewis Cc: Wouter Wijngaards , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Fri, 08 Feb 2008 11:41:25 CDT." Date: Sat, 09 Feb 2008 13:00:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 19:18 +1100 2/8/08, Mark Andrews wrote: > > > * So that you can easily correct mistakes. > > You can cover that via clever scripting. Once I added 100's of names > incorrectly. I just modified the "add" to "delete" in the script and > took them out. > > But granted, easy to fix would be nice. I question it is necessary. That's the whole point of obsuring the names and not deleting them. You can turn a add into a delete and restore the zone state. > > * So you can build namespace before you remove a DNAME. > > But, atomicity of dynamic updates can solve that. "delete DNAME, add > these" can be in one step. > > > We obscure as that matched NS and preserved the DNAME semantics. > > So you are saying that you implemented DNAME much like (similar?) NS? > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: -- 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 Feb 8 18:05: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 61ABF28C6C6; Fri, 8 Feb 2008 18:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[AWL=1.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iU-CbIAgcU02; Fri, 8 Feb 2008 18:05:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A6E0628C6FB; Fri, 8 Feb 2008 18:05:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNf1n-000OP6-Mr for namedroppers-data@psg.com; Sat, 09 Feb 2008 02:01:15 +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 1JNf1k-000OOA-Tt for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 02:01:14 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1920tDi023475; Fri, 8 Feb 2008 21:00:55 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802090150.m191oZ1A004031@drugs.dv.isc.org> References: <200802090150.m191oZ1A004031@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 21:00:48 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: Edward Lewis , Wouter Wijngaards , namedroppers@ops.ietf.org 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 12:50 +1100 2/9/08, Mark Andrews wrote: > Try changing > 64K of zone data atomically. Yeah, it's a lot of work. But computers are big these days and pretty good a tedious tasks. In contexts that matter, resource limits are not tested. What we're talking about is an extreme situation, a corner case. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 18:09: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 B430C28C759; Fri, 8 Feb 2008 18:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiGgDbcWGAkp; Fri, 8 Feb 2008 18:09:15 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 129CC28C6FB; Fri, 8 Feb 2008 18:09:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNf4T-000Oqh-L4 for namedroppers-data@psg.com; Sat, 09 Feb 2008 02:04:01 +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 1JNf4Q-000OqI-PJ for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 02:03:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7B52E11432; Sat, 9 Feb 2008 02:03:58 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-Reply-To: Your message of "Fri, 08 Feb 2008 20:26:36 GMT." <18549.1202502396@sa.vix.com> References: <200802080326.m183QTJo045227@drugs.dv.isc.org> <47ACAD64.6080802@nist.gov> <18549.1202502396@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 09 Feb 2008 02:03:58 +0000 Message-ID: <32485.1202522638@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > ... if you try to add a DNAME to a name that has records or children, you > should get a YXDOMAIN error. likewise, if you try to load a zone that has any other records at a name when there is a CNAME or DNAME at that name, or has any children under a name that has a DNAME or NS, the zone should be rejected. -- to unsubscribe send a message to namedroppers-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 Feb 8 18:13:31 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 93F5728C7EA; Fri, 8 Feb 2008 18:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJAI0zIhcSKX; Fri, 8 Feb 2008 18:13:30 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 19E4128C6C6; Fri, 8 Feb 2008 18:12:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNf6S-000PD4-Bv for namedroppers-data@psg.com; Sat, 09 Feb 2008 02:06:04 +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 1JNf6P-000PBy-43 for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 02:06:02 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1925nXu023543; Fri, 8 Feb 2008 21:05:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802090154.m191so3i004053@drugs.dv.isc.org> References: <200802090154.m191so3i004053@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 21:05:36 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: Edward Lewis , namedroppers@ops.ietf.org 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 12:54 +1100 2/9/08, Mark Andrews wrote: > Yes. Why? What's missing from your answer is a justification. As it stands now, the WG document says "can't be done." If you want to get consensus for what you want, you need to do some explaining. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 18:15: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 14DB828C6C6; Fri, 8 Feb 2008 18:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj28yquUNVyK; Fri, 8 Feb 2008 18:15:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5F1D928C1C9; Fri, 8 Feb 2008 18:15:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNf9T-000Poc-1a for namedroppers-data@psg.com; Sat, 09 Feb 2008 02:09:11 +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 1JNf9Q-000Pno-B1 for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 02:09:09 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1928vdb023570; Fri, 8 Feb 2008 21:08:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200802090154.m191so3i004053@drugs.dv.isc.org> Date: Fri, 8 Feb 2008 21:08:55 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: Mark Andrews , Edward Lewis , namedroppers@ops.ietf.org 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 21:05 -0500 2/8/08, Edward Lewis wrote: >At 12:54 +1100 2/9/08, Mark Andrews wrote: > >> Yes. > >Why? Okay, in our passing messages it struck me that the reason is for "recovering from mistakes." Is that all? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Feb 8 18:54: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 0BEEA28C6FB; Fri, 8 Feb 2008 18:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpf-E4ve-Z2k; Fri, 8 Feb 2008 18:54:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E1EA528C614; Fri, 8 Feb 2008 18:54:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNfiE-0005Nf-NK for namedroppers-data@psg.com; Sat, 09 Feb 2008 02:45:06 +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 1JNfiB-0005My-IB for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 02:45:05 +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 m192iwVl004809; Sat, 9 Feb 2008 13:44:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090244.m192iwVl004809@drugs.dv.isc.org> To: Scott Rose Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Fri, 08 Feb 2008 14:28:36 CDT." <47ACAD64.6080802@nist.gov> Date: Sat, 09 Feb 2008 13:44:58 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Edward Lewis wrote: > > > >> Because you can't ADD a DNAME which obscures some record > >> then STOP and RESTART the server. > > > > I don't know how to read that. By the rules of DNAME, it isn't allowed > > to "obscure" domain names. So, no, you can't do that. > > > > Should we want to? > > So when it comes to names under a DNAME - obscure/delete/remove all > basically mean the same thing (in the protocol) and the only difference > is in bookkeeping on the server side as to what to do with the actual > RRs. Is that the point? > > In which case the first paragraph of Section 5.2 can be changed to read: > > DNAME resource records can be added, changed and removed. > Adding a DNAME RR removes all domain names that would appear > under the newly added DNAME RR. The zone data that is > removed MAY still exist on the local server in some form > but MUST NOT be used as zone data when responding to queries Yes > and MUST NOT be included in zone transfer operations. No. > Then the following two paragraphs of Section 5.2. Removed can be > interpreted as obscured, deleted, copied to another file, or some other > operation - it is up to the implementation. > > -- > ---------------------------------------- > Scott Rose Computer Scientist > NIST > ph: +1 301-975-8439 > scott.rose@nist.gov > > http://www-x.antd.nist.gov/dnssec > http://www.dnsops.gov/ > ----------------------------------------- > > -- > to 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 Fri Feb 8 20:01: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 08B7A28C815; Fri, 8 Feb 2008 20:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq75IOSkmZJr; Fri, 8 Feb 2008 20:01:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6CD8A28C5A1; Fri, 8 Feb 2008 20:01:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNgl8-000F4G-7e for namedroppers-data@psg.com; Sat, 09 Feb 2008 03:52: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 1JNgl5-000F2x-8l for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 03:52:08 +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 m193q1qb005703; Sat, 9 Feb 2008 14:52:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090352.m193q1qb005703@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Fri, 08 Feb 2008 20:10:14 CDT." Date: Sat, 09 Feb 2008 14:52:01 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 10:59 +1100 2/9/08, Mark Andrews wrote: > > > ra=1 and rd=1 > ...(for clarity, a server willing to do recursion and a query wanting it) > > > QNAME -> CNAME -> non-existant name in zone -> name error > > QNAME -> CNAME -> non-existant name on other server -> name error > > The latter two sound incorrect according to RFC 1035, section 4.1.1 ... > > RCODE 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist. > > Even if the recursion is done by a server that is authoritative for > the QNAME, the QNAME has to exist for it to have a CNAME. Yet if you read RFC 1034 they are correct. There are inconstancies and errors all through RFC 1034 and RFC 1035. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: -- 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 Feb 8 20:02: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 D982A3A6FA0; Fri, 8 Feb 2008 20:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBjQ3tRjpOW7; Fri, 8 Feb 2008 20:02:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 26A0628C3E8; Fri, 8 Feb 2008 20:02:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNgqR-000Fs2-E7 for namedroppers-data@psg.com; Sat, 09 Feb 2008 03:57: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 1JNgqO-000Fqx-PS for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 03:57:38 +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 m193vWlu005830; Sat, 9 Feb 2008 14:57:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090357.m193vWlu005830@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Fri, 08 Feb 2008 21:08:55 CDT." Date: Sat, 09 Feb 2008 14:57:32 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 21:05 -0500 2/8/08, Edward Lewis wrote: > >At 12:54 +1100 2/9/08, Mark Andrews wrote: > > > >> Yes. > > > >Why? > > Okay, in our passing messages it struck me that the reason is for > "recovering from mistakes." > > Is that all? Errors. Consistancy. Atomic change. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. -- 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 Feb 8 21:02: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 233DD28C838; Fri, 8 Feb 2008 21:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw4e+Wk9Tsgm; Fri, 8 Feb 2008 21:02:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8BAB028C6FB; Fri, 8 Feb 2008 21:02:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNhj0-000NXR-0I for namedroppers-data@psg.com; Sat, 09 Feb 2008 04:54:02 +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 1JNhix-000NWv-7q for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 04:54:00 +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 m194ru04043740 for ; Sat, 9 Feb 2008 15:53:56 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090453.m194ru04043740@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: draft-ietf-dnsext-axfr-clarify-07.txt: 2.1.1 Header Values Date: Sat, 09 Feb 2008 15:53:56 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Note 2.1.1.a Set to any value that the client desires. There is no specific means for selecting the value in this field. However, consideration can be given to making it harder for forged messages to be accepted by referencing the work in progress "Measures for making DNS more resilient against forged answers" [FORGERY]. ID MUST differ from any un-answered query previously issued on the TCP connection. [FORGERY] is really not applicable here. Sequentual ID's are prefectly reasonable on a TCP connection. -- 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 Feb 8 21:16: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 6DDAA3A70A2; Fri, 8 Feb 2008 21:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW7hxtGXGrp2; Fri, 8 Feb 2008 21:16:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BD3393A6BB2; Fri, 8 Feb 2008 21:16:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNhxV-00006j-UR for namedroppers-data@psg.com; Sat, 09 Feb 2008 05:09:01 +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 1JNhxS-00005o-QO for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 05:09:00 +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 m1958vpB043944 for ; Sat, 9 Feb 2008 16:08:57 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090508.m1958vpB043944@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: draft-ietf-dnsext-axfr-clarify-07.txt: 2.2 AXFR response Date: Sat, 09 Feb 2008 16:08:57 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion An AXFR client MUST be able to react to no AXFR response Messages from the server. An AXFR server MAY elect to silently discard the AXFR query but this is only RECOMMENDED if the server has reasons to deduce that the query was sent maliciously. So a client in expected to detect when the server has silently discarded a messages? How is it supposed to detect this? Wait 1 minute, 10, 60, a day, a week, a month, a year. A server MUST respond to a request over TCP. There is no retry with TCP. A client can potentially wait indefinately for a response. 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 Feb 8 21:29: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 71DAA28C759; Fri, 8 Feb 2008 21:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVZjiu2Fvx3E; Fri, 8 Feb 2008 21:29:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AE65428C6AF; Fri, 8 Feb 2008 21:29:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNiBa-0002ly-JN for namedroppers-data@psg.com; Sat, 09 Feb 2008 05:23:34 +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 1JNiBY-0002lf-11 for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 05:23:33 +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 m195NUst044056 for ; Sat, 9 Feb 2008 16:23:30 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802090523.m195NUst044056@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-axfr-clarify-07.txt: 2.1.1 Header Values In-reply-to: Your message of "Sat, 09 Feb 2008 15:53:56 +1100." <200802090453.m194ru04043740@drugs.dv.isc.org> Date: Sat, 09 Feb 2008 16:23:30 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > Note 2.1.1.a Set to any value that the client desires. There > is no specific means for selecting the value in this field. However, > consideration can be given to making it harder for forged messages to be > accepted by referencing the work in progress "Measures for making DNS > more resilient against forged answers" [FORGERY]. > > ID MUST differ from any un-answered query previously > issued on the TCP connection. s/un-answered/outstanding/ > [FORGERY] is really not applicable here. Sequentual > ID's are prefectly reasonable on a TCP connection. > -- > 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: -- 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 Feb 9 04:55: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 68B2828C917; Sat, 9 Feb 2008 04:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhnQQhMRW+29; Sat, 9 Feb 2008 04:55:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A8FF728C961; Sat, 9 Feb 2008 04:55:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNp2n-000FWs-Qp for namedroppers-data@psg.com; Sat, 09 Feb 2008 12:42:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNp2l-000FWR-2P for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 12:42:56 +0000 Received: (qmail 89920 invoked from network); 9 Feb 2008 12:57:16 -0000 Received: from softbank219178199025.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 9 Feb 2008 12:57:16 -0000 Message-ID: <47AD971C.1060900@necom830.hpcl.titech.ac.jp> Date: Sat, 09 Feb 2008 21:05:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: AXFR over UDP is available References: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Edward Lewis wrote: >> First of all, you failed to convince us that changes to enable >> AXFR over UDP is desirable. But, let's ignore it for the rest of >> my message. > I wasn't trying to. That's your fault. > 2) You attempt to do the transfer over UDP - but fall into the problems > of mis-ordered packets, etc. (which I disucss in one of the two drafts, > I forget which already) You, merely confusingly, mentioned that UDP reply should be one message (though RFC1035, further, remotely restrict the message contained in one packet), while RFC1995 clearly restrict reply one packet (which could be fragmented into multiple packets without causing misorderging): Transport of a query may be by either UDP or TCP. If an IXFR query is via UDP, the IXFR server may attempt to reply using UDP if the entire response can be contained in a single DNS packet. -- Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 9 07:03: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 EBB023A699A; Sat, 9 Feb 2008 07:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWVazuS4GLoX; Sat, 9 Feb 2008 07:03:24 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DEF0028C9C2; Sat, 9 Feb 2008 07:02:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNr3j-000Bx1-3o for namedroppers-data@psg.com; Sat, 09 Feb 2008 14:52:03 +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 1JNr3g-000Bwg-M9 for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 14:52:01 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m19EoYAh053410; Sat, 9 Feb 2008 09:50:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <47AD971C.1060900@necom830.hpcl.titech.ac.jp> References: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> <47AD971C.1060900@necom830.hpcl.titech.ac.jp> Date: Sat, 9 Feb 2008 09:43:00 -0500 To: Masataka Ohta From: Edward Lewis Subject: Re: AXFR over UDP is available Cc: Edward Lewis , namedroppers@ops.ietf.org 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 21:05 +0900 2/9/08, Masataka Ohta wrote: >You, merely confusingly, mentioned that UDP reply should be one >message (though RFC1035, further, remotely restrict the message >contained in one packet), while RFC1995 clearly restrict reply >one packet (which could be fragmented into multiple packets without >causing misorderging): What do you mean by "merely confusingly?" Is there something unclear in my draft? > Transport of a query may be by either UDP or TCP. If an IXFR query > is via UDP, the IXFR server may attempt to reply using UDP if the > entire response can be contained in a single DNS packet. If that's the case, okay. I didn't have time to read RFC1995 to find that. In IXFR, can the client 'force' a full zone transfer? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 9 07:06: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 D68113A714F; Sat, 9 Feb 2008 07:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.478 X-Spam-Level: X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx7Vd2EOKpE4; Sat, 9 Feb 2008 07:06:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9730528C99E; Sat, 9 Feb 2008 07:06:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNrAg-000DKT-VR for namedroppers-data@psg.com; Sat, 09 Feb 2008 14:59:14 +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 1JNrAe-000DJx-Gb for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 14:59:13 +0000 Received: from [10.31.65.205] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m19EwgR8053771; Sat, 9 Feb 2008 09:58:53 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802090357.m193vWlu005830@drugs.dv.isc.org> References: <200802090357.m193vWlu005830@drugs.dv.isc.org> Date: Sat, 9 Feb 2008 09:58:31 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt Cc: Edward Lewis , namedroppers@ops.ietf.org 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 14:57 +1100 2/9/08, Mark Andrews wrote: > Errors. Consistancy. Atomic change. Up until last night I was inclined to prefer "obscuring" to "preventing." By obscuring, I mean the addition of the DNAME hides the other names but they stay in the zone's memory. By preventing, I mean that the attempt to add the DNAME is rebuffed if there are names that would be obscured. The reason is that 'obscuring' is an implicit, unstated action taken as the result of another. Just like the third semantic possible here (the addition causes the implicit loss of the would be obscured names), there is an unintended consequence. The "error" we are talking about here is merely the mistaken addition of a DNAME at the wrong owner name or mistaken in the sense that the operator forget there was a name somewhere. In this case, obscuring is better than removing. But prevention is even better. If the operator tries to add the record and gets an error, the mistake is caught in live time, obvious, concrete. (Note that the writing sounds like dynamic update, but this goes for zone load too.) When it comes to to consistency, again I think that obscuring is the wrong choice, as in the question in a previous message. Are the obscured in the zone transfer? If they are, it's pretty much a waste, isn't it? I really think we want to avoid allowing for (more) obscured elements in the DNS. Atomic change. I don't understand how that relates. I'd guess though that any action that has an intentional unintended side effect would be detrimental to atomicity because of the potential shear volume of actions that might ensue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 9 07:17: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 B28F93A6A73; Sat, 9 Feb 2008 07:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPHPVnqwgVnj; Sat, 9 Feb 2008 07:17:58 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4F40728C94B; Sat, 9 Feb 2008 07:16:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNrKq-000FCN-2s for namedroppers-data@psg.com; Sat, 09 Feb 2008 15:09:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNrKn-000FBq-5h for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 15:09:42 +0000 Received: (qmail 5059 invoked from network); 9 Feb 2008 15:48:58 -0000 Received: from softbank219178199025.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 9 Feb 2008 15:48:58 -0000 Message-ID: <47ADBF58.6080809@necom830.hpcl.titech.ac.jp> Date: Sat, 09 Feb 2008 23:57:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: AXFR over UDP is available References: <47ACEF86.1050007@necom830.hpcl.titech.ac.jp> <47AD971C.1060900@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Edward Lewis wrote: > I didn't have time to read RFC1995 to find that. Again, that's your fault. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 10 11:32: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 E7EBA3A67A9; Sun, 10 Feb 2008 11:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[AWL=1.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxksgmdoCbBx; Sun, 10 Feb 2008 11:32:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B6DAC3A6854; Sun, 10 Feb 2008 11:32:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNyAQ-000Bzx-51 for namedroppers-data@psg.com; Sat, 09 Feb 2008 22:27:26 +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 1JNyAI-000Byk-RM for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 22:27:24 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m19MOfYu012206; Sun, 10 Feb 2008 05:24:42 +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 m19MOMQH022288; Sun, 10 Feb 2008 05:24:24 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: <200802082359.m18NxgvG065654@drugs.dv.isc.org>, <200802090146.m191kfag003878@drugs.dv.isc.org> References: <200802082359.m18NxgvG065654@drugs.dv.isc.org>, <200802090146.m191kfag003878@drugs.dv.isc.org>, <200802090352.m193q1qb005703@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Feb 2008 05:24:22 +0700 Message-ID: <20281.1202595862@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Sat, 09 Feb 2008 10:59:42 +1100 From: Mark Andrews Message-ID: <200802082359.m18NxgvG065654@drugs.dv.isc.org> | Actually it was making the difference. You only get to that | part of the algorithm if you recursion was not requested | or not available (See step 1). I think some of the problem that we're having is that you're slavishly following the precise words of 1034, despite (many times) also saying ... There are inconstancies and errors all through RFC 1034 and RFC 1035. (this particular instance from a reply to Ed Lewis, Sat, 09 Feb 2008 14:52:01 +1100). That just makes no sense, if they're full of errors (and they are) then what we need to do is look and see what should be correct, and then ignore the parts of 1034 (& 1035) which contradict that - those being the parts we decide are the errors. Otherwise we have known inconsistencies, but no method to use to determine what the correct position should be. The results you quote are correct if you follow the algorithms in 1034 4.3.2 and 5.3.3 (and if you make some inferences about what 5.3.3 actually says, since it never actually explicitly says what you believe it does, though I can see you could read it that way). But as you've pointed out, this doesn't make sense - I think in one earlier message you even proposed making a CNAME to a non-existing canonical name be illegal, to avoid the issue. But the simpler solution is just to make step 4a of 5.3.3 clearer, to indicate (as is done in the 4.3.2 algorithm) that you only return Name Error (or for that matter, any other error) if there was no CNAME encountered before finding the error. | You will note that the following two answer are indistingishable. | | QNAME -> CNAME -> non-existant name in zone -> no error | QNAME -> CNAME -> existant name in zone but no data -> no error | | I don't think that was ever intended. Intended? Who knows? But reasonable? Why not? Two things are of interest here - does the data sought exist (no, in both cases), and does the name used for the lookup exist (yes, in both cases), so why would anyone care more than that (and if anyone really does care more, they go get auth answers from auth servers for everything they need to know, and find out that way - but that's not anything a normal name resolution would need to do.) And to avoid cluttering up everyone's mailbox with multiple replies, the following relates to a different message from you ... From: Mark Andrews Date: Sat, 09 Feb 2008 12:46:41 +1100 Message-id: <200802090146.m191kfag003878@drugs.dv.isc.org> Quoting me initially ... > as there isn't any way to tell (without a bunch of extra queries) if > the canonical name is in the same zone as the alias or not, so there > cannot really be different behaviours.) Then ... | Only if there is not a SOA add or a referral added or | a NXDOMAIN rcode added. The real problem is that there | wasn't a NODATA rcode. NODATA is inferred. | It's a rare that none of these are done. I don't agree with the real problem, rcode itself is a problem, a better solution would have been a synthesised type=ERROR RR response, where the RDATA contains the error indication (what caused the error, the TYPE it refers to (including ANY), ...) But none of that is really useful now, as that isn't what happened. In the case we're talking about, I still don't believe the NXDOMAIN should ever appear, a SOA wouldn't really help, as that might be for the zone of the QNAME, rather than the canonical name - a referral would indicate that there was another zone involved. I'm not sure that discussion of this is getting us any closer to any kind of solution to the real issue however. From the same message... | If the stub resolver can't get this information then how is | it to meet this requirement of RFC 1034? Think MTA and MX | query response. It doesn't. Big deal. That's what I was referring to in a reply a day or two ago to Paul - sure, sometimes there will be an extra query, but it should be rare, after all, dangling cnames shouldn't be a very common thing. In the normal (common case - the MX lookup, no data, A lookup sequence, which was very common in the timeframe of 1034, as MX was still somewhat rare) situation it makes very good sense to be able to avoid the A lookup when the qname doesn't exist - but the qname being an alias, and the canonical name not existing is not something we really should be optimising for. There are three arguments for accepting the 1035 definition of Name Error to what you're inferring from 1034 (and which you copied into 2308 I see) (This is, aside from the "Auth server only" part) First, 1034 is half in accordance with the 1035 definition (and the part that isn't, isn't all that clear). Second, 1035 is the DNS specification, 1034 is just a "how to do it" (concepts and facilities...) and in general, one would expect the specification to be more accurate than a "how to" derived from it. Third, if you delete the part from 1035 about Name Error referring to the name in the query, then 1035 would be left with no definition of Name Error at all (there's nothing else there) - nor does anything else define it, which to me is a pretty strong reason to keep it. Lastly, there's just plain "what should it be", that is, what makes most sense, and to me, that's for Name Error to indicate to the client "the name you gave me is incorrect, the DNS says it does not exist", rather than: "(the same) or there's some internal configuration error in the DNS so we can't find the answer for you, even though the name you searched for does in fact exist". Keep Name Error to mean a client generated error, and let DNS administrator mistakes be handled in other ways. To finish, a question: Are you special casing Name Error the way you're claiming it should work, or do you believe that all errors should be handled the same way (server failure and refused - I doubt format error and not implemented can ever be an 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 Sun Feb 10 11:34: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 48EDB3A67A9; Sun, 10 Feb 2008 11:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ2hazvGarMn; Sun, 10 Feb 2008 11:34:18 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A0D943A67A6; Sun, 10 Feb 2008 11:34:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNzLx-000O3b-Qt for namedroppers-data@psg.com; Sat, 09 Feb 2008 23:43:25 +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 1JNzLu-000O35-OR for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 23:43:24 +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 m19NhEUg023878; Sun, 10 Feb 2008 10:43:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802092343.m19NhEUg023878@drugs.dv.isc.org> To: Robert Elz Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Sun, 10 Feb 2008 05:24:22 +0700." <20281.1202595862@epsilon.noi.kre.to> Date: Sun, 10 Feb 2008 10:43:14 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Name Error - indicates that query processing terminated at a non-existant name. This covers answers from a cache. This covers answers to CNAME and ANY queries. This covers answers from an athoratiative server. -- 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 Sun Feb 10 11: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 E30EC3A6897; Sun, 10 Feb 2008 11:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGqdq3CQMdXp; Sun, 10 Feb 2008 11:34:32 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3804B3A67A9; Sun, 10 Feb 2008 11:34:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNycW-000Gxs-52 for namedroppers-data@psg.com; Sat, 09 Feb 2008 22:56: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 1JNycT-000GxG-9b for namedroppers@ops.ietf.org; Sat, 09 Feb 2008 22:56:26 +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 m19MuHw3023518; Sun, 10 Feb 2008 09:56:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802092256.m19MuHw3023518@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Sat, 09 Feb 2008 09:58:31 CDT." Date: Sun, 10 Feb 2008 09:56:17 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > When it comes to to consistency, again I think that obscuring is the > wrong choice, as in the question in a previous message. Are the > obscured in the zone transfer? If they are, it's pretty much a > waste, isn't it? I really think we want to avoid allowing for (more) > obscured elements in the DNS. No they are NOT obscured in zone transfer. Records obscured by NS cuts are NOT obscured by a zone transfer either. NS and DNAME records are both forms of delegation. NS to a different zone, DNAME to a different namespace. NS and DNAME will both obscure and reveal record by there addition / removal. The obscured records are both transmitted in AXFR / IXFR. 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 Sun Feb 10 11: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 427593A67A9; Sun, 10 Feb 2008 11:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1Cv5Wg9oIOl; Sun, 10 Feb 2008 11:34:58 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5AA543A67A6; Sun, 10 Feb 2008 11:34:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JO1Av-000GO7-0U for namedroppers-data@psg.com; Sun, 10 Feb 2008 01:40:09 +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 1JO1Ar-000GL9-Jn for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 01:40:07 +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 m1A1dtBh060973; Sun, 10 Feb 2008 12:39:56 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802100139.m1A1dtBh060973@drugs.dv.isc.org> To: Robert Elz Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Sun, 10 Feb 2008 05:24:22 +0700." <20281.1202595862@epsilon.noi.kre.to> Date: Sun, 10 Feb 2008 12:39:55 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > | You will note that the following two answer are indistingishable. > | > | QNAME -> CNAME -> non-existant name in zone -> no error > | QNAME -> CNAME -> existant name in zone but no data -> no error > | > | I don't think that was ever intended. > > Intended? Who knows? But reasonable? Why not? Two things are > of interest here - does the data sought exist (no, in both cases), > and does the name used for the lookup exist (yes, in both cases), so > why would anyone care more than that (and if anyone really does care > more, they go get auth answers from auth servers for everything they > need to know, and find out that way - but that's not anything a normal > name resolution would need to do.) For you there are two things of interest. For me there are four things of interest. Is the original name a alias or not, does the resulting name exist or not, if the name exists is there data there or not, is the query complete. A recursive server delivers all of these. You get NOERROR, NXDOMAIN or YXDOMAIN is the query is complete. You get SERVFAIL if the query does not complete. You get any CNAMEs/DNAMEs and you get the data or not. An athoritative server can deliver these as well. If the SOA record is added to NODATA and NXDOMAIN respones a authoritative server also delivers all of these. no error + SOA -> NODATA regardless of the number of preceeding CNAME / DNAME records. NXDOMAIN, with or without a SOA, inidicates that processing ended in a non-existant name independent of the number of CNAME / DNAME records It's only when you have "no error and CNAME and no SOA" you step into ambiguity. Some of that can be resolved by seeing if there is a referral. The remaining ambiguity could have been (and should have been) address by a "type error" rcode or by not making adding of the SOA record optional. Note we have a "type error" rcode these days, NXRRSET. Your wanting the NXDOMAIN response to mean "The orginal QNAME does not exist" does not work with recursive servers. It also introduces additional ambiguity. Yes we have to live with some ambiguity as there are old servers out there, we don't have to perpetuate that ambiguity. You also state that CNAME to non-existant is rare. This is currently true in the forward namespace though is becoming less so as DNAME if find more use, it is a lot less true under ARPA. RFC 2317 for IN-ADDR.ARPA and DNAME for IP6.ARPA fairly often result to CNAME to non-existant. 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 Sun Feb 10 11:37: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 4149E3A68AC; Sun, 10 Feb 2008 11:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEXZcKG2U3ek; Sun, 10 Feb 2008 11:37:03 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 014A33A6854; Sun, 10 Feb 2008 11:36:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JO09T-0006fH-6I for namedroppers-data@psg.com; Sun, 10 Feb 2008 00:34:35 +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 1JO09Q-0006eH-0q for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 00:34:33 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m1A0VtTo023595; Sun, 10 Feb 2008 07:31:55 +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 m1A0VxrD011186; Sun, 10 Feb 2008 07:32:13 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-Reply-To: <200802092343.m19NhEUg023878@drugs.dv.isc.org> References: <200802092343.m19NhEUg023878@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Feb 2008 07:31:59 +0700 Message-ID: <7975.1202603519@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Date: Sun, 10 Feb 2008 10:43:14 +1100 From: Mark Andrews Message-ID: <200802092343.m19NhEUg023878@drugs.dv.isc.org> | Name Error - indicates that query processing terminated | at a non-existant name. But that is definitely not what 1035 says, nor is it what the algorithm for auth servers in 1034 says (which agrees exactly with 1035), only (perhaps) the algorithm for caches (resolvers) in 1034. I can think of no good reason why it should be that way. You also didn't answer the question about the other error codes in the presence of CNAMEs. 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 Sun Feb 10 13: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 314873A68AE; Sun, 10 Feb 2008 13:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzZEznw3wpBy; Sun, 10 Feb 2008 13:27:37 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 944473A6832; Sun, 10 Feb 2008 13:27:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOJZC-0007LT-EP for namedroppers-data@psg.com; Sun, 10 Feb 2008 21:18:26 +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 1JOJZ9-0007Kv-2i for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 21:18:25 +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 1JOJZ2-0000aL-VV for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 22:18:16 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 232B845A0; Sun, 10 Feb 2008 22:18:19 +0100 (CET) Date: Sun, 10 Feb 2008 22:18:18 +0100 From: bert hubert To: namedroppers@ops.ietf.org Subject: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation Message-ID: <20080210211818.GA16503@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, I'm having some fun seeing how much of the internet I can resolve on IPv6 only. Since both the root-servers and the .nl servers are now reachable over IPv6, this set is not entirely empty. In fact, there is one host that can ONLY be resolved over IPv6: www.nl.ipv6.net. 172800 IN AAAA 2001:888:1037::8080 although it may require some IPv4 in between. When fixing the issues this and other domains exposed in PowerDNS, I decided to do something different. When trying to find nameserver addresses, I now internally use an 'ADDR' query, which gets translated into an ANY query. The answers that come in are then filtered to only contain A and AAAA records. The internal cache also supports ADDR queries as 'A|AAAA'. Now, from my limited testing, this appear to work! That is, the ANY query does not appear to be any less functional than an A query. It is well known that 'rd' ANY queries are useless (or at best a debugging aid), but non-rd ANY queries appear to do the job. I only turn on the AAAA queries for users that have explicitly chosen they want to use outgoing IPv6 queries for their resolution needs, so the immediate impact on PowerDNS operators would be limited. But still, I wonder if what I'm doing is technically legal, or conversely, if there are standards complying ways for this not to work. http://ds9a.nl/tmp/nl-ipv6-resolve shows a trace using the 'ADDR' pseudo-query, or download http://svn.powerdns.com/snapshots/pdns-recursor-3.1.5-snapshot4.tar.bz2 (do read the README to compile) And execute: $ ./pdns_recursor --local-port=5300 --daemon=no --socket-dir=./ --daemon=no --trace --hint-file=named.root --query-local-address6=:: For the largest amount of fun, remove all A records from the named.root And please let me know if you think this can never work, or if you think it should work, but won't. 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 Sun Feb 10 14:21: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 BEEC63A6805; Sun, 10 Feb 2008 14:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLFV43kIQRiQ; Sun, 10 Feb 2008 14:21:38 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0772A3A6803; Sun, 10 Feb 2008 14:21:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOKUR-000GCo-Fi for namedroppers-data@psg.com; Sun, 10 Feb 2008 22:17:35 +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 1JOKUO-000GCQ-Hg for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 22:17:34 +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 m1AMHQM8060394; Mon, 11 Feb 2008 09:17:26 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802102217.m1AMHQM8060394@drugs.dv.isc.org> To: bert hubert Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation In-reply-to: Your message of "Sun, 10 Feb 2008 22:18:18 BST." <20080210211818.GA16503@outpost.ds9a.nl> Date: Mon, 11 Feb 2008 09:17:26 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Just somethings to be aware of. A ANY response can be >= 64K whereas the individual A and AAAA queries are each less than 64K. A ANY query is much more likely to trigger TCP fallback. A ANY query will not trigger code paths which moves glue which matches the query to the start of the additional section. 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 Sun Feb 10 14:51: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 A26273A67FB; Sun, 10 Feb 2008 14:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imtBsWBcHZ18; Sun, 10 Feb 2008 14:51:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D3C683A67A6; Sun, 10 Feb 2008 14:51:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOKvy-000JVO-9M for namedroppers-data@psg.com; Sun, 10 Feb 2008 22:46:02 +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 1JOKvn-000JTV-TH for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 22:45:53 +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 m1AMjh8W080146; Mon, 11 Feb 2008 09:45:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802102245.m1AMjh8W080146@drugs.dv.isc.org> Cc: Robert Elz , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis In-reply-to: Your message of "Sun, 10 Feb 2008 12:39:55 +1100." <200802100139.m1A1dtBh060973@drugs.dv.isc.org> Date: Mon, 11 Feb 2008 09:45:43 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > You also state that CNAME to non-existant is rare. This > is currently true in the forward namespace though is becoming > less so as DNAME if find more use, it is a lot less true > under ARPA. RFC 2317 for IN-ADDR.ARPA and DNAME for IP6.ARPA > fairly often result to CNAME to non-existant. QUERY(AAAA) -> CNAME -> NODATA is quite common in the forward tree. www. CNAME A 1.2.3.4 This is one of the alternate sources of ambiguity if the SOA is not added. The other is where a referral to the root is required and the authoritative server does not have the information. 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 Sun Feb 10 14:52: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 CBEDE3A687D; Sun, 10 Feb 2008 14:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6R0AgtynAhn; Sun, 10 Feb 2008 14:52:08 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 31FB73A67FB; Sun, 10 Feb 2008 14:52:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOKyX-000JnH-7X for namedroppers-data@psg.com; Sun, 10 Feb 2008 22:48:41 +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 1JOKyU-000Jmm-Oe for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 22:48:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 14B1711433; Sun, 10 Feb 2008 22:48:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mark Andrews cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation In-Reply-To: Your message of "Mon, 11 Feb 2008 09:17:26 +1100." <200802102217.m1AMHQM8060394@drugs.dv.isc.org> References: <200802102217.m1AMHQM8060394@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 10 Feb 2008 22:48:37 +0000 Message-ID: <48115.1202683717@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion is it too late to say that appropriate additional data for an AAAA response includes A, and that appropriate additional data for an A response include AAAA? -- to unsubscribe send a message to namedroppers-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 Feb 10 16:00: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 068693A695A; Sun, 10 Feb 2008 16:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzUpJq4rm2t0; Sun, 10 Feb 2008 16:00:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 20DF43A6940; Sun, 10 Feb 2008 16:00:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOM1T-0000oX-2h for namedroppers-data@psg.com; Sun, 10 Feb 2008 23:55: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 1JOM1Q-0000o3-DH for namedroppers@ops.ietf.org; Sun, 10 Feb 2008 23:55:45 +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 m1ANtX9T080475; Mon, 11 Feb 2008 10:55:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802102355.m1ANtX9T080475@drugs.dv.isc.org> To: Paul Vixie Cc: bert hubert , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation In-reply-to: Your message of "Sun, 10 Feb 2008 22:48:37 -0000." <48115.1202683717@sa.vix.com> Date: Mon, 11 Feb 2008 10:55:33 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > is it too late to say that appropriate additional data for an AAAA response > includes A, and that appropriate additional data for an A response include > AAAA? It's never too late. You just can't depend on it. What is really wanted is one query. AAAA can carry A. Just make the nameservers/signers etc map A's into AAAA. Set a end-of-transition date and after that date never make A queries again, FORMERR them. Actually we need a extend version of AAAA which carries zone information. The global zone is ".". Sites and links get to choose the zone name using names already allocated to them. e.g. drugs.dv.isc.org. fe80::214:22ff:fed9:fbdc link1.dv.isc.org. drugs.dv.isc.org. fd92:7065:b8e:0:214:22ff:fed9:fbdc dv.isc.org. drugs.dv.isc.org. 2001:470:1f00:820:214:22ff:fed9:fbdc . drugs.dv.isc.org. ::ffff:192.168.191.236 dv.isc.org. getaddrinfo() would be configured to know that link1.dv.isc.org is scopeid 1 via DHCP or manually or a RA and that dv.isc.org is local, again via DHCP or manually or a RA and would filter by default. 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 Sun Feb 10 23:17: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 50E4A3A6AAB; Sun, 10 Feb 2008 23:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6h1hGxakG4l; Sun, 10 Feb 2008 23:17:15 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 550D33A6AA9; Sun, 10 Feb 2008 23:17:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOSnL-000KIz-9n for namedroppers-data@psg.com; Mon, 11 Feb 2008 07:09:39 +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 1JOSnI-000KIY-5e for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 07:09:37 +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 1JOSnA-0007uM-SR; Mon, 11 Feb 2008 08:09:28 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8B5174101; Mon, 11 Feb 2008 08:09:30 +0100 (CET) Date: Mon, 11 Feb 2008 08:09:29 +0100 From: bert hubert To: Paul Vixie Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation Message-ID: <20080211070929.GA23968@outpost.ds9a.nl> References: <200802102217.m1AMHQM8060394@drugs.dv.isc.org> <48115.1202683717@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48115.1202683717@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Sun, Feb 10, 2008 at 10:48:37PM +0000, Paul Vixie wrote: > is it too late to say that appropriate additional data for an AAAA response > includes A, and that appropriate additional data for an A response include > AAAA? That was our previous mode of operation ('hope') but it did not get very far on the internet. 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 Feb 11 08:23:31 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 C7AAB3A6C5F; Mon, 11 Feb 2008 08:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBIJBTcDVKdZ; Mon, 11 Feb 2008 08:23:30 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3A9333A6C5B; Mon, 11 Feb 2008 08:23:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JObH9-0004gI-J6 for namedroppers-data@psg.com; Mon, 11 Feb 2008 16:12:59 +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 1JObH5-0004eF-Tl for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 16:12:57 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1BG9EmI004159; Mon, 11 Feb 2008 17:09:15 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47B0732A.3030305@nlnetlabs.nl> Date: Mon, 11 Feb 2008 17:09:14 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Edward Lewis CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt References: <200802090357.m193vWlu005830@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 11 Feb 2008 17:09:17 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Lewis wrote: | At 14:57 +1100 2/9/08, Mark Andrews wrote: | |> Errors. Consistancy. Atomic change. | | But prevention is even better. If the operator tries to add the record | and gets an error, the mistake is caught in live time, obvious, concrete. I think preventing, as in return rcode YXDOMAIN(or another one) when trying to add a DNAME that obscures/stands over lower domain names is better. These are no unintended consequences to the operator's actions. It is a simple concept, and (I believe) implementation as well. I do not know how it stands to current implementations (well, BIND seems to do obscuring). NSD, refuses to load *files* with DNAMEs that obscure content. But accepts zone *transfers*, and could possibly act pretty strange with such a transfer (answering queries for obscured data, but using the DNAME to synthesize for nxdomains; and after a restart refusing to reload the zone file). The problem of trying to DNAME a huge zone, I think is something where you need to use an AXFR or IXFR for that update. Any very large update for a very large zone will be > 64 kb in any case. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHsHMqkDLqNwOhpPgRAnKUAJ96P/TkTfY0GXWm0JitoHkw8GrFKgCdHafE 6epcS50xFRVcgaIs14elnfs= =zDlD -----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 Feb 11 08:40: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 DB4A03A6C5F; Mon, 11 Feb 2008 08:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDTcZ8tRHFGb; Mon, 11 Feb 2008 08:40:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E72473A6C55; Mon, 11 Feb 2008 08:40:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JObXn-0006xF-JG for namedroppers-data@psg.com; Mon, 11 Feb 2008 16:30: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 1JObXk-0006wU-AY for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 16:30:10 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1BGU0iI081559 for ; Mon, 11 Feb 2008 17:30:00 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47B07808.8010708@nlnetlabs.nl> Date: Mon, 11 Feb 2008 17:30:00 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis References: <200802092343.m19NhEUg023878@drugs.dv.isc.org> <7975.1202603519@epsilon.noi.kre.to> In-Reply-To: <7975.1202603519@epsilon.noi.kre.to> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 11 Feb 2008 17:30:00 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Elz wrote: | From: Mark Andrews | | Name Error - indicates that query processing terminated | | at a non-existant name. | | But that is definitely not what 1035 says, nor is it what the | algorithm for auth servers in 1034 says (which agrees exactly with 1035), | only (perhaps) the algorithm for caches (resolvers) in 1034. | | I can think of no good reason why it should be that way. It seems to me that the definition of NXDOMAIN is in error, and could be expanded to include not only that the query name does not exist, but 'a nonexistant domain was encountered during the processing of the query'. That could be what Mark means with 'inconsistencies and errors in 1034'. | You also didn't answer the question about the other error codes | in the presence of CNAMEs. They mean the same as for non-CNAMEs, processing errors occurred. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHsHgIkDLqNwOhpPgRAiyJAJ4l6PtyAborsu6MdTAuYE6d/C7NVACgpS9p 3thcaGMKuXuGg+tirWaPRvo= =QjmG -----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 Feb 11 14:02: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 C9FD93A6CA1; Mon, 11 Feb 2008 14:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6UjMDwECL80; Mon, 11 Feb 2008 14:02:07 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 10B213A6C69; Mon, 11 Feb 2008 14:02:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOgXP-000MeX-NB for namedroppers-data@psg.com; Mon, 11 Feb 2008 21:50:07 +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 1JOgXM-000Me6-RL for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 21:50:06 +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 m1BLlM4i027968; Tue, 12 Feb 2008 08:47:23 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802112147.m1BLlM4i027968@drugs.dv.isc.org> To: Wouter Wijngaards Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Mon, 11 Feb 2008 17:09:14 BST." <47B0732A.3030305@nlnetlabs.nl> Date: Tue, 12 Feb 2008 08:47:22 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Edward Lewis wrote: > | At 14:57 +1100 2/9/08, Mark Andrews wrote: > | > |> Errors. Consistancy. Atomic change. > | > > | But prevention is even better. If the operator tries to add the record > | and gets an error, the mistake is caught in live time, obvious, concrete. > > I think preventing, as in return rcode YXDOMAIN(or another one) when > trying to add a DNAME that obscures/stands over lower domain names is > better. These are no unintended consequences to the operator's actions. > It is a simple concept, and (I believe) implementation as well. YXDOMAIN becomes overloaded. Is it the prerequisite or is it the update section that failed? YXDOMAIN is not an appropriate rcode. 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 Feb 11 15:00: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 EC5D128C309; Mon, 11 Feb 2008 15:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71TF2+Ekdv59; Mon, 11 Feb 2008 15:00:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 27B893A6B4F; Mon, 11 Feb 2008 15:00:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOhXi-0004Ox-Ah for namedroppers-data@psg.com; Mon, 11 Feb 2008 22:54: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 1JOhXf-0004Nr-S9 for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 22:54:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EF61B11434; Mon, 11 Feb 2008 22:54:26 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mark Andrews cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-Reply-To: Your message of "Tue, 12 Feb 2008 08:47:22 +1100." <200802112147.m1BLlM4i027968@drugs.dv.isc.org> References: <200802112147.m1BLlM4i027968@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 11 Feb 2008 22:54:26 +0000 Message-ID: <2149.1202770466@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > I think preventing, as in return rcode YXDOMAIN(or another one) when > > trying to add a DNAME that obscures/stands over lower domain names is > > better. These are no unintended consequences to the operator's actions. > > It is a simple concept, and (I believe) implementation as well. > > YXDOMAIN becomes overloaded. Is it the prerequisite or > is it the update section that failed? YXDOMAIN is not > an appropriate rcode. damn. that's right. the update section succeeds or fails silently -- all zone content related errors have to be the result of failed prerequisites. adding a DNAME to an existing name (one which has children or records) would fail silently under this proposal. so, we'd have to express this as a "name does not exist" assertion, which would only hold true if the prospective DNAME owner has no children and no records. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 15:26: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 C16373A695D; Mon, 11 Feb 2008 15:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoILYVWvzDT0; Mon, 11 Feb 2008 15:26:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9F8373A688F; Mon, 11 Feb 2008 15:26:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOhvV-0007gJ-7G for namedroppers-data@psg.com; Mon, 11 Feb 2008 23:19:05 +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 1JOhvS-0007fd-H6 for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 23:19:03 +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 m1BNGJqR067419; Tue, 12 Feb 2008 10:16:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802112316.m1BNGJqR067419@drugs.dv.isc.org> To: Paul Vixie Cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Mon, 11 Feb 2008 22:54:26 -0000." <2149.1202770466@sa.vix.com> Date: Tue, 12 Feb 2008 10:16:19 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > > I think preventing, as in return rcode YXDOMAIN(or another one) when > > > trying to add a DNAME that obscures/stands over lower domain names is > > > better. These are no unintended consequences to the operator's actions. > > > It is a simple concept, and (I believe) implementation as well. > > > > YXDOMAIN becomes overloaded. Is it the prerequisite or > > is it the update section that failed? YXDOMAIN is not > > an appropriate rcode. > > damn. that's right. the update section succeeds or fails silently -- all > zone content related errors have to be the result of failed prerequisites. > adding a DNAME to an existing name (one which has children or records) would > fail silently under this proposal. > > so, we'd have to express this as a "name does not exist" assertion, which > would only hold true if the prospective DNAME owner has no children and no > records. No. That would change it from "DNAME does not exist" to "DNAME could exist". Also is that before or after the UPDATE section is processed? Delete all at node, add DNAME at node. Do you want to change "NS does not exist" to "NS could exist"? The later would require walking the sub tree looking for non-glue. DNAME has basically the same probles as NS when it comes to adding one to a zone. The same solutions are equally applicable. Consistancy is important. 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 Feb 11 15:52: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 D6A8528C2C2; Mon, 11 Feb 2008 15:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLzdUhsvJCUZ; Mon, 11 Feb 2008 15:52:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 059A63A6D8D; Mon, 11 Feb 2008 15:52:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOiN1-000Acx-EP for namedroppers-data@psg.com; Mon, 11 Feb 2008 23:47:31 +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 1JOiMy-000Ace-V7 for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 23:47:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8804A1142F; Mon, 11 Feb 2008 23:47:23 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mark Andrews cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-Reply-To: Your message of "Tue, 12 Feb 2008 10:16:19 +1100." <200802112316.m1BNGJqR067419@drugs.dv.isc.org> References: <200802112316.m1BNGJqR067419@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 11 Feb 2008 23:47:23 +0000 Message-ID: <4025.1202773643@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > so, we'd have to express this as a "name does not exist" assertion, which > > would only hold true if the prospective DNAME owner has no children and no > > records. > > No. well, you're right, but not for the reason you gave. > That would change it from "DNAME does not exist" to "DNAME could exist". that's not the problem. the problem is that there is no assertion that does what we want. RFC2136 2.4.5 says: 2.4.5 - Name Is Not In Use Name is not in use. No RR of any type is owned by a specified NAME. Note that this prerequisite IS satisfied by empty nonterminals. For this prerequisite, a requestor adds to the section a single RR whose NAME is equal to that of the name whose nonownership of any RRs is required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified as NONE. TYPE must be specified as ANY. TTL must be specified as zero (0). the "is satisfied by empty nonterminals" mystifies me, but it means this is not the same as "DNAME can be added". > Also is that before or after the UPDATE section is processed? in [ibid] we see: 2.4 - Prerequisite Section This section contains a set of RRset prerequisites which must be satisfied at the time the UPDATE packet is received by the primary master server. [...] > Delete all at node, add DNAME at node. that won't do. a DNAME can't be meaningfully added if there are children, so, the empty nonterminal case has to be sorted. > Do you want to change "NS does not exist" to "NS could exist"? The > later would require walking the sub tree looking for non-glue. yes, i want that also. but we're talking about DNAME at the moment. > DNAME has basically the same probles as NS when it comes to adding > one to a zone. The same solutions are equally applicable. > > Consistancy is important. in that case we should fix the NS case also. a new UPDATE prerequisite that said "no records no children" would do it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 16:35: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 E25B728CA41; Mon, 11 Feb 2008 16:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia7W1q6Kov9v; Mon, 11 Feb 2008 16:35:24 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 87F6928CAE4; Mon, 11 Feb 2008 16:35:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOiyE-000G2t-PA for namedroppers-data@psg.com; Tue, 12 Feb 2008 00:25:58 +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 1JOiyB-000G1e-LJ for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 00:25:57 +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 m1C0NChs068162; Tue, 12 Feb 2008 11:23:12 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802120023.m1C0NChs068162@drugs.dv.isc.org> To: Paul Vixie Cc: Wouter Wijngaards , Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt In-reply-to: Your message of "Mon, 11 Feb 2008 23:47:23 -0000." <4025.1202773643@sa.vix.com> Date: Tue, 12 Feb 2008 11:23:12 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > > so, we'd have to express this as a "name does not exist" assertion, which > > > would only hold true if the prospective DNAME owner has no children and no > > > records. > > > > No. > > well, you're right, but not for the reason you gave. > > > That would change it from "DNAME does not exist" to "DNAME could exist". > > that's not the problem. the problem is that there is no assertion that does > what we want. RFC2136 2.4.5 says: > > 2.4.5 - Name Is Not In Use > > Name is not in use. No RR of any type is owned by a specified NAME. > Note that this prerequisite IS satisfied by empty nonterminals. > > For this prerequisite, a requestor adds to the section a single RR > whose NAME is equal to that of the name whose nonownership of any RRs > is required. RDLENGTH is zero and RDATA is therefore empty. CLASS > must be specified as NONE. TYPE must be specified as ANY. TTL must > be specified as zero (0). > > the "is satisfied by empty nonterminals" mystifies me, but it means this > is not the same as "DNAME can be added". > > > Also is that before or after the UPDATE section is processed? > > in [ibid] we see: > > 2.4 - Prerequisite Section > > This section contains a set of RRset prerequisites which must be > satisfied at the time the UPDATE packet is received by the primary > master server. [...] I know when the prerequite have to be tested. All the other UPDATE changes are tested as the UPDATE record is processed. What do we do if the pre-requisite succeeds. A record is added below then a DNAME is added? What do we do if the DNAME is then removed in the same update? > > Delete all at node, add DNAME at node. > > that won't do. a DNAME can't be meaningfully added if there are children, > so, the empty nonterminal case has to be sorted. I got the example wrong. The point is however by the time the DNAME addition is processed the condition have potentially changed. > > Do you want to change "NS does not exist" to "NS could exist"? The > > later would require walking the sub tree looking for non-glue. > > yes, i want that also. but we're talking about DNAME at the moment. > > > DNAME has basically the same probles as NS when it comes to adding > > one to a zone. The same solutions are equally applicable. > > > > Consistancy is important. > > in that case we should fix the NS case also. a new UPDATE prerequisite > that said "no records no children" would do it. You need three tests. No children. DNAME No children but glue. NS No child records at node. NS If you are converting a zone from a copy to a DNAME you want the DNAME to go in first then the records that are obscured to be deleted. This removes the NXDOMAIN race. Note you can't always delete all the obscured records in a single update. There are lots of place where the DNS RFC's assume that large changes can happen atomically *and* in small amounts of time. e.g. Converting a unsigned zone to a signed zone and still being able to processes multiple updates per minute. UPDATE just can't deliver "large and atomic". At some point changes need to be made so that it can. Obscuring/revealing the content on DNAME allows for "large and atomic" in both directions. 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 Feb 11 17:46: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 B209C3A6E07; Mon, 11 Feb 2008 17:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWUoiErR8fhZ; Mon, 11 Feb 2008 17:46:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9D0283A6DFB; Mon, 11 Feb 2008 17:46:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOk3R-000NJ1-KW for namedroppers-data@psg.com; Tue, 12 Feb 2008 01:35: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 1JOk2c-000NDH-Jh for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 01:34:55 +0000 Received: from hlid.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1C1YUkT004569 for ; Mon, 11 Feb 2008 20:34:30 -0500 (EST) (envelope-from namedroppers@hlid.ogud.com) Received: (from namedroppers@localhost) by hlid.ogud.com (8.13.1/8.13.1/Submit) id m1C1YUNI004568 for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 20:34:30 -0500 (EST) (envelope-from namedroppers) 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 1JOYen-000BQc-0b for namedroppers@ops.ietf.org; Mon, 11 Feb 2008 13:25:14 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 6D0F111436; Mon, 11 Feb 2008 13:25:07 +0000 (UTC) To: namedroppers@ops.ietf.org Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation References: <200802102217.m1AMHQM8060394@drugs.dv.isc.org> <48115.1202683717@sa.vix.com> From: Paul Vixie Date: 11 Feb 2008 13:25:07 +0000 In-Reply-To: Message-ID: Lines: 65 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > is it too late to say that appropriate additional data for an AAAA > > response includes A, and that appropriate additional data for an A > > response include AAAA? > > That was our previous mode of operation ('hope') but it did not get very > far on the internet. hope, plus three dollars and a quarter, gets you a starbucks latte. but rough consensus and running code, well, now that's another matter entirely. as server implementors, we could just start including AAAA RRs in the additional data section when answering with A RRs, and including A RRs in the additional data section when answering with AAAA RRs. more or less like what we do with NS and MX. i suggested this, half heartedly, when RFC 1886 was in production, but i was new to the IETF and i didn't know that i had to say it louder if i wanted the idea to be considered. but if a bunch of us just started *doing* it, it would not be a protocol violation nor create interoperability problems, and if it works well, we can always write a BCP about it. here's the one line change it took to get this working in my private label non-BIND recursive nameserver: Index: dns_request.c =================================================================== RCS file: /home/vixie/src/cvsroot/base/robodns/dns_request.c,v retrieving revision 1.72 diff -u -r1.72 dns_request.c --- dns_request.c 21 Jun 2007 14:17:17 -0000 1.72 +++ dns_request.c 11 Feb 2008 13:19:43 -0000 @@ -1143,6 +1143,8 @@ } dns_rrset_lastrdata(&rdi); dns_rrset_lrumark(rrset); + if (adddom != NULL && (type == ns_t_a || type == ns_t_aaaa)) + dns_adddom(adddom, nadddom, nname, class, dc, now); return (ret); } and here's what it looks like on the wire: ; <<>> DiG 9.4.1 <<>> @::1 www.isc.org in aaaa ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24902 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.isc.org. IN AAAA ;; ANSWER SECTION: www.isc.org. 600 IN AAAA 2001:4f8:0:2::d ;; ADDITIONAL SECTION: www.isc.org. 594 IN A 204.152.184.88 ;; Query time: 185 msec ;; SERVER: ::1#53(::1) ;; WHEN: Mon Feb 11 13:18:30 2008 ;; MSG SIZE rcvd: 73 "so, tonight's the night, i'm breaking outta this joint, who's with me?" -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 Feb 12 04:19: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 438CD3A6CF8; Tue, 12 Feb 2008 04:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3EFnlOw-ZXb; Tue, 12 Feb 2008 04:19:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 884823A6A7C; Tue, 12 Feb 2008 04:19:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOtuH-000LkG-84 for namedroppers-data@psg.com; Tue, 12 Feb 2008 12:06:37 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOttv-000Lil-3n for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 12:06:16 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm447b1f189; Tue, 12 Feb 2008 20:19:59 +0800 Received: from core3.amsl.com([64.170.98.86]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1d47ad15ed; Sat, 09 Feb 2008 02:16:43 +0800 Received: from core3.amsl.com([64.170.98.86]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 09 Feb 2008 02:16:43 +0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0F228C3FD; Fri, 8 Feb 2008 10:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46-G7+B2vXw0; Fri, 8 Feb 2008 10:00:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95AB128C3A1; Fri, 8 Feb 2008 10:00:03 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 54A663A79D3; Fri, 8 Feb 2008 10:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-07.txt Message-Id: <20080208180001.54A663A79D3@core3.amsl.com> Date: Fri, 8 Feb 2008 10:00:01 -0800 (PST) Cc: namedroppers@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : DNS Zone Transfer Protocol (AXFR) Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-07.txt Pages : 0 Date : 2008-2-5 The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996. The base definition of these facilities, that of the AXFR, has proven insufficient in detail, resulting in no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-axfr-clarify-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-8095634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-8095634.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --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 Feb 12 04:46: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 6AE0928C1D9; Tue, 12 Feb 2008 04:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVwmmB-8GNuo; Tue, 12 Feb 2008 04:46:21 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 96DCF28C20B; Tue, 12 Feb 2008 04:46:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOuQg-000Ohu-LK for namedroppers-data@psg.com; Tue, 12 Feb 2008 12:40:06 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOuQY-000OgG-JY for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 12:40:04 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm12847b20004; Tue, 12 Feb 2008 20:53:42 +0800 Received: from core3.amsl.com([64.170.98.86]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm947ad1e0f; Sat, 09 Feb 2008 02:47:56 +0800 Received: from core3.amsl.com([64.170.98.86]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 09 Feb 2008 02:47:56 +0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FFA3A7C72; Thu, 7 Feb 2008 14:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rOdesnj-As6; Thu, 7 Feb 2008 14:37:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559A33A7BA5; Thu, 7 Feb 2008 14:37:04 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2EA353A79EC; Thu, 7 Feb 2008 14:37:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-09.txt Message-Id: <20080207223702.2EA353A79EC@core3.amsl.com> Date: Thu, 7 Feb 2008 14:37:02 -0800 (PST) Cc: namedroppers@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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-09.txt Pages : 16 Date : 2008-2-7 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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2672bis-dname-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-7143512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-7143512.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --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 Feb 12 05:58: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 5C9CD28C26E; Tue, 12 Feb 2008 05:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjb4btyJy2pd; Tue, 12 Feb 2008 05:58:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 843B728C1D4; Tue, 12 Feb 2008 05:58:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOvT7-0006qo-NZ for namedroppers-data@psg.com; Tue, 12 Feb 2008 13:46:41 +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 1JOvT4-0006qA-Az for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 13:46:40 +0000 Received: from [192.168.1.14] (pool-96-241-61-40.washdc.fios.verizon.net [96.241.61.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id 3C7381367AD; Tue, 12 Feb 2008 08:46:37 -0500 (EST) Cc: namedroppers@ops.ietf.org Message-Id: <5B5D910D-6FDA-4C4D-97C1-5FD020BF7EF1@verisign.com> From: "Blacka, David" To: Paul Vixie In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-2--968985893; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation Date: Tue, 12 Feb 2008 08:46:37 -0500 References: <200802102217.m1AMHQM8060394@drugs.dv.isc.org> <48115.1202683717@sa.vix.com> X-Mailer: Apple Mail (2.915) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Apple-Mail-2--968985893 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Feb 11, 2008, at 8:25 AM, Paul Vixie wrote: >>> is it too late to say that appropriate additional data for an AAAA >>> response includes A, and that appropriate additional data for an A >>> response include AAAA? >> >> That was our previous mode of operation ('hope') but it did not get >> very >> far on the internet. > > hope, plus three dollars and a quarter, gets you a starbucks latte. > but > rough consensus and running code, well, now that's another matter > entirely. > > as server implementors, we could just start including AAAA RRs in the > additional data section when answering with A RRs, and including A > RRs in > the additional data section when answering with AAAA RRs. more or > less > like what we do with NS and MX. i suggested this, half heartedly, > when RFC > 1886 was in production, but i was new to the IETF and i didn't know > that i > had to say it louder if i wanted the idea to be considered. but if > a bunch > of us just started *doing* it, it would not be a protocol violation > nor > create interoperability problems, and if it works well, we can > always write > a BCP about it. So, what use is this extra additional section rrset? Wouldn't RFC 2181 rules (and general resolver paranoia) keep this A or AAAA from ever being used as an answer? -- David Blacka Sr. Engineer VeriSign Infrastructure Product Engineering --Apple-Mail-2--968985893 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMTIxMzQ2MzdaMCMGCSqGSIb3DQEJBDEWBBSntyYHFmFh 1MTY+xpxh6H6m1d2DTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJt cyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJp U2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhArFBLSmLR/hjp8A/U61Mv9MA0GCSqGSIb3DQEBAQUA BIGAyUSK9Krl/wwNlBjZOo/NdAjfNhuaeYvrWCfy8xVkvoslkrBa7bCeRGPsGi5taZunyoaXOQoK CrQWSH+xqXXzgfoZQ7Ody2pNThU/GI0YwzajusoDdUyw0gUkBgJUWM/SatSG+R41K8DnlwK+mhEi XsakZg58dhGgpdOorUd7e5oAAAAAAAA= --Apple-Mail-2--968985893-- -- to unsubscribe send a message to namedroppers-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 Feb 12 08:23: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 84A373A6E4E; Tue, 12 Feb 2008 08:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onSEGLFOYYvh; Tue, 12 Feb 2008 08:23:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B0D9B28C313; Tue, 12 Feb 2008 08:23:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxnV-000OBW-IQ for namedroppers-data@psg.com; Tue, 12 Feb 2008 16:15: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 1JOxnS-000OBA-I1 for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 16:15:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F11FF11434 for ; Tue, 12 Feb 2008 16:15:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation In-Reply-To: Your message of "Tue, 12 Feb 2008 08:46:37 EST." <5B5D910D-6FDA-4C4D-97C1-5FD020BF7EF1@verisign.com> References: <200802102217.m1AMHQM8060394@drugs.dv.isc.org> <48115.1202683717@sa.vix.com> <5B5D910D-6FDA-4C4D-97C1-5FD020BF7EF1@verisign.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Feb 2008 16:15:44 +0000 Message-ID: <42982.1202832944@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion [davidb] > So, what use is this extra additional section rrset? Wouldn't RFC 2181 > rules (and general resolver paranoia) keep this A or AAAA from ever being > used as an answer? in my own implementation, i upgrade additional records if they come from the same server i would have queried for them. i assume that others do likewise, and that RFC 2181 is overly conservative on this one point. however, their availability to stub resolvers (to which RFC 2181 does not apply) is the important part. getaddrinfo() with ai_family == PF_UNSPEC, for example. also, their availability in a recursive server (at the "additional data" credibility level) for other responses (MX, NS, SRV) would moot the question, if i have one kind of cached address record for the target, but no evidence for/against the existence of the other kind of record, should i query for the other kind so that my additional data can be more complete? and it would moot the question, if you're trying to reach a name server and you have one kind of address record for it but no evidence for or against the existence of the other kind of record, and you can't reach it using the kind of address you have, should you query for the kind you don't have before giving up? so even without patching RFC 2181 or testing getaddrinfo(), i see two immediate benefits from this change in behaviour, which as i said violates no specification of which i am aware. -- to unsubscribe send a message to namedroppers-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 Feb 12 08:33: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 CA9AB28C998; Tue, 12 Feb 2008 08:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.483 X-Spam-Level: X-Spam-Status: No, score=-5.483 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkuUabKRA2Jg; Tue, 12 Feb 2008 08:33:37 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id ADD5B3A6E65; Tue, 12 Feb 2008 08:33:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxzG-000PRd-0O for namedroppers-data@psg.com; Tue, 12 Feb 2008 16:28: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 1JOxz0-000PPf-MT for namedroppers@ops.ietf.org; Tue, 12 Feb 2008 16:28:00 +0000 Received: from [0.0.0.0] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1CGRY3e010096 for ; Tue, 12 Feb 2008 11:27:35 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 12 Feb 2008 11:20:55 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Fwd: I-D ACTION:draft-lewis-axfr-over-udp-00.txt 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 The title was chopped up in the announcement, but here it is. DNS Zone Transfer Protocol (AXFR) over the User Datagram Protocol (UDP) >X-Original-To: i-d-announce@ietf.org >Delivered-To: i-d-announce@core3.amsl.com >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-lewis-axfr-over-udp-00.txt >Date: Mon, 11 Feb 2008 16:45:01 -0800 (PST) >X-BeenThere: i-d-announce@ietf.org >Reply-To: internet-drafts@ietf.org >List-Id: >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : NS Zone Transfer Protocol (AXFR)over the >User Datagram Protocol (UDP) > Author(s) : E. Lewis > Filename : draft-lewis-axfr-over-udp-00.txt > Pages : 5 > Date : 2008-2-8 > >The Domain Name System's Authoritative Transfer (AXFR) use of the >User Datagram Protocol (UDP) as a transport protocol is defined. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-lewis-axfr-over-udp-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then >"get draft-lewis-axfr-over-udp-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-lewis-axfr-over-udp-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >http://www.ietf.org/mailman/listinfo/i-d-announce > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Feb 13 07:43: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 D863F3A6F74; Wed, 13 Feb 2008 07:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8cSGjR2ky+l; Wed, 13 Feb 2008 07:43:40 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0BA9F3A6F93; Wed, 13 Feb 2008 07:43:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPJac-000H71-VZ for namedroppers-data@psg.com; Wed, 13 Feb 2008 15:32:02 +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 1JPJaZ-000H6I-Mk for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 15:32:01 +0000 Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m1DFVrGR027452 for ; Wed, 13 Feb 2008 10:31:55 -0500 Received: from 619893L ([129.6.220.160]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m1DFVerW011682 for ; Wed, 13 Feb 2008 10:31:43 -0500 From: "Scott Rose" To: Subject: Resolution of the DNAME via dynamic update issue Date: Wed, 13 Feb 2008 10:31:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Resolution of DNAME in dynamic update issue Issue: What should happen when attempting to add a DNAME RR via dynamic update? Possible resolution 1: Return error code. Either overload YXDOMAIN or allocate a new error code for this case (or this and NS case): OBSURENAME error (or something else): meaning that if the RR is added; it will cause one or more other RRs at that name or below that name to become obscured. From Paul Vixies original comment: http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00046.html http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00283.html Then expanded after discussion that YXDOMAIN is not the correct error code on Monday Feb 11: http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00321.html Possible resolution 2: Accept and obscure names. From Mark Andrews post: http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00247.html Allow dynamic updates of DNAME to obscure names below the added name. Those obscured names are transferred in AXFR/IXFR operations but are not used in the resolution process. A dynamic update message adding a DNAME RR at a name that already has RR’s of some other type would still generate an error (must be delete/add operation). In addition, zone files with names below a DNAME still load successfully but a server MAY wish to log an error to log files to alert administrators. Please indicate which you prefer (or give an alternate). -- to unsubscribe send a message to namedroppers-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 Feb 13 09:16: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 5005928C945; Wed, 13 Feb 2008 09:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRso7T+LWbTC; Wed, 13 Feb 2008 09:15:58 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BC81028C87A; Wed, 13 Feb 2008 09:14:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPL07-0006Ql-3m for namedroppers-data@psg.com; Wed, 13 Feb 2008 17:02: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 1JPL01-0006QJ-JF for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 17:02:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E59D211433; Wed, 13 Feb 2008 17:02:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Scott Rose" cc: namedroppers@ops.ietf.org Subject: Re: Resolution of the DNAME via dynamic update issue In-Reply-To: Your message of "Wed, 13 Feb 2008 10:31:40 EST." References: X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 13 Feb 2008 17:02:20 +0000 Message-ID: <5279.1202922140@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Resolution of DNAME in dynamic update issue > > Issue: What should happen when attempting to add a DNAME RR via dynamic > update? > > Possible resolution 1: Return error code. Either overload YXDOMAIN or ... marka pointed out to me that YXDOMAIN is a response to a prerequisite not an update action, and we have no way to express "name must have no children and no records" in the current prerequisite encodings. thus, this idea will not work unless we add another prerequisite encoding, which i think is the wrong approach. > Possible resolution 2: Accept and obscure names. ... > > Please indicate which you prefer (or give an alternate). of the two possible resolutions given, i prefer #2. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 11:15: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 39F593A6F91; Wed, 13 Feb 2008 11:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[AWL=1.842, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsp8fEZF6Krh; Wed, 13 Feb 2008 11:15:51 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id CC8703A6EEE; Wed, 13 Feb 2008 11:15:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPMuq-000KzT-GI for namedroppers-data@psg.com; Wed, 13 Feb 2008 19:05:08 +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 1JPMuj-000KyL-J5 for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 19:05:07 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1DJ4qk9001990; Wed, 13 Feb 2008 14:04:52 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200802131904.m1DJ4qk9001990@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Feb 2008 14:04:44 -0500 To: Scott Rose , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Resolution of the DNAME via dynamic update issue In-Reply-To: References: Mime-Version: 1.0 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 10:31 13/02/2008, Scott Rose wrote: >Resolution of DNAME in dynamic update issue > >Issue: What should happen when attempting to add a DNAME RR via dynamic >update? > >Possible resolution 1: Return error code. Either overload YXDOMAIN or >allocate a new error code for this case (or this and NS case): OBSURENAME >error (or something else): meaning that if the RR is added; it will cause >one or more other RRs at that name or below that name to become obscured. > > >From Paul Vixies original comment: >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00046.html > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00283.html > >Then expanded after discussion that YXDOMAIN is not the correct error code >on Monday Feb 11: > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00321.html > > >Possible resolution 2: Accept and obscure names. From Mark Andrews post: >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00247.html > >Allow dynamic updates of DNAME to obscure names below the added name. Those >obscured names are transferred in AXFR/IXFR operations but are not used in >the resolution process. A dynamic update message adding a DNAME RR at a >name that already has RR's of some other type would still generate an error >(must be delete/add operation). > >In addition, zone files with names below a DNAME still load successfully but >a server MAY wish to log an error to log files to alert administrators. > >Please indicate which you prefer (or give an alternate). For completeness Possible resolution 3: Accept and delete zone contents below the DNAME/NS added This one has been mentioned. Side effect of #2 can name/RRset below DNAME be deleted ? can name/RRset below DNAME be modified ? can name/RRset below DNAME be added ? Special case of #2 zone example.com. SOA ..... NS foo.example.com. NS bar.some-other-zone.tld. foo A a.b.c.d Attempting to add "example.com. DNAME example.org." This obscures foo.example.com. Should this update be allowed or rejected as foo.example.com will never be visible ? Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 11:52:31 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 8B3263A6873; Wed, 13 Feb 2008 11:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E3KMdbl0SZy; Wed, 13 Feb 2008 11:52:30 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BA19F3A6814; Wed, 13 Feb 2008 11:52:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPNVT-000OtQ-7k for namedroppers-data@psg.com; Wed, 13 Feb 2008 19:42:59 +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 1JPNVM-000Osd-RG for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 19:42:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7962C1142F; Wed, 13 Feb 2008 19:42:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: Resolution of the DNAME via dynamic update issue In-Reply-To: Your message of "Wed, 13 Feb 2008 14:04:44 EST." <200802131904.m1DJ4qk9001990@ogud.com> References: <200802131904.m1DJ4qk9001990@ogud.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 13 Feb 2008 19:42:52 +0000 Message-ID: <14016.1202931772@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > For completeness > Possible resolution 3: Accept and delete zone contents below the DNAME/NS > added > > This one has been mentioned. i think #3 is a really and terribly bad idea. > Side effect of #2 > can name/RRset below DNAME be deleted ? > > can name/RRset below DNAME be modified ? > > can name/RRset below DNAME be added ? yes. > Special case of #2 > zone example.com. > SOA ..... > NS foo.example.com. > NS bar.some-other-zone.tld. > foo A a.b.c.d > > Attempting to add "example.com. DNAME example.org." > This obscures foo.example.com. > Should this update be allowed or rejected as foo.example.com will > never be visible ? i think this level of semantic control is unrealistic. it begs questions about DNAMEs to parents, DNAME loops, CNAME loops, and similar. proposal #2 says UPDATE shouldn't enforce these limitations. -- to unsubscribe send a message to namedroppers-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 Feb 13 12:18: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 1EACA3A67A7; Wed, 13 Feb 2008 12:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtrvDSCEcD4O; Wed, 13 Feb 2008 12:18:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1F8E13A68DF; Wed, 13 Feb 2008 12:18:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPNxb-00020d-D2 for namedroppers-data@psg.com; Wed, 13 Feb 2008 20:12:03 +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 1JPNxY-00020A-OQ for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 20:12:02 +0000 Received: from [192.168.1.107] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1DKBkoi002529; Wed, 13 Feb 2008 15:11:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802131904.m1DJ4qk9001990@ogud.com> References: <200802131904.m1DJ4qk9001990@ogud.com> Date: Wed, 13 Feb 2008 15:10:16 -0500 To: Olafur Gudmundsson From: Edward Lewis Subject: Re: Resolution of the DNAME via dynamic update issue Cc: Scott Rose , namedroppers@ops.ietf.org 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 The reason I prefer #1 is that #2 and #3 have a shared feature of "unintended consequences." Okay, let's now drop #3 from consideration. The problem with #2 is that it means possibly many names are impacted as a side effect without notice. The very error that is easily recoverd from (being able to undo the obscuring) is the error enabled by #2. (It only saves itself from itself.) I'd prefer to allocate a new error code. Yes, this means more work for the implementations, but protocols are supposed to be all about communications, the clearer the better optimized for performance. (Oh, and I'm against overloading the YXDOMAIN because that wouldn't be clear.) I favored obscuring until I realized that it was an unintended consequence. I do have a question for the group. When we say NS records obscure names below them in the same zone, where is that planted in the specs? Was it something that was coded and we just stuck with it? At 14:04 -0500 2/13/08, Olafur Gudmundsson wrote: >At 10:31 13/02/2008, Scott Rose wrote: >>Resolution of DNAME in dynamic update issue >> >>Issue: What should happen when attempting to add a DNAME RR via dynamic >>update? >> >>Possible resolution 1: Return error code. Either overload YXDOMAIN or >>allocate a new error code for this case (or this and NS case): OBSURENAME >>error (or something else): meaning that if the RR is added; it will cause >>one or more other RRs at that name or below that name to become obscured. >> >> >From Paul Vixies original comment: >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00046.html >> >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00283.html >> >>Then expanded after discussion that YXDOMAIN is not the correct error code >>on Monday Feb 11: >> >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00321.html >> >> >>Possible resolution 2: Accept and obscure names. From Mark Andrews post: >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00247.html >> >>Allow dynamic updates of DNAME to obscure names below the added name. Those >>obscured names are transferred in AXFR/IXFR operations but are not used in >>the resolution process. A dynamic update message adding a DNAME RR at a >>name that already has RR's of some other type would still generate an error >>(must be delete/add operation). >> >>In addition, zone files with names below a DNAME still load successfully but >>a server MAY wish to log an error to log files to alert administrators. >> >>Please indicate which you prefer (or give an alternate). > > > >For completeness >Possible resolution 3: Accept and delete zone contents below the >DNAME/NS added > >This one has been mentioned. > > >Side effect of #2 > can name/RRset below DNAME be deleted ? > > can name/RRset below DNAME be modified ? > > can name/RRset below DNAME be added ? > > >Special case of #2 >zone example.com. > SOA ..... > NS foo.example.com. > NS bar.some-other-zone.tld. >foo A a.b.c.d > >Attempting to add "example.com. DNAME example.org." >This obscures foo.example.com. >Should this update be allowed or rejected as foo.example.com will >never be visible ? > > 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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Feb 13 13:02: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 BF23E3A6FC4; Wed, 13 Feb 2008 13:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYui5iLk9sRs; Wed, 13 Feb 2008 13:02:32 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DF6C33A67CF; Wed, 13 Feb 2008 13:02:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPOdU-0006js-6A for namedroppers-data@psg.com; Wed, 13 Feb 2008 20:55:20 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPOdJ-0006hv-23 for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 20:55:11 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id 48CD17C8D4; Wed, 13 Feb 2008 20:52:54 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 1BFF075F3B; Wed, 13 Feb 2008 22:55:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18355.22827.31633.105664@guava.gson.org> Date: Wed, 13 Feb 2008 22:55:07 +0200 To: "Scott Rose" Cc: Subject: Re: Resolution of the DNAME via dynamic update issue In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Scott Rose wrote: > Resolution of DNAME in dynamic update issue >=20 > Issue: What should happen when attempting to add a DNAME RR via dyna= mic > update=3F I prefer resolution 2, "Accept and obscure names", as it is consistent with the existing dynamic update behavior with regards to NS records (RFC2136 section 7.18). And to be fully consistent, perhaps we should use the same terminology as that section and say "occlude" rather than "obscure". > A dynamic update message adding a DNAME RR at a > name that already has RR=92s of some other type would still generate = an error > (must be delete/add operation). This error case is analogous to the existing error case of adding a CNAME to a name having other data, and for consistency, it should be dealt with in the same way, by ignoring the update RR. --=20 Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 13:35: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 6C7873A6AE9; Wed, 13 Feb 2008 13:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65GL76kgXn9U; Wed, 13 Feb 2008 13:35:41 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 586D03A67D0; Wed, 13 Feb 2008 13:35:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPP5h-000A8S-Co for namedroppers-data@psg.com; Wed, 13 Feb 2008 21:24:29 +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 1JPP5d-000A81-PH for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 21:24: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 m1DLOCfC086890; Thu, 14 Feb 2008 08:24:13 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802132124.m1DLOCfC086890@drugs.dv.isc.org> To: Edward Lewis Cc: Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Wed, 13 Feb 2008 15:10:16 CDT." Date: Thu, 14 Feb 2008 08:24:12 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > The reason I prefer #1 is that #2 and #3 have a shared feature of > "unintended consequences." > > Okay, let's now drop #3 from consideration. > > The problem with #2 is that it means possibly many names are impacted > as a side effect without notice. The very error that is easily > recoverd from (being able to undo the obscuring) is the error enabled > by #2. (It only saves itself from itself.) > > I'd prefer to allocate a new error code. Yes, this means more work > for the implementations, but protocols are supposed to be all about > communications, the clearer the better optimized for performance. > (Oh, and I'm against overloading the YXDOMAIN because that wouldn't > be clear.) > > I favored obscuring until I realized that it was an unintended consequence. Any change can have unintend consecquences. Your wanting to make the zone contents disappear before the update has unintended consequnences. There *will* be a window where names that used to exist won't and then will exist once the DNAME is added. There will also be a window between when a DNAME is removed and the namespace restored. NXDOMAIN is a fatal error for mail, etc. > I do have a question for the group. When we say NS records obscure > names below them in the same zone, where is that planted in the > specs? Was it something that was coded and we just stuck with it? > > At 14:04 -0500 2/13/08, Olafur Gudmundsson wrote: > >At 10:31 13/02/2008, Scott Rose wrote: > >>Resolution of DNAME in dynamic update issue > >> > >>Issue: What should happen when attempting to add a DNAME RR via dynamic > >>update? > >> > >>Possible resolution 1: Return error code. Either overload YXDOMAIN or > >>allocate a new error code for this case (or this and NS case): OBSURENAME > >>error (or something else): meaning that if the RR is added; it will cause > >>one or more other RRs at that name or below that name to become obscured. > >> > >> >From Paul Vixies original comment: > >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00046.html > >> > >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00283.html > >> > >>Then expanded after discussion that YXDOMAIN is not the correct error code > >>on Monday Feb 11: > >> > >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00321.html > >> > >> > >>Possible resolution 2: Accept and obscure names. From Mark Andrews post: > >>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00247.html > >> > >>Allow dynamic updates of DNAME to obscure names below the added name. Those > >>obscured names are transferred in AXFR/IXFR operations but are not used in > >>the resolution process. A dynamic update message adding a DNAME RR at a > >>name that already has RR's of some other type would still generate an error > >>(must be delete/add operation). > >> > >>In addition, zone files with names below a DNAME still load successfully but > >>a server MAY wish to log an error to log files to alert administrators. > >> > >>Please indicate which you prefer (or give an alternate). > > > > > > > >For completeness > >Possible resolution 3: Accept and delete zone contents below the > >DNAME/NS added > > > >This one has been mentioned. > > > > > >Side effect of #2 > > can name/RRset below DNAME be deleted ? > > > > can name/RRset below DNAME be modified ? > > > > can name/RRset below DNAME be added ? > > > > > >Special case of #2 > >zone example.com. > > SOA ..... > > NS foo.example.com. > > NS bar.some-other-zone.tld. > >foo A a.b.c.d > > > >Attempting to add "example.com. DNAME example.org." > >This obscures foo.example.com. > >Should this update be allowed or rejected as foo.example.com will > >never be visible ? > > > > 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: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: -- 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 Feb 13 13:59: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 79A643A67B1; Wed, 13 Feb 2008 13:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNrg0Osn6bqe; Wed, 13 Feb 2008 13:59:26 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C1A693A6811; Wed, 13 Feb 2008 13:58:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPPUO-000D4E-6s for namedroppers-data@psg.com; Wed, 13 Feb 2008 21:50:00 +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 1JPPUL-000D3d-Ac for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 21:49:58 +0000 Received: from [192.168.1.107] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1DLnhuD003272; Wed, 13 Feb 2008 16:49:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802132124.m1DLOCfC086890@drugs.dv.isc.org> References: <200802132124.m1DLOCfC086890@drugs.dv.isc.org> Date: Wed, 13 Feb 2008 16:43:07 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: Resolution of the DNAME via dynamic update issue Cc: Edward Lewis , Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org 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 8:24 +1100 2/14/08, Mark Andrews wrote: > Any change can have unintend consecquences. Your wanting > to make the zone contents disappear before the update has > unintended consequnences. There *will* be a window where > names that used to exist won't and then will exist once the > DNAME is added. What I meant by unintended consequences is that when occluding the names, the status of names are changing without an explicitly communication. If the introduction of a DNAME is prevented because there are names in place and must be explicitly removed first, then all the changes are explicitly communicated. > There will also be a window between when a DNAME is removed > and the namespace restored. How common is the use case of a DNAME being introduced and then withdrawn on top of an otherwise stable tree structure? I don't see what this is "solving for." > NXDOMAIN is a fatal error for mail, etc. I don't understand why this is mentioned. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Feb 13 14:42: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 9B65C3A6E6D; Wed, 13 Feb 2008 14:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9qnPxgBZM2V; Wed, 13 Feb 2008 14:42:09 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 586993A67B1; Wed, 13 Feb 2008 14:42:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQC2-000Hnv-8K for namedroppers-data@psg.com; Wed, 13 Feb 2008 22:35:06 +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 1JPQBz-000Hn5-EP for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 22:35:04 +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 m1DMYrHl015123; Thu, 14 Feb 2008 09:34:53 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802132234.m1DMYrHl015123@drugs.dv.isc.org> To: Olafur Gudmundsson Cc: Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Wed, 13 Feb 2008 14:04:44 CDT." <200802131904.m1DJ4qk9001990@ogud.com> Date: Thu, 14 Feb 2008 09:34:53 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 10:31 13/02/2008, Scott Rose wrote: > >Resolution of DNAME in dynamic update issue > > > >Issue: What should happen when attempting to add a DNAME RR via dynamic > >update? > > > >Possible resolution 1: Return error code. Either overload YXDOMAIN or > >allocate a new error code for this case (or this and NS case): OBSURENAME > >error (or something else): meaning that if the RR is added; it will cause > >one or more other RRs at that name or below that name to become obscured. > > > > >From Paul Vixies original comment: > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00046.html > > > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00283.html > > > >Then expanded after discussion that YXDOMAIN is not the correct error code > >on Monday Feb 11: > > > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00321.html > > > > > >Possible resolution 2: Accept and obscure names. From Mark Andrews post: > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00247.html > > > >Allow dynamic updates of DNAME to obscure names below the added name. Those > >obscured names are transferred in AXFR/IXFR operations but are not used in > >the resolution process. A dynamic update message adding a DNAME RR at a > >name that already has RR's of some other type would still generate an error > >(must be delete/add operation). > > > >In addition, zone files with names below a DNAME still load successfully but > >a server MAY wish to log an error to log files to alert administrators. > > > >Please indicate which you prefer (or give an alternate). > > > > For completeness > Possible resolution 3: Accept and delete zone contents below the DNAME/NS add > ed > > This one has been mentioned. > > > Side effect of #2 > can name/RRset below DNAME be deleted ? yes. can update delete a name/RRset below a delegating NS? yes. > can name/RRset below DNAME be modified ? yes. can update modify a name/RRset below a delegating NS? yes. > can name/RRset below DNAME be added ? yes. can update add a name/RRset below a delegating NS? yes. > Special case of #2 > zone example.com. > SOA ..... > NS foo.example.com. > NS bar.some-other-zone.tld. > foo A a.b.c.d > > Attempting to add "example.com. DNAME example.org." > This obscures foo.example.com. > Should this update be allowed or rejected as foo.example.com will > never be visible ? allowed and will be visible if DNAME is removed. > 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: -- 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 Feb 13 14:56: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 C7B5B3A67D9; Wed, 13 Feb 2008 14:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFgB3takZoHc; Wed, 13 Feb 2008 14:56:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E6E793A67D5; Wed, 13 Feb 2008 14:56:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQRz-000JSf-Pf for namedroppers-data@psg.com; Wed, 13 Feb 2008 22:51:35 +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 1JPQRw-000JSB-SH for namedroppers@ops.ietf.org; Wed, 13 Feb 2008 22:51:34 +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 m1DMpL8I025854; Thu, 14 Feb 2008 09:51:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802132251.m1DMpL8I025854@drugs.dv.isc.org> To: Edward Lewis Cc: Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Wed, 13 Feb 2008 16:43:07 CDT." Date: Thu, 14 Feb 2008 09:51:21 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 8:24 +1100 2/14/08, Mark Andrews wrote: > > > Any change can have unintend consecquences. Your wanting > > to make the zone contents disappear before the update has > > unintended consequnences. There *will* be a window where > > names that used to exist won't and then will exist once the > > DNAME is added. > > What I meant by unintended consequences is that when occluding the > names, the status of names are changing without an explicitly > communication. If the introduction of a DNAME is prevented because > there are names in place and must be explicitly removed first, then > all the changes are explicitly communicated. > > > There will also be a window between when a DNAME is removed > > and the namespace restored. > > How common is the use case of a DNAME being introduced and then > withdrawn on top of an otherwise stable tree structure? I don't see > what this is "solving for." > > > NXDOMAIN is a fatal error for mail, etc. > > I don't understand why this is mentioned. Because the only other choice is to make names DISAPPEAR then REAPPEAR as you DESTROY/REBUILD the namespace below the DNAME. zone with lots of content beneath new DNAME location | *** LOTS OF NXDOMAINS *** DESTROY V zone with not content beneath new DNAME location | *** LOTS OF NXDOMAINS *** V zone with DNAME or zone with DNAME | V zone with not content beneath old DNAME location | *** LOTS OF NXDOMAINS *** REBUILD V zone with lots of content beneath old DNAME location Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. -- 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 Feb 13 18:41: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 A451F3A6FAC; Wed, 13 Feb 2008 18:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.837 X-Spam-Level: X-Spam-Status: No, score=-4.837 tagged_above=-999 required=5 tests=[AWL=1.462, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06a7FrqzqU1E; Wed, 13 Feb 2008 18:41:37 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B43A23A681C; Wed, 13 Feb 2008 18:41:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPTuv-000Gy4-PC for namedroppers-data@psg.com; Thu, 14 Feb 2008 02:33:41 +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 1JPTut-000Gxp-Dc for namedroppers@ops.ietf.org; Thu, 14 Feb 2008 02:33:40 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1E2XZGY005174 for ; Wed, 13 Feb 2008 21:33:36 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200802140233.m1E2XZGY005174@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Feb 2008 21:33:15 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: Meeting at IETF-71 ? In-Reply-To: <200802071403.m17E3i5N091823@ogud.com> References: <200802071403.m17E3i5N091823@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At 11:12 07/02/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote: >We have a few new active drafts right now, >do you see a need for a face to face meeting? >I will decide by Monday if DNSEXT is meeting. > > Olafur Only two people told me there is need for a meeting. Given the long discussions on AXFR and DNAME over the last few days, I think there is some need to discussion forum. I will update DNSEXT meeting request to be for a one hour slot. There will be separate small meeting to flesh out the profile document. If you are interested and willing to help out with that document contact me or George. Send in agenda requests Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 19:11: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 C950F28C7DD; Wed, 13 Feb 2008 19:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrNErj8u1LM4; Wed, 13 Feb 2008 19:11:43 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6576628C7AB; Wed, 13 Feb 2008 19:11:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPUO4-000JeB-CP for namedroppers-data@psg.com; Thu, 14 Feb 2008 03:03: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 1JPUO1-000Jdt-VQ for namedroppers@ops.ietf.org; Thu, 14 Feb 2008 03:03:47 +0000 Received: from [192.168.1.107] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1E33WZF005506; Wed, 13 Feb 2008 22:03:33 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200802132251.m1DMpL8I025854@drugs.dv.isc.org> References: <200802132251.m1DMpL8I025854@drugs.dv.isc.org> Date: Wed, 13 Feb 2008 22:01:46 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: Resolution of the DNAME via dynamic update issue Cc: Edward Lewis , Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org 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 9:51 +1100 2/14/08, Mark Andrews wrote: >>> NXDOMAIN is a fatal error for mail, etc. >> >> I don't understand why this is mentioned. > > Because the only other choice is to make names DISAPPEAR > then REAPPEAR as you DESTROY/REBUILD the namespace below > the DNAME. > > zone with lots of content beneath new DNAME location > | > *** LOTS OF NXDOMAINS *** > DESTROY > V > zone with not content beneath new DNAME location > | > *** LOTS OF NXDOMAINS *** > V > zone with DNAME > > or > > zone with DNAME > | > V > zone with not content beneath old DNAME location > | > *** LOTS OF NXDOMAINS *** > REBUILD > V > zone with lots of content beneath old DNAME location Still not getting the point. How often is this a concern? How often would a zone be run this way? I understand the scenario, the question is, when in operations would this be a concern? And what does that have to do with mail? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Feb 13 19:21: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 0D6323A6FDF; Wed, 13 Feb 2008 19:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2mi8rBGBr3T; Wed, 13 Feb 2008 19:21:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5B9E93A6FBA; Wed, 13 Feb 2008 19:21:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPUZ7-000KV1-5k for namedroppers-data@psg.com; Thu, 14 Feb 2008 03:15:13 +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 1JPUYw-000KTG-CX for namedroppers@ops.ietf.org; Thu, 14 Feb 2008 03:15:03 +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 m1E3EnG0084445; Thu, 14 Feb 2008 14:14:49 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802140314.m1E3EnG0084445@drugs.dv.isc.org> To: Edward Lewis Cc: Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Wed, 13 Feb 2008 22:01:46 CDT." Date: Thu, 14 Feb 2008 14:14:49 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 9:51 +1100 2/14/08, Mark Andrews wrote: > > >>> NXDOMAIN is a fatal error for mail, etc. > >> > >> I don't understand why this is mentioned. > > > > Because the only other choice is to make names DISAPPEAR > > then REAPPEAR as you DESTROY/REBUILD the namespace below > > the DNAME. > > > > zone with lots of content beneath new DNAME location > > | > > *** LOTS OF NXDOMAINS *** > > DESTROY > > V > > zone with not content beneath new DNAME location > > | > > *** LOTS OF NXDOMAINS *** > > V > > zone with DNAME > > > > or > > > > zone with DNAME > > | > > V > > zone with not content beneath old DNAME location > > | > > *** LOTS OF NXDOMAINS *** > > REBUILD > > V > > zone with lots of content beneath old DNAME location > > Still not getting the point. How often is this a concern? How often > would a zone be run this way? I understand the scenario, the > question is, when in operations would this be a concern? Does it really matter how often? All we need to realise as engineers is that it happens with zone which are being managed via dynamic update. Such changes should happen with having to shut the server down, manually edit the zone and then reload it. Often the people that are managing the zone don't have access to do this. Pick any of the dynamic dns service providers for examples of where manual changes are not available. You can create the zone, delete the zone and the rest is done via update. > And what does that have to do with mail? You can have mail lost in the intermediate stages. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. -- 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 Feb 13 19:23: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 97E1928C0F3; Wed, 13 Feb 2008 19:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foC3FbCFAdpp; Wed, 13 Feb 2008 19:23:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 000B43A6FDF; Wed, 13 Feb 2008 19:23:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPUZk-000KWz-6N for namedroppers-data@psg.com; Thu, 14 Feb 2008 03:15:52 +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 1JPUZh-000KWc-Cb for namedroppers@ops.ietf.org; Thu, 14 Feb 2008 03:15:50 +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 m1E3FdsL084459; Thu, 14 Feb 2008 14:15:39 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802140315.m1E3FdsL084459@drugs.dv.isc.org> Cc: Edward Lewis , Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Thu, 14 Feb 2008 14:14:49 +1100." Date: Thu, 14 Feb 2008 14:15:39 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > > At 9:51 +1100 2/14/08, Mark Andrews wrote: > > > > >>> NXDOMAIN is a fatal error for mail, etc. > > >> > > >> I don't understand why this is mentioned. > > > > > > Because the only other choice is to make names DISAPPEAR > > > then REAPPEAR as you DESTROY/REBUILD the namespace below > > > the DNAME. > > > > > > zone with lots of content beneath new DNAME location > > > | > > > *** LOTS OF NXDOMAINS *** > > > DESTROY > > > V > > > zone with not content beneath new DNAME location > > > | > > > *** LOTS OF NXDOMAINS *** > > > V > > > zone with DNAME > > > > > > or > > > > > > zone with DNAME > > > | > > > V > > > zone with not content beneath old DNAME location > > > | > > > *** LOTS OF NXDOMAINS *** > > > REBUILD > > > V > > > zone with lots of content beneath old DNAME location > > > > Still not getting the point. How often is this a concern? How often > > would a zone be run this way? I understand the scenario, the > > question is, when in operations would this be a concern? > > Does it really matter how often? All we need to realise > as engineers is that it happens with zone which are being > managed via dynamic update. Such changes should happen > with having to shut the server down, manually edit the zone without > and then reload it. Often the people that are managing the > zone don't have access to do this. Pick any of the dynamic > dns service providers for examples of where manual changes > are not available. You can create the zone, delete the zone > and the rest is done via update. > > > And what does that have to do with mail? > > You can have mail lost in the intermediate stages. > > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 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. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Feb 13 19:34: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 2F77028C7A7; Wed, 13 Feb 2008 19:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh6YNEKuL3M5; Wed, 13 Feb 2008 19:34:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D21EE3A68A8; Wed, 13 Feb 2008 19:34:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPUmv-000Ld6-A6 for namedroppers-data@psg.com; Thu, 14 Feb 2008 03:29:29 +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 1JPUms-000Lcj-N7 for namedroppers@ops.ietf.org; Thu, 14 Feb 2008 03:29:28 +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 m1E3THgr084621; Thu, 14 Feb 2008 14:29:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802140329.m1E3THgr084621@drugs.dv.isc.org> To: Edward Lewis Cc: Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Wed, 13 Feb 2008 16:43:07 CDT." Date: Thu, 14 Feb 2008 14:29:17 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > At 8:24 +1100 2/14/08, Mark Andrews wrote: > > > Any change can have unintend consecquences. Your wanting > > to make the zone contents disappear before the update has > > unintended consequnences. There *will* be a window where > > names that used to exist won't and then will exist once the > > DNAME is added. > > What I meant by unintended consequences is that when occluding the > names, the status of names are changing without an explicitly > communication. If the introduction of a DNAME is prevented because > there are names in place and must be explicitly removed first, then > all the changes are explicitly communicated. Pre-requisites are what prevent unintended consequences in UPDATE. If we don't have a appropriate pre-requisite we need to invent one. 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 Feb 15 02:48: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 CC7133A6973; Fri, 15 Feb 2008 02:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnrYw4wZHdvM; Fri, 15 Feb 2008 02:48:37 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 13B403A6874; Fri, 15 Feb 2008 02:48:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPxyv-00007J-Tz for namedroppers-data@psg.com; Fri, 15 Feb 2008 10:39:49 +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 1JPxys-00006k-4U for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 10:39:48 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1FAdQqO083887; Fri, 15 Feb 2008 11:39:26 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47B56BDE.7050003@nlnetlabs.nl> Date: Fri, 15 Feb 2008 11:39:26 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Resolution of the DNAME via dynamic update issue References: <200802140315.m1E3FdsL084459@drugs.dv.isc.org> In-Reply-To: <200802140315.m1E3FdsL084459@drugs.dv.isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 15 Feb 2008 11:39:27 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: |>> Still not getting the point. How often is this a concern? How often |>> would a zone be run this way? I understand the scenario, the |>> question is, when in operations would this be a concern? |> Does it really matter how often? All we need to realise |> as engineers is that it happens with zone which are being |> managed via dynamic update. Such changes should happen |> with having to shut the server down, manually edit the zone | | without | |> and then reload it. Often the people that are managing the |> zone don't have access to do this. Pick any of the dynamic |> dns service providers for examples of where manual changes |> are not available. You can create the zone, delete the zone |> and the rest is done via update. So, I understand the argument is that the obscure option provides a feature that the error-code option does not provide. The obscure option provides a way for zone operators to leverage a DNAME to make large changes to the zone, atomically, using dynamic update. The error code option argument is that it doesn't have obscuring, which is then an unwanted feature. A clean way to do this is to have a good precondition, or proper errorcode to return. ~From the discussion I gather that NS records can also be leveraged to make large atomic changes using dynamic update. Leverage procedure: 1) copy current zone contents to a remote server or zone 2) set a NS or DNAME to point to that server or zone. Users get same content but via an indirection 3) build up large change using dynamic update requests to obscured records. 4) remove NS or DNAME, exposing the covered data atomically. To be honest, I never heard of this feature before. I can imagine it being useful. I hope I rendered the procedure correctly here. The fact remains that non dynamic update servers do not expect obscured data in zone transfers or zone files. There is no RFC telling them about it. That would mean that obscured data requires all servers that support AXFR/IXFR to start supporting dynamic update features to implement covered data features. I highly doubt that existing AXFR/IXFR but not dynamic update servers do so. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHtWvdkDLqNwOhpPgRAnKYAKCTyazoO3SaSIMZs2czb6aRNirTHACgrnVp mRZvXzGfcy/txlFT178aIWE= =ZTB4 -----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 Fri Feb 15 05:06: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 1376C3A689A; Fri, 15 Feb 2008 05:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoX0f5SqEXvz; Fri, 15 Feb 2008 05:06:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 096333A6834; Fri, 15 Feb 2008 05:06:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ08t-000Hph-3y for namedroppers-data@psg.com; Fri, 15 Feb 2008 12:58:15 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ08o-000Hoh-Ia for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 12:58:12 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JWA0060169RBN00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 12:58:08 +0000 (GMT) Received: from [137.43.2.214] by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0JWA00HFY6OV0YD0@cali.ucd.ie>; Fri, 15 Feb 2008 12:58:08 +0000 (GMT) Date: Fri, 15 Feb 2008 12:58:01 +0000 From: Niall O'Reilly Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: <18355.22827.31633.105664@guava.gson.org> To: Andreas Gustafsson Cc: Niall O'Reilly , Scott Rose , namedroppers@ops.ietf.org Message-id: <195365DB-0BF0-47B3-8116-D3177D070C37@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: multipart/signed; boundary=Apple-Mail-8--712700983; micalg=pgp-sha1; protocol="application/pgp-signature" Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.2 (Tiger) References: <18355.22827.31633.105664@guava.gson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Apple-Mail-8--712700983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed On 13 Feb 2008, at 20:55, Andreas Gustafsson wrote: >> A dynamic update message adding a DNAME RR at a >> name that already has RR=92s of some other type would still generate =20= >> an error >> (must be delete/add operation). > > This error case is analogous to the existing error case of adding a > CNAME to a name having other data, and for consistency, it should be > dealt with in the same way, by ignoring the update RR. Since when is a DNAME not allowed _at_ a name that already has RR's of some other type (except CNAME, of course)? Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 --Apple-Mail-8--712700983 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.1 (Darwin) iD8DBQFHtYxdeYfkja6ZXtkRAqt4AJ9dB+niCuSfWz/wU6NwsFUhhzjzcgCgpHoh kcVXj31h7ctIYKWx6DTCwGc= =u89z -----END PGP SIGNATURE----- --Apple-Mail-8--712700983-- -- to unsubscribe send a message to namedroppers-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 Feb 15 05:24: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 8460C3A68AE; Fri, 15 Feb 2008 05:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w97SNZfHWCOv; Fri, 15 Feb 2008 05:24:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EAA6B28D197; Fri, 15 Feb 2008 05:24:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ0V8-000L6i-8K for namedroppers-data@psg.com; Fri, 15 Feb 2008 13:21:14 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ0Uz-000L5b-Jw for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 13:21:08 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id 0FF497C8E0; Fri, 15 Feb 2008 13:18:40 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id C5FBA75F43; Fri, 15 Feb 2008 15:21:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18357.37311.714274.916287@guava.gson.org> Date: Fri, 15 Feb 2008 15:21:03 +0200 To: Niall O'Reilly Cc: Andreas Gustafsson , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Resolution of the DNAME via dynamic update issue In-Reply-To: <195365DB-0BF0-47B3-8116-D3177D070C37@ucd.ie> References: <18355.22827.31633.105664@guava.gson.org> <195365DB-0BF0-47B3-8116-D3177D070C37@ucd.ie> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Niall O'Reilly wrote: > On 13 Feb 2008, at 20:55, Andreas Gustafsson wrote: > >> A dynamic update message adding a DNAME RR at a > >> name that already has RR=92s of some other type would still genera= te =20 > >> an error > >> (must be delete/add operation). > > > > This error case is analogous to the existing error case of adding a= > > CNAME to a name having other data, and for consistency, it should b= e > > dealt with in the same way, by ignoring the update RR. >=20 > =09Since when is a DNAME not allowed =5Fat=5F a name that already > =09has RR's of some other type (except CNAME, of course)=3F Sorry, I responded to Mark's comment without checking his assertions. You're right, DNAME is allowed at a name that has other RRs (except CNAME or another DNAME). What I should have said was that cases that actually =5Fare=5F errors, such as attempts to add a DNAME to a name already having a CNAME or another DNAME, should be dealt with by ignoring the update RR, since that is how RFC2136 generally deals with errors (as opposed to unsatisfied prerequisites, which cause error responses to be sent). --=20 Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 15 07:18: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 9268828D17D; Fri, 15 Feb 2008 07:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlcHxEcgPFp7; Fri, 15 Feb 2008 07:18:16 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4D97D3A67DB; Fri, 15 Feb 2008 07:18:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ2AY-000AwP-Vz for namedroppers-data@psg.com; Fri, 15 Feb 2008 15:08:06 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ2AW-000Aw4-Bm for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 15:08:05 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JWA00K01CLHGU00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 15:08:02 +0000 (GMT) Received: from [137.43.2.214] by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0JWA00LPUCPDHV70@cali.ucd.ie>; Fri, 15 Feb 2008 15:08:01 +0000 (GMT) Date: Fri, 15 Feb 2008 15:07:55 +0000 From: Niall O'Reilly Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: <18357.37311.714274.916287@guava.gson.org> To: gson@araneus.fi (Andreas Gustafsson) Cc: Niall O'Reilly , Scott Rose , namedroppers@ops.ietf.org Message-id: <53F7BA91-AA57-4471-860A-BC27D62EAD51@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: multipart/signed; boundary=Apple-Mail-9--704907127; micalg=pgp-sha1; protocol="application/pgp-signature" Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.2 (Tiger) References: <18355.22827.31633.105664@guava.gson.org> <195365DB-0BF0-47B3-8116-D3177D070C37@ucd.ie> <18357.37311.714274.916287@guava.gson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --Apple-Mail-9--704907127 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 15 Feb 2008, at 13:21, Andreas Gustafsson wrote: > Sorry, I responded to Mark's comment without checking his assertions. Sorry, I responded to yours without looking back along the thread. > You're right, DNAME is allowed at a name that has other RRs (except > CNAME or another DNAME). > > What I should have said was that cases that actually _are_ errors, > such as attempts to add a DNAME to a name already having a CNAME or > another DNAME, should be dealt with by ignoring the update RR, since > that is how RFC2136 generally deals with errors (as opposed to > unsatisfied prerequisites, which cause error responses to be sent). Makes sense. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 --Apple-Mail-9--704907127 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.1 (Darwin) iD8DBQFHtarQeYfkja6ZXtkRAoouAJwJZLd+AMF8SQP5/NkLVNbEr4k7jwCeP7WI ZefphU8F4omAVwxDcFELBNo= =SSiO -----END PGP SIGNATURE----- --Apple-Mail-9--704907127-- -- to unsubscribe send a message to namedroppers-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 Feb 15 08: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 BA07628D1B1; Fri, 15 Feb 2008 08:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrMieCXgCvv2; Fri, 15 Feb 2008 08:30:16 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E7C5F28D108; Fri, 15 Feb 2008 08:30:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ3Js-000LM9-0I for namedroppers-data@psg.com; Fri, 15 Feb 2008 16:21:48 +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 1JQ3Jp-000LLc-GZ for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 16:21:46 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C76121145C; Fri, 15 Feb 2008 16:21:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Wouter Wijngaards cc: Mark Andrews , Edward Lewis , Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Resolution of the DNAME via dynamic update issue In-Reply-To: Your message of "Fri, 15 Feb 2008 11:39:26 +0100." <47B56BDE.7050003@nlnetlabs.nl> References: <200802140315.m1E3FdsL084459@drugs.dv.isc.org> <47B56BDE.7050003@nlnetlabs.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 15 Feb 2008 16:21:44 +0000 Message-ID: <19547.1203092504@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > So, I understand the argument is that the obscure option provides a > feature that the error-code option does not provide. that's not my argument. my argument is, there is no way to get that error code at the moment. we would have to define a new kind of UPDATE prerequisite, to which a possible response would be YXDOMAIN. i think we should avoid defining a new kind of prerequisite to handle DNAME, and that's my argument for why the obscure option is better. -- to unsubscribe send a message to namedroppers-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 Feb 15 14:50: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 1E34D3A6B5E; Fri, 15 Feb 2008 14:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42OXp-vwwMFr; Fri, 15 Feb 2008 14:50:52 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9081F28C2DA; Fri, 15 Feb 2008 14:49:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ9GF-000PjZ-GT for namedroppers-data@psg.com; Fri, 15 Feb 2008 22:42:27 +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 1JQ9GB-000Pj2-DY for namedroppers@ops.ietf.org; Fri, 15 Feb 2008 22:42:26 +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 m1FMfwMG098828; Sat, 16 Feb 2008 09:41:59 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802152241.m1FMfwMG098828@drugs.dv.isc.org> To: Wouter Wijngaards Cc: Edward Lewis , Olafur Gudmundsson , Scott Rose , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Resolution of the DNAME via dynamic update issue In-reply-to: Your message of "Fri, 15 Feb 2008 11:39:26 BST." <47B56BDE.7050003@nlnetlabs.nl> Date: Sat, 16 Feb 2008 09:41:58 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Andrews wrote: > |>> Still not getting the point. How often is this a concern? How often > |>> would a zone be run this way? I understand the scenario, the > |>> question is, when in operations would this be a concern? > |> Does it really matter how often? All we need to realise > |> as engineers is that it happens with zone which are being > |> managed via dynamic update. Such changes should happen > |> with having to shut the server down, manually edit the zone > | > | without > | > |> and then reload it. Often the people that are managing the > |> zone don't have access to do this. Pick any of the dynamic > |> dns service providers for examples of where manual changes > |> are not available. You can create the zone, delete the zone > |> and the rest is done via update. > > So, I understand the argument is that the obscure option provides a > feature that the error-code option does not provide. The obscure option > provides a way for zone operators to leverage a DNAME to make large > changes to the zone, atomically, using dynamic update. > > The error code option argument is that it doesn't have obscuring, which > is then an unwanted feature. A clean way to do this is to have a good > precondition, or proper errorcode to return. > > ~From the discussion I gather that NS records can also be leveraged to > make large atomic changes using dynamic update. > > Leverage procedure: > 1) copy current zone contents to a remote server or zone That assumes you *have* another server. It can't be the existing server or the zone will be found via normal delegation. > 2) set a NS or DNAME to point to that server or zone. Users get same > content but via an indirection > 3) build up large change using dynamic update requests to obscured records. > 4) remove NS or DNAME, exposing the covered data atomically. Say you have SOA + NS + DNAME and you want to remove the DNAME and have a complete zone. You can't replace the DNAME with a NS RRset. > To be honest, I never heard of this feature before. I can imagine it > being useful. I hope I rendered the procedure correctly here. > > The fact remains that non dynamic update servers do not expect obscured > data in zone transfers or zone files. There is no RFC telling them about > it. There will be if we tell them in this document. > That would mean that obscured data requires all servers that support > AXFR/IXFR to start supporting dynamic update features to implement > covered data features. I highly doubt that existing AXFR/IXFR but not > dynamic update servers do so. And no one has complained in the last 8 years about BIND 9 doing it. It is a rarely used option at this point. When we look at RFC's for reveiw, we are supposed to look at what we got wrong and repair it. > Best regards, > ~ Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFHtWvdkDLqNwOhpPgRAnKYAKCTyazoO3SaSIMZs2czb6aRNirTHACgrnVp > mRZvXzGfcy/txlFT178aIWE= > =ZTB4 > -----END PGP SIGNATURE----- -- 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 Feb 16 15:28: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 577FE3A6B5E; Sat, 16 Feb 2008 15:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=1.953, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV11fdA0LWwf; Sat, 16 Feb 2008 15:28:34 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0C42F3A6B3F; Sat, 16 Feb 2008 15:28:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQWFO-000ClR-U0 for namedroppers-data@psg.com; Sat, 16 Feb 2008 23:15:06 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQWFL-000CkQ-Pi for namedroppers@ops.ietf.org; Sat, 16 Feb 2008 23:15:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id C2FAB3A6ABF; Sat, 16 Feb 2008 15:15:01 -0800 (PST) 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-dnssec-rsasha256-03.txt Message-Id: <20080216231501.C2FAB3A6ABF@core3.amsl.com> Date: Sat, 16 Feb 2008 15:15:01 -0800 (PST) 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 : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-03.txt Pages : 9 Date : 2008-02-16 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-rsasha256-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-16150441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-rsasha256-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-16150441.I-D\@ietf.org> --OtherAccess-- --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 Feb 18 13:11: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 1584C28C0E9; Mon, 18 Feb 2008 13:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=-2.897, 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 9RkhEUEXQBuN; Mon, 18 Feb 2008 13:11:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BECE3A6C71; Mon, 18 Feb 2008 13:11:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRDA4-0003q6-4w for namedroppers-data@psg.com; Mon, 18 Feb 2008 21:04:28 +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 1JRDA1-0003pl-8i for namedroppers@ops.ietf.org; Mon, 18 Feb 2008 21:04:26 +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 1JRD9y-0004jf-Lu for namedroppers@ops.ietf.org; Mon, 18 Feb 2008 22:04:22 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7F95D45AA; Mon, 18 Feb 2008 22:04:25 +0100 (CET) Date: Mon, 18 Feb 2008 22:04:25 +0100 From: bert hubert To: namedroppers@ops.ietf.org Subject: notes accompanying -02 of forgery-resilience draft Message-ID: <20080218210425.GA27088@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, I've just posted -02 of draft-ietf-dnsext-forgery-resilience, which has received quite a bit of love and changes since -01. Until it appears on the IETF site, please use http://ds9a.nl/tmp/draft.html A summary: * Included Stub Resolvers (closing ticket 7) * Added a 'security' section * strictly made this draft apply to *implementations* that should have certain *abilities*. It is up to the operator to choose an implementation that does or does not support these abilities, and it is to the operator to choose if or not to turn on said abilities. * added a *note* to the effect that lower TTL values in zones are easier to spoof - non-normative * typos removed * countermeasures rewritten heavily to be less specific about measures but more about results - no discussion on what 'random' means exactly, but focus on 'unpredictable'. * some wording improvements (differences between resolver, nameserver etc) * document now updates 1034 instead of confusingly claiming to update either 1034 or 1035 * added reference to TSIG/IPSEC rfc's as another way to secure communications Click through http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/timeline to see the exct diffs. It is suggested we do a final round of critical reading with limited and focused changes before last call. Kind regards, Bert Hubert & Remco van Mook -- 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 Feb 18 13:11: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 59F633A689E; Mon, 18 Feb 2008 13:11:54 -0800 (PST) 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.007, 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 OZUxyvXekLyn; Mon, 18 Feb 2008 13:11:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFCD63A6CE8; Mon, 18 Feb 2008 13:11:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRD7c-0003YV-Vw for namedroppers-data@psg.com; Mon, 18 Feb 2008 21:01:56 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRD6O-0003Q5-PZ for namedroppers@ops.ietf.org; Mon, 18 Feb 2008 21:01:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id AB0E13A6876; Mon, 18 Feb 2008 13:00:01 -0800 (PST) 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-02.txt Message-Id: <20080218210001.AB0E13A6876@core3.amsl.com> Date: Mon, 18 Feb 2008 13:00:01 -0800 (PST) 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-02.txt Pages : 21 Date : 2008-02-18 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-forgery-resilience-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-18125037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18125037.I-D\@ietf.org> --OtherAccess-- --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 Feb 18 14:15: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 7B0063A6DF2; Mon, 18 Feb 2008 14:15:23 -0800 (PST) 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 f+muJfJXdzFb; Mon, 18 Feb 2008 14:15:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6243528C57E; Mon, 18 Feb 2008 14:12:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRE7Q-000AJF-Tw for namedroppers-data@psg.com; Mon, 18 Feb 2008 22:05:48 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRE7O-000AIt-05 for namedroppers@ops.ietf.org; Mon, 18 Feb 2008 22:05:47 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 49871C2DFE; Mon, 18 Feb 2008 22:05:42 +0000 (GMT) Date: Mon, 18 Feb 2008 22:05:40 +0000 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: notes accompanying -02 of forgery-resilience draft Message-ID: In-Reply-To: <20080218210425.GA27088@outpost.ds9a.nl> References: <20080218210425.GA27088@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --On 18 February 2008 22:04:25 +0100 bert hubert wrote: > * countermeasures rewritten heavily to be less specific about measures but > more about results - no discussion on what 'random' means exactly, but > focus on 'unpredictable'. Next time you are making some changes, you could look out for use of the word random elsewhere. In some places you really mean "random or pseudo-random", whereas in other places I think you mean "arbitrary". For a trivial example, "random authoritative nameserver" in 1.1, but more perniciously "pick a random port" in the second para of 4.4 should be, I think, "use an arbitrary port" (whereas the next para is correct, I think). 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 Mon Feb 18 15:23: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 256513A6897; Mon, 18 Feb 2008 15:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9yk1jGryvK1; Mon, 18 Feb 2008 15:23:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBDF03A6785; Mon, 18 Feb 2008 15:23:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRFFI-000Hiu-Ey for namedroppers-data@psg.com; Mon, 18 Feb 2008 23:18:00 +0000 Received: from [69.17.117.9] (helo=mail7.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRFFE-000HiV-Po for namedroppers@ops.ietf.org; Mon, 18 Feb 2008 23:17:58 +0000 Received: (qmail 3896 invoked from network); 18 Feb 2008 23:17:55 -0000 Received: from unknown (HELO [164.99.121.186]) (federico@[130.57.22.201]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Feb 2008 23:17:55 -0000 Message-ID: <47BA121E.8010507@ximian.com> Date: Mon, 18 Feb 2008 18:17:50 -0500 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft References: <20080218210425.GA27088@outpost.ds9a.nl> In-Reply-To: <20080218210425.GA27088@outpost.ds9a.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 Found no substance corrections. Stylistically, I would suggest: - replacing the term "fake data" with something more specific. In most cases, something akin to "doctored resource records" would do. - in 4.3, "several important documents". Suggesting the more specific "two Best Current Practice documents". - in 5, the first paragraph "a curious mathematical phenomenon means..." can be rewritten as "a known probability problem, known as the birthday paradox, describes the probability..." I guess this is the editor's job, but I thought I would lend a hand. The document looks generally good. Nice job! Best-Federico bert hubert wrote: > Hi everybody, > > I've just posted -02 of draft-ietf-dnsext-forgery-resilience, which has > received quite a bit of love and changes since -01. > > Until it appears on the IETF site, please use > http://ds9a.nl/tmp/draft.html > > A summary: > > * Included Stub Resolvers (closing ticket 7) > * Added a 'security' section > * strictly made this draft apply to *implementations* that should have > certain *abilities*. It is up to the operator to choose an implementation > that does or does not support these abilities, and it is to the operator to > choose if or not to turn on said abilities. > * added a *note* to the effect that lower TTL values in zones are easier to > spoof - non-normative > * typos removed > * countermeasures rewritten heavily to be less specific about measures but > more about results - no discussion on what 'random' means exactly, but focus > on 'unpredictable'. > * some wording improvements (differences between resolver, nameserver etc) > * document now updates 1034 instead of confusingly claiming to update either > 1034 or 1035 > * added reference to TSIG/IPSEC rfc's as another way to secure > communications > > Click through http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/timeline to > see the exct diffs. > > It is suggested we do a final round of critical reading with limited and > focused changes before last call. > > Kind regards, > > Bert Hubert & Remco van Mook > > -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 15:26: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 B99E73A68A9; Mon, 18 Feb 2008 15:26:12 -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 mGaMSFo6mMvo; Mon, 18 Feb 2008 15:26:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB1BF3A686E; Mon, 18 Feb 2008 15:26:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRFJh-000I6q-60 for namedroppers-data@psg.com; Mon, 18 Feb 2008 23:22:33 +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 1JRFJd-000I6L-Va for namedroppers@ops.ietf.org; Mon, 18 Feb 2008 23:22:31 +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 m1INMNPY034159; Tue, 19 Feb 2008 10:22:23 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802182322.m1INMNPY034159@drugs.dv.isc.org> To: Internet-Drafts@ietf.org Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt In-reply-to: Your message of "Mon, 18 Feb 2008 13:00:01 -0800." <20080218210001.AB0E13A6876@core3.amsl.com> Date: Tue, 19 Feb 2008 10:22:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion This is the second time in recent weeks that a draft that should have been there was not. Instead of draft I'm getting the expired boiler plate for the previous revision of the draft. Something is systematically going wrong. Mark % fetch http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt draft-ietf-dnsext-forgery-resilience-02.txt 100% of 973 B 2399 kBps farside.isc.org:marka {2} % fetch ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt draft-ietf-dnsext-forgery-resilience-02.txt 100% of 973 B 476 kBps % cat draft-ietf-dnsext-forgery-resilience-02.txt This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted from the Internet-Drafts directory. An Internet-Draft expires 185 days from the date that it is posted unless it is replaced by an updated version, or the Secretariat has been notified that the document is under official review by the IESG or has been passed to the RFC Editor for review and/or publication as an RFC. This Internet-Draft was not published as an RFC. Internet-Drafts are not archival documents, and copies of Internet-Drafts that have been deleted from the directory are not available. The Secretariat does not have any information regarding the future plans of the author(s) or working group, if applicable, with respect to this deleted Internet-Draft. For more information, or to request a copy of the document, please contact the author(s) directly. Draft Author(s): Remco van Mook , Bert Hubert % date Mon Feb 18 23:21:37 UTC 2008 % -- 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 Feb 19 04: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 CFFCA28C549; Tue, 19 Feb 2008 04:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is5IHb1H7BwD; Tue, 19 Feb 2008 04:32:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2851F3A6A7E; Tue, 19 Feb 2008 04:32:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRVA-000ADY-Og for namedroppers-data@psg.com; Tue, 19 Feb 2008 12:23:12 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRV6-000ACy-Qo for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 12:23:10 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:42462) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp id 1JRRUv-0003z5-IU (Exim 4.67) (return-path ); Tue, 19 Feb 2008 12:22:57 +0000 Received: from cet1 by draco.cus.cam.ac.uk with local (Exim 4.68) (envelope-from ) id 1JRRUv-0001Us-JW; Tue, 19 Feb 2008 12:22:57 +0000 Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt To: Mark_Andrews@isc.org (Mark Andrews) Date: Tue, 19 Feb 2008 12:22:57 +0000 (GMT) Cc: Internet-Drafts@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200802182322.m1INMNPY034159@drugs.dv.isc.org> from "Mark Andrews" at Feb 19, 8 10:22:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Mark Andrews writes: > This is the second time in recent weeks that a draft that > should have been there was not. Instead of draft I'm > getting the expired boiler plate for the previous revision > of the draft. Something is systematically going wrong. Certainly looks like it: $ ftp ftp.ietf.org Connected to ftp.ietf.org. [...] ftp> dir /internet-drafts/draft-ietf-dnsext-forgery-resilience-* -rw-r--r-- 1 0 0 973 Feb 16 05:01 draft-ietf-dnsext-forgery-resilience-02.txt -rw-r--r-- 1 30 8 30427 Feb 18 20:50 draft-ietf-dnsext-forgery-resilience-02.xml The XML version seems to be correct. -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-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 Feb 19 04:44: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 BC35D3A6A60; Tue, 19 Feb 2008 04:44:16 -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 kW3QI3Cp390m; Tue, 19 Feb 2008 04:44:15 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4C1A3A6895; Tue, 19 Feb 2008 04:44:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRkR-000Brk-OD for namedroppers-data@psg.com; Tue, 19 Feb 2008 12:38:59 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRkN-000Bqz-5h for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 12:38:57 +0000 X-IronPort-AV: E=Sophos;i="4.25,376,1199664000"; d="gz'50?scan'50,208,50";a="15234614" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 Feb 2008 12:38:53 +0000 To: namedroppers@ops.ietf.org Subject: heads up for NSEC3 software implementers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: roy@nominet.org.uk Date: Tue, 19 Feb 2008 12:38:52 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 19/02/2008 12:38:52 PM Content-Type: multipart/mixed; boundary="=_mixed 0045797FC12573F4_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --=_mixed 0045797FC12573F4_= Content-Type: text/plain; charset="US-ASCII" This is a heads up for implementers of software that contain DNSSEC functions for signing and validating NSEC3 zones. During the various tests we used the provisional DNS Security Algorithm Numbers 131 and 133 for respectively DSA-NSEC3-SHA1 and RSASHA1-NSEC3-SHA1. The IANA has assigned DNS Security Algorithm Numbers 6 and 7 for respectively DSA-NSEC3-SHA1 and RSASHA1-NSEC3-SHA1. http://www.iana.org/assignments/dns-sec-alg-numbers Please update your software. Thanks, Roy Arends Nominet UK PS. Though this seems a trivial change at some code-points, I do realize that folks need to test against (for instance) the example zone present in the appendix. I've attached the example zone in this mail. Feel free to ping me for additional test material or examples. --=_mixed 0045797FC12573F4_= Content-Type: application/x-gzip; name="example.signed.gz" Content-Disposition: attachment; filename="example.signed.gz" Content-Transfer-Encoding: base64 H4sICPfLukcAA2V4YW1wbGUuc2lnbmVkANVaWY+jWLJ+r19h9dPMoEmzL93qB8DGYGxjwCzmjX3f V/vXj7Od1Z1VlZR7cqS8eUmlkKX4IPgiTmzn/Pbbgv8H3BEOGqJDa2NtHqNEikP5gDkDZMOwUybN kz/ZeZX5/1z8vkjLyG6I3HFIz4Vdn7SpesjIqCzQFEP6KP7y2/MTx28gZO/5+VBBCRwQfognvlO1 EDFUSEHGGBndIa8AYEXlkT349ZDjHTE4GZaVFdwjHdxUSFfmd8A0vX5Jh6Oo79Qp5cSOW9gkgYbx 0OBJmeBwnkXDHfOvp280azDEqQnXhfsh752gx0o3z/HKb1qqSym/uIMu34KSGC/80vargXSwEk9R f0AQ24lsMuqoIHTvoKKFX4NqEE1S1x9un9STWANCqEt4qWMjZAkmMdZ8BUGvQY/s8sLDt+o5aJ+T uB9GkdfeFLUhCm/zIc9KtLx9FoXdQfZrCILlXRRWodtDdYiTge1AOJZmRVukiFcN2df3fEcEPFRd j3Vxbud114UZmvU9lYYw5IN22SDty5vi15gw8Wsfg/EqcwIoJPM0q7Ab0YFHkFSRhPGXF9mnxf1S JfqP+ytmnhZOH7ZPrz77aQEtEBwEF8jt/x9fFm9fzxLgs9Cz5D+/l1IUVdi8vJD4+jwYhDAQhUEY wSiMuv0EMQiEIfD+oNk3oSCKgIs/lZsT43sY04TL4ZgPR0Fnmsw7ANQ+qyirzhCqtjWPjGfBNWrt srMRaJrj0CoKVRsAJ68kVENTlJ5pd33hvVmwLsC7XOxbx2pPoPz77z/ScVDv9294nxeC54W+EnsT /iBej7oUdnsR4nlfPdk9wI8rgyVPLYCzZN3VHlrJ23lepc5b62EI7GnAjtHAWK2jHqn57WXnylTn rOBhmAWzxd5MuiuuXiRnot/idW/e79Dir/A1z9lN+oM424QyRFNTewsyKKwfh2q3tCHG0K5L3GwL Pk3KbpwFU2pJ7uXO6jJ43DJtIcmtXfKNwjaKc2nidbbcWLPggtp35VKcgJEpgfEtzlYHVVyfFwsY wxfIjRB6XNO07Xext7u2oqF1aDsaCnnpwfHIH2MtJnfaPCEtvQLlo6EB47UjKb+S8I6/pntGX6Us UVeRLMHRrLKnMxrxBVVUBqeMGHPunfVPFSb+UtjVMk6HhiivJ/ygSppUw8rSaxXCzJG+2s4rnBBC meeGWm1pRg8MUgYbaTC9PZ5eO+BE9xS8o2YVpp1W85xsz8UFyeocUqDtGwp/9bcXxed8blbF75wR ggmQfOxzdK+hSa9Rij35ravmatfIaYtsIopzsg2T6RoCzYL7695aakuuajWHtFlctlSgPbVbs9gV VyLINlKbz4L3G9kKEIcH5Jbtwrfj35pFjrRC729cPH/RwrYdx3W9H4PqXwHuT8j/SuDfXLQstMnI 7mgduiLJmrOx8n1NX7abHXu5LAU+9uHGnwU3BxAzVRo51qCGAKg+bIyz4Wn7IMgkb6oLkx/no+Rp J7dJll6KaIOzdwIfFW1/Rbs/iLoxBH1D6zw3D6qg5yj54ri3HDP3lOe8/spCd6PNLoS7isQC/ojY K6mhoeYwzgCuCnir3a2slBujWXprI+rYVsxGcTcLFhj+zONOpkwi1bCgs98eRxnNd0I/khgPr88E Ds+CGYk1t9a+qPoxqu756u/2Ak8LegFR8BP4BD/d1vvsqqA/isUIdwHAuUZKbxgd7FzSA54n9unA uOahxrR+h63nCyIRiFdH1D+TApiqsWizSYh0LKTKqZ+Ve7934I0xC07JCp/4/dHqczN7M4Pd3Wnx X/j8g9L6Ruun8uCcGbbQrWqCIlbcmzwXH3zhzIuUqRtgvFvtxu1hFoyeuPIwWf0RRELaXAs4gp5H yUXPzEE4NQkKIXE9Cz4IeK6kywbyJFW7c/+Iu3cHokdt0nMg+kxWEXeQDpfcOYwOOsjnxCm4UbNN 9ngGgCG0ZV39vJlvEQIBzMQmOuanVqIp3N2taTYsoYkUiJSutiZQOvPpoU87C2i91jqeobtVHpH3 bqs86nefk8JK/VSGCfHkqGmV19NbUckSrT2QIYNq9s39wcN0ptpolOerpktxLcm1ZvDAFY/WApNp p+MmgTDfyjJcj+Q6nC+2zY4WFMSNxtAA1HvAt5++ablfN37232v9fiK2ehHDSJQAF9jNpvOrCyQo DsIoZM3QK3zFQjC0vhmAJhkCx2mcRkmEgEGc/Un1qn6UAU3b5VxZ53f61StdFFtvowMO4ddb4l2b 3Zrkrtp8D7GHRSMJLpAeKOKKaqC9r2/GsexTSQy3E3PkWqOcBZcEDA8WqlmwJ3h3A35nKfpF8mty xhZfvjPS9xL44stfQ5o/vOB7iR/7i49P77oPjOJ5n0nOSTlGt4Wyw4nN5FvBrVhtlrKv4NwsuAs8 OsEALjxPl+txnQjXQTQuIBgZQoaPK0QfW2C+UL4W64JsZRzVvPrNpp4XDpx0u/8i7vh/Q+Avi1+E k/rLLGd38Q/i7RyjcC/VKOJfJLw2+cMwjgFXCH3bGaGO9Q3nTrNgv0h3Q4tXohKBoM4k0ioPEAst 9hIhSBle8Ko836EN4Ljjq7W1IcwEfrMsom/X8/32ydCvnkP+Cr78BSD4q2PbP3G7Z+QHMbhzvelW ETKYs7HG4yoEkO0WlUD4Wu6ZJpnqLMDna8Pe5mXLCk5a5VCHAC4mbuPDpnIMFKyrtid84ynzOdjl e3/Xm+k+YejmPqZ7lO3enUYfDWY/W3FjpccNskfgLC/5PV7ZyAoPLW7DLJtot1wyLSLl8yEY69F8 yWrx2DnZWpdsWhQtj1Bvakp+bKKIvTORWXAlDeBJPV3i0yRY997Xnc+h7t/Loa/FvoN9H4yJe0D/ iQS5+PLInO/2k0e7Hy/Rjb4v0bmnfCZPEvTCv562VFw7GcdRxHBU88C0MKu8FuGEiCbiXOaDw8li UZnhYY8zogBv3WbDWQxFgnTATuWKqh1HnAWvLkDjbQRfUfXD5R4hH9H7brs92oT7JMYIjylXQS0s r2R8lK9uCPWq71g4ZCBIozEr95T8OGv4esEcksooBQZrryJSiNGEwHGt7uiYyJmt1kArdOB8WVZd dVUMTuOE9ud7mn/E2fuN8WAT9ZMYg+vMjTNwIDAGZGykl5JA/ILu9QlE0uwAVMKOmXduFa9ZN+j0 LuDRi35t11bdb2HiwCtE009bY3XYd/MDhW4iRsoIXCHE4RdjPODs3cZ4tDX7yWYterMyW7jXDRg6 gKR6kYUrSV7zDLigFisUpzFcNbNg/HpFkQsdAjturSRSkyBS4nYYZLvEqkJ9ywmo+Spa3trXnFY5 cTNtzPDP3uNV6vs+Ef1YHH543+D0eDoRSIGb674o9U2vBHR4Jtbckt7W/IWIEjCZn+zF9TZhQE9q JmTsr5RqM/4mqA3BK5Z9ZyOqPfxkrsUpg6VQKsvxHCa/0AX/jK4fB7UfTlfaycipXoNsoARpDCrO UqgwZg/qxeRnTu8nLIvOgq/VzuFEekn4K0I70OO0D6ftsXM89QS0l+Ssbu15rlGBD3wTL8ghKDf3 Jf9oZb57yT869/HJlnykYwJJOQDK8dsVfapAKkQd5wAqEEeiGGub1W6+XLWmbC/GeXmkL3Xmd/ts bYy7gIttovUq9VoAVjbvw4csnQx31wrZPtfuS/4Rd+82yqMTPJ+tA7H7aoj1uOnNFnVWIdWwjn+9 MvuAiiArWw2OsWTnrcKJfSZsTHOXkMwyaFdbuzH1FU05hVYq0doRq/mJBM9BnCEahCJsve4eWR6R 926rPNrW+/9X7yt0slmzDHkkJIBDjza6mpCOBfeAhYh5thOF3LVnwYFDmcY4AQdDO1yJA7NeMTIf D8JFPD4fIIhc/yjMjw2h6ZhB9OlgA+TqXu//6/UpptfHQ15P5OZo++N4yIdwxsap7yTyuJGPY5zo 7hS6lqtuxS64FH3YZUwszu8GUJzLnJpcKi8yKhSlofdexBpttNQUE8lc1FC0/Sw4HtbMEQdQUUWy l4HnNMfZ3z5Sg3xIX9mISFcvO54TGA5sXT5eLyFh3NODm6pLDItoff4kkXyZTpyT0t4qK4/IwbGu PXAp1bZBHEQy8dphqvMsmDDYbhz9dCcq9Ci/cHZ5zdo7OEM/grN9rXYYX2+FAwmou+x6koS8ibCI Mm08XA20sdwU8yeJHO/o4hZRmANb7Y7bZIll7Dghen/VpSR1BvM6fxyCXJKsm8FWAUdOf890r6lZ vFHc/thLfni5dkKwiDHWFggROov1sItKTSxe9GJZ9UCgiyidmfOjYWna4rF8yQId5mVBTAbcIVZX 4cAgNrcck20dzoMreYhqgHZxwIq5N4/Q/DgVP0lH9d8w+Ekm47eiaAM0Kw8gdBq6Km0PCqcDLWsn JauKNq+NJp6fIHJKoQGOYlPIAPtYyR24M9siSh0OOCxSyIGgo/mhML4N6mRJHq5GMohvcvdoMv5j gvq/mIwLJuOaknKjbfTICAkP42XqztxA95W6ZM9GH+jzC65nNBOUYCweGFbbJVZSrSZOnYIycpYi TZwVb1rP16XXc7AXukrYZUvznkn/A4v3egLKLgAA --=_mixed 0045797FC12573F4_=-- -- to unsubscribe send a message to namedroppers-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 Feb 19 12:59: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 23FCB3A6BA8; Tue, 19 Feb 2008 12:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=-1.932, 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 HpSzGy2u1D2R; Tue, 19 Feb 2008 12:59:32 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17BF23A68E4; Tue, 19 Feb 2008 12:59:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRZPp-000Jof-UP for namedroppers-data@psg.com; Tue, 19 Feb 2008 20:50:13 +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 1JRZPm-000Jo2-A7 for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 20:50:12 +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 1JRZPj-0003aI-0K for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 21:50:07 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id DCFA7404B; Tue, 19 Feb 2008 21:50:09 +0100 (CET) Date: Tue, 19 Feb 2008 21:50:09 +0100 From: bert hubert To: Federico Lucifredi Cc: namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft Message-ID: <20080219205009.GB18061@outpost.ds9a.nl> References: <20080218210425.GA27088@outpost.ds9a.nl> <47BA121E.8010507@ximian.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BA121E.8010507@ximian.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Mon, Feb 18, 2008 at 06:17:50PM -0500, Federico Lucifredi wrote: > Found no substance corrections. Stylistically, I would suggest: > > - replacing the term "fake data" with something more specific. In most > cases, something akin to "doctored resource records" would do. Hmm, how about 'unoriginal data'? I see your point, but 'doctored resource records' doesn't really do it for me either. > - in 4.3, "several important documents". Suggesting the more specific > "two Best Current Practice documents". Done. > > - in 5, the first paragraph "a curious mathematical phenomenon means..." > can be rewritten as "a known probability problem, known as the birthday > paradox, describes the probability..." Tricky, how about: 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. > The document looks generally good. Nice job! Thanks Federico! 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 Feb 19 13:15: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 E978B3A6ABC; Tue, 19 Feb 2008 13:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-1.449, 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 kA-9L2aAaW7q; Tue, 19 Feb 2008 13:15:15 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1682728C759; Tue, 19 Feb 2008 13:15:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRZet-000Lzu-MY for namedroppers-data@psg.com; Tue, 19 Feb 2008 21:05:47 +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 1JRZeq-000Lz5-5i for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 21:05: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 1JRZeo-0003kL-37 for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 22:05:42 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BD0E34B476; Tue, 19 Feb 2008 22:05:44 +0100 (CET) Date: Tue, 19 Feb 2008 22:05:44 +0100 From: bert hubert To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft Message-ID: <20080219210544.GA21182@outpost.ds9a.nl> References: <20080218210425.GA27088@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 Mon, Feb 18, 2008 at 10:05:40PM +0000, Alex Bligh wrote: > pseudo-random", whereas in other places I think you mean "arbitrary". > For a trivial example, "random authoritative nameserver" in 1.1, but > more perniciously "pick a random port" in the second para of 4.4 should be, > I think, "use an arbitrary port" (whereas the next para is correct, I > think). Thanks for your keen eye on using 'random' vs 'arbitrary' - I've replaced the two occurrences you found. We are indeed a bit sloppy wrt 'random' and 'pseudo-random', but I don't think adding 'pseudo-' in many places will improve things materially. What do you think? 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 Feb 19 14:02: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 3135328C603; Tue, 19 Feb 2008 14:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtBbKVKLxp+d; Tue, 19 Feb 2008 14:02:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47DE63A6E1C; Tue, 19 Feb 2008 14:01:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRaRa-0001eu-Ng for namedroppers-data@psg.com; Tue, 19 Feb 2008 21:56:06 +0000 Received: from [69.17.117.6] (helo=mail4.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRaRV-0001ds-7f for namedroppers@ops.ietf.org; Tue, 19 Feb 2008 21:56:02 +0000 Received: (qmail 4667 invoked from network); 19 Feb 2008 21:55:59 -0000 Received: from unknown (HELO [164.99.121.186]) (federico@[130.57.22.201]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 19 Feb 2008 21:55:59 -0000 Message-ID: <47BB506E.5030401@ximian.com> Date: Tue, 19 Feb 2008 16:55:58 -0500 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft References: <20080218210425.GA27088@outpost.ds9a.nl> <47BA121E.8010507@ximian.com> <20080219205009.GB18061@outpost.ds9a.nl> In-Reply-To: <20080219205009.GB18061@outpost.ds9a.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 bert hubert wrote: > On Mon, Feb 18, 2008 at 06:17:50PM -0500, Federico Lucifredi wrote: >> Found no substance corrections. Stylistically, I would suggest: >> >> - replacing the term "fake data" with something more specific. In most >> cases, something akin to "doctored resource records" would do. > > Hmm, how about 'unoriginal data'? I see your point, but 'doctored resource > records' doesn't really do it for me either. I see what you mean. I wanted to convey that those are arbitrarily manipulated records... maybe "malicious records" ? or simply "manipulated records" ? > >> - in 4.3, "several important documents". Suggesting the more specific >> "two Best Current Practice documents". > > Done. > >> - in 5, the first paragraph "a curious mathematical phenomenon means..." >> can be rewritten as "a known probability problem, known as the birthday >> paradox, describes the probability..." > > Tricky, how about: > > 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. It is just the "means" part that is a bit odd. perhaps replacing it with "argues" ? "determines" would also work... "The so called birthday paradox argues 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." > > >> The document looks generally good. Nice job! > > Thanks Federico! Thank you! -F -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 19 18:20: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 8BBD628C19F; Tue, 19 Feb 2008 18:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PDR-RFCLGw0; Tue, 19 Feb 2008 18:20:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 384A93A6B9F; Tue, 19 Feb 2008 18:20:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JReR8-0003u7-3n for namedroppers-data@psg.com; Wed, 20 Feb 2008 02:11:54 +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 1JReR4-0003tt-Sr for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 02:11:52 +0000 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 19 Feb 2008 18:11:50 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.1.240.5; Tue, 19 Feb 2008 18:11:50 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Tue, 19 Feb 2008 18:12:18 -0800 From: Yue Luo To: bert hubert , "namedroppers@ops.ietf.org" Date: Tue, 19 Feb 2008 18:11:48 -0800 Subject: RE: notes accompanying -02 of forgery-resilience draft Thread-Topic: notes accompanying -02 of forgery-resilience draft Thread-Index: AchycnakAEXggCRPSam8nFGl48UpvAA8kd9g Message-ID: <7F2791CD3A148642AF9069A0336EDE853787E75A8E@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> References: <20080218210425.GA27088@outpost.ds9a.nl> In-Reply-To: <20080218210425.GA27088@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 I am new to DNS and would appreciate any help with my question. It seems that the draft assumes that once a record is cached it won't be ov= erwritten until it has expired. I am wondering if this is a requirement in = some RFC or a de facto custom that all implementation follows. 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, February 18, 2008 1:04 PM To: namedroppers@ops.ietf.org Subject: notes accompanying -02 of forgery-resilience draft Hi everybody, I've just posted -02 of draft-ietf-dnsext-forgery-resilience, which has received quite a bit of love and changes since -01. Until it appears on the IETF site, please use http://ds9a.nl/tmp/draft.html A summary: * Included Stub Resolvers (closing ticket 7) * Added a 'security' section * strictly made this draft apply to *implementations* that should have certain *abilities*. It is up to the operator to choose an implementation that does or does not support these abilities, and it is to the operator = to choose if or not to turn on said abilities. * added a *note* to the effect that lower TTL values in zones are easier to spoof - non-normative * typos removed * countermeasures rewritten heavily to be less specific about measures but more about results - no discussion on what 'random' means exactly, but fo= cus on 'unpredictable'. * some wording improvements (differences between resolver, nameserver etc) * document now updates 1034 instead of confusingly claiming to update eithe= r 1034 or 1035 * added reference to TSIG/IPSEC rfc's as another way to secure communications Click through http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/timeline t= o see the exct diffs. It is suggested we do a final round of critical reading with limited and focused changes before last call. Kind regards, Bert Hubert & Remco van Mook -- 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 Tue Feb 19 23: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 DE7B528C45B; Tue, 19 Feb 2008 23:42:49 -0800 (PST) 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 FmM14c2ffUPC; Tue, 19 Feb 2008 23:42:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3EE628C566; Tue, 19 Feb 2008 23:42:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRjSg-0003qh-4O for namedroppers-data@psg.com; Wed, 20 Feb 2008 07:33:50 +0000 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRjSc-0003pV-R6 for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 07:33:48 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id C315C564079; Wed, 20 Feb 2008 08:33:45 +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 14138-03; Wed, 20 Feb 2008 08:33:42 +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 D13B3564031; Wed, 20 Feb 2008 08:33:40 +0100 (CET) Message-ID: <47BBD7D3.2010707@nlnetlabs.nl> Date: Wed, 20 Feb 2008 08:33:39 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Yue Luo CC: bert hubert , "namedroppers@ops.ietf.org" Subject: Re: notes accompanying -02 of forgery-resilience draft References: <20080218210425.GA27088@outpost.ds9a.nl> <7F2791CD3A148642AF9069A0336EDE853787E75A8E@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <7F2791CD3A148642AF9069A0336EDE853787E75A8E@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.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/5890/Wed Feb 20 06:38:24 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 Yue Luo wrote: | I am new to DNS and would appreciate any help with my question. | It seems that the draft assumes that once a record is cached it won't be overwritten until it has expired. I am wondering if this is a requirement in some RFC or a de facto custom that all implementation follows. RFC 2181 section 5.4.1 describes what a server should do when considering whether to accept an RRSet in a reply, or retain an RRSet already in its cache instead. So, sometimes it will stay in the cache, sometimes be overwritten. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHu9fTkDLqNwOhpPgRAiK/AJ0WNX3RaXr/KDLFUI6gy276eJ/gPwCgpf+b 83l8a2d3bODGA53Zm4dyZWc= =Z9xw -----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 Feb 19 23:53: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 D0A7F3A68F9; Tue, 19 Feb 2008 23:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-2.199, 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 ZQ25DMa7aIwB; Tue, 19 Feb 2008 23:53:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 941583A68D2; Tue, 19 Feb 2008 23:53:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRjcK-0004ZA-Ba for namedroppers-data@psg.com; Wed, 20 Feb 2008 07:43:48 +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 1JRjc7-0004XJ-4q for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 07:43:42 +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 1JRjc2-0005La-3m; Wed, 20 Feb 2008 08:43:30 +0100 Received: from fweimer by bfk.de with local id 1JRjYb-0005Uv-WD; Wed, 20 Feb 2008 08:39:58 +0100 To: Federico Lucifredi Cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft References: <20080218210425.GA27088@outpost.ds9a.nl> <47BA121E.8010507@ximian.com> <20080219205009.GB18061@outpost.ds9a.nl> <47BB506E.5030401@ximian.com> From: Florian Weimer Date: Wed, 20 Feb 2008 08:39:57 +0100 In-Reply-To: <47BB506E.5030401@ximian.com> (Federico Lucifredi's message of "Tue, 19 Feb 2008 16:55:58 -0500") Message-ID: <82wsp0oz3m.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 * Federico Lucifredi: > "The so called birthday paradox argues 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." Oh, and isn't the magic number 23? 8-) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 20 00:08: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 8251328C731; Wed, 20 Feb 2008 00:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-1.159, 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 C-Q0OmWEcNZP; Wed, 20 Feb 2008 00:08:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9DFB28C742; Wed, 20 Feb 2008 00:08:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRjrG-0005un-6b for namedroppers-data@psg.com; Wed, 20 Feb 2008 07:59:14 +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 1JRjr9-0005tc-5m for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 07:59:09 +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 1JRjr5-00021R-LT for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 08:59:03 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 667F445F2; Wed, 20 Feb 2008 08:59:06 +0100 (CET) Date: Wed, 20 Feb 2008 08:59:06 +0100 From: bert hubert To: Florian Weimer Cc: Federico Lucifredi , namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft Message-ID: <20080220075906.GC21578@outpost.ds9a.nl> References: <20080218210425.GA27088@outpost.ds9a.nl> <47BA121E.8010507@ximian.com> <20080219205009.GB18061@outpost.ds9a.nl> <47BB506E.5030401@ximian.com> <82wsp0oz3m.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82wsp0oz3m.fsf@mid.bfk.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Wed, Feb 20, 2008 at 08:39:57AM +0100, Florian Weimer wrote: > > "The so called birthday paradox argues 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." > > Oh, and isn't the magic number 23? 8-) Correct :-) - The so called birthday paradox means that a group of 22 people suffices to have a more than even chance + The so called birthday paradox implies that a group of 23 people suffices to have a more than even chance Done. -- 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 Feb 20 00:10: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 E147E28C731; Wed, 20 Feb 2008 00:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.966, 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 wG8ddjh3Rbe9; Wed, 20 Feb 2008 00:10:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD00528C747; Wed, 20 Feb 2008 00:10:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRju3-0006E9-VY for namedroppers-data@psg.com; Wed, 20 Feb 2008 08:02: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 1JRju0-0006DQ-Jo for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 08:02:06 +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 1JRjty-00023v-Lu for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 09:02:02 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8CF1245F3; Wed, 20 Feb 2008 09:02:05 +0100 (CET) Date: Wed, 20 Feb 2008 09:02:05 +0100 From: bert hubert To: Yue Luo Cc: "namedroppers@ops.ietf.org" Subject: Re: notes accompanying -02 of forgery-resilience draft Message-ID: <20080220080205.GD21578@outpost.ds9a.nl> References: <20080218210425.GA27088@outpost.ds9a.nl> <7F2791CD3A148642AF9069A0336EDE853787E75A8E@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: <7F2791CD3A148642AF9069A0336EDE853787E75A8E@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 Tue, Feb 19, 2008 at 06:11:48PM -0800, Yue Luo wrote: > It seems that the draft assumes that once a record is cached it won't be > overwritten until it has expired. I am wondering if this is a requirement > in some RFC or a de facto custom that all implementation follows. The data can sometimes be refreshed, but it is not actively refreshed usually. If an updated copy comes in however, it is generally not ignored. 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 Feb 20 03:05: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 B121528C129; Wed, 20 Feb 2008 03:05:04 -0800 (PST) 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 nIwk4N-K5xND; Wed, 20 Feb 2008 03:05:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9D3428C132; Wed, 20 Feb 2008 03:05:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRmch-0000yy-4M for namedroppers-data@psg.com; Wed, 20 Feb 2008 10:56:23 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRmcd-0000yT-7a for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 10:56:21 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 27F12C2DA3; Wed, 20 Feb 2008 10:56:17 +0000 (GMT) Date: Wed, 20 Feb 2008 10:56:15 +0000 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: notes accompanying -02 of forgery-resilience draft Message-ID: In-Reply-To: <20080219210544.GA21182@outpost.ds9a.nl> References: <20080218210425.GA27088@outpost.ds9a.nl> <20080219210544.GA21182@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Bert, --On 19 February 2008 22:05:44 +0100 bert hubert wrote: > Thanks for your keen eye on using 'random' vs 'arbitrary' - I've replaced > the two occurrences you found. > > We are indeed a bit sloppy wrt 'random' and 'pseudo-random', but I don't > think adding 'pseudo-' in many places will improve things materially. > > What do you think? I don't think the distinction between pseudo-random and random is useful in general for this (perhaps you could even define random to include 'pseudo-random' somewhere). The fact it's used in some places and not others probably adds to confusion, as it creates a false distinction (i.e. 'the authors have said random for X, but random or pseudo-random for Y, does that mean my PRNG can't be used for X?'). The one type of reference you would want to avoid is saying something like "the random number generator should be designed so one cannot guess its output given [set of circumstances]". That is tautological as by definition one cannot guess the output of a truly random number generator under ANY set of circumstances. But even this flaw would be avoided by defining random to include "the characteristics of a pseudo-random number generator appropriate to the task described" (or similar), which leaves room for the "appropriate" to be defined by usage. 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 Wed Feb 20 07:15: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 F1F6728C1E5; Wed, 20 Feb 2008 07:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1J2N9-4B3lY; Wed, 20 Feb 2008 07:15:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A05F28C15E; Wed, 20 Feb 2008 07:15:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRqW1-0009YE-O6 for namedroppers-data@psg.com; Wed, 20 Feb 2008 15:05:45 +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 1JRqVr-0009TU-2Y for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 15:05:41 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1KF5UwB079041 for ; Wed, 20 Feb 2008 10:05:30 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200802201505.m1KF5UwB079041@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Feb 2008 10:04:26 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: DNSEXT @ IETF-71 action plan and agenda items Mime-Version: 1.0 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 Dear colleagues, For a sleeping working group we have been quite active over the last 3 months. I would like to clear out as many issues in the documents we have as possible over the next few weeks. To make the face to face meeting we are having in Philadelphia as productive as possible, I'm asking document editors to take some actions. Document editors: Please update your documents before the deadline on Monday if there are resolved issues. For unresolved issues write summary post to namedroppers to focus the discussion on the mailing list. Send in agenda requests to me, so far I have: (alphabetical) AXFR-clarify AXFR-over-UDP DNAME-bis DNS-profile dnssec-update forgery-resilience During the transition of IETF's web-site to a new contractor our new charter got lost, the charter sent out on December 26'th to IETF-Announce is still our charter not the one on the web site. Once the charter is restored I have asked for the following milestones to be listed: Feb 2008 RFC2536bis and RFC2539bis advanced to IESG. Mar 2008 DNAMEbis advanced to IESG Apr 2008 ENDS0bis advanced to IESG Jun 2008 Forgery Resilience advanced to IESG Jul 2008 AXFR-clarify advanced to IESG Dec 2008 DNS-profile advanced to IESG EDNS0 interoperabilty report: the WG needs a volunteer to write it so ENDS0 can be advanced to Draft-Standard when ENDS0bis is issued as a RFC. In my mind the following Proposed Standard documents that the WG has produced are the ones that is most urgent to update/fix/advance so I'm asking for volunteers to take on editing the following documents: RFC1995 IXFR-bis, RFC1996 NOtify-bis RFC2136 Dynamic Update-bis RFC2181 Clarify-bis RFC2308 NegCaching-bis RFC2845 TSIG-bis The (unrealistic) goal is to have these and DNS-profile all done by the end of the year. On my plate I have finishing getting Unknown RR Types/RFC3597 advanced, and resole the discusses on RFC29292bis. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 20 07:40: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 5DA0D28C16F; Wed, 20 Feb 2008 07:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=1.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, 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 NiAX9-Sb4tWx; Wed, 20 Feb 2008 07:40:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EDA528C12A; Wed, 20 Feb 2008 07:40:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRqsG-000Dlu-RP for namedroppers-data@psg.com; Wed, 20 Feb 2008 15:28:44 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRqsD-000DjD-Nf for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 15:28:43 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5865E1C00E0; Wed, 20 Feb 2008 16:28:40 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 539C01C00D8; Wed, 20 Feb 2008 16:28:40 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 46F8558ECC8; Wed, 20 Feb 2008 16:28:40 +0100 (CET) Date: Wed, 20 Feb 2008 16:28:40 +0100 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT @ IETF-71 action plan and agenda items Message-ID: <20080220152840.GA12061@nic.fr> References: <200802201505.m1KF5UwB079041@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200802201505.m1KF5UwB079041@ogud.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 Wed, Feb 20, 2008 at 10:04:26AM -0500, Ólafur Guðmundsson /DNSEXT chair wrote a message of 63 lines which said: > In my mind the following Proposed Standard documents that the WG has > produced are the ones that is most urgent to update/fix/advance so > I'm asking for volunteers to take on editing the following > documents: Does anyone maintain a list of errata/issues/obscurities for these documents somewhere? -- to unsubscribe send a message to namedroppers-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 Feb 20 09:36: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 D738028C776; Wed, 20 Feb 2008 09:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-2.118, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 ngKZmbUj3-Ns; Wed, 20 Feb 2008 09:36:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8BD528C5D1; Wed, 20 Feb 2008 09:36:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRslG-00041k-Ia for namedroppers-data@psg.com; Wed, 20 Feb 2008 17:29:38 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRslB-00040e-N6 for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 17:29:36 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2647bca751; Thr, 21 Feb 2008 01:43:21 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd747b7cea1; Sun, 17 Feb 2008 07:43:08 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sun, 17 Feb 2008 07:43:08 +0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162863A6BC3; Sat, 16 Feb 2008 15:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ06KICUcTXU; Sat, 16 Feb 2008 15:15:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062F23A6B46; Sat, 16 Feb 2008 15:15:03 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2FAB3A6ABF; Sat, 16 Feb 2008 15:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-dnsext-dnssec-rsasha256-03.txt Message-Id: <20080216231501.C2FAB3A6ABF@core3.amsl.com> Date: Sat, 16 Feb 2008 15:15:01 -0800 (PST) Cc: namedroppers@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-03.txt Pages : 9 Date : 2008-02-16 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-rsasha256-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-16150441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-rsasha256-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-16150441.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --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 Wed Feb 20 09:43: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 B8B7E28C748; Wed, 20 Feb 2008 09:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfbDslXvP9Ue; Wed, 20 Feb 2008 09:43:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A18BA28C418; Wed, 20 Feb 2008 09:43:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRsuk-0005Wi-SQ for namedroppers-data@psg.com; Wed, 20 Feb 2008 17:39:26 +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 1JRsue-0005W9-QS for namedroppers@ops.ietf.org; Wed, 20 Feb 2008 17:39:22 +0000 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 20 Feb 2008 09:39:20 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.1.240.5; Wed, 20 Feb 2008 09:39:12 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Wed, 20 Feb 2008 09:39:41 -0800 From: Yue Luo To: bert hubert CC: "namedroppers@ops.ietf.org" Date: Wed, 20 Feb 2008 09:39:10 -0800 Subject: RE: notes accompanying -02 of forgery-resilience draft Thread-Topic: notes accompanying -02 of forgery-resilience draft Thread-Index: AchzlwewSWi9CviPS8ScnPGP19160gATeVMA Message-ID: <7F2791CD3A148642AF9069A0336EDE853787E75C38@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> References: <20080218210425.GA27088@outpost.ds9a.nl> <7F2791CD3A148642AF9069A0336EDE853787E75A8E@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> <20080220080205.GD21578@outpost.ds9a.nl> In-Reply-To: <20080220080205.GD21578@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 I am thinking about an attacker manufacturing a reply similar to section 6.= 2.7 in RFC 1034 in order to attack c.isi.edu. What should the server do w= ith the c.isi.edu A record in the answer? Should the server put the record= into cache (and overwrite existing c.isi.edu A record if any)? It seems that an implementation needs to be very careful when dealing with = similar situations. Otherwise, TTL is not effective in reducing the vulner= ability window. It would be very helpful if more discussion and guideline = could be provided in the document. Thank you. Yue -----Original Message----- From: bert hubert [mailto:bert.hubert@netherlabs.nl] Sent: Wednesday, February 20, 2008 12:02 AM To: Yue Luo Cc: namedroppers@ops.ietf.org Subject: Re: notes accompanying -02 of forgery-resilience draft On Tue, Feb 19, 2008 at 06:11:48PM -0800, Yue Luo wrote: > It seems that the draft assumes that once a record is cached it won't be > overwritten until it has expired. I am wondering if this is a requirement > in some RFC or a de facto custom that all implementation follows. The data can sometimes be refreshed, but it is not actively refreshed usually. If an updated copy comes in however, it is generally not ignored. 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 Feb 21 02:28: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 1E33C28C74D; Thu, 21 Feb 2008 02:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.365 X-Spam-Level: X-Spam-Status: No, score=0.365 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, HOST_EQ_NL=1.545, 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 2oDG5fRAJh5F; Thu, 21 Feb 2008 02:28:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CF8428C611; Thu, 21 Feb 2008 02:28:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JS8Vd-000BOa-6K for namedroppers-data@psg.com; Thu, 21 Feb 2008 10:18:33 +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 1JS8VZ-000BNz-Pg for namedroppers@ops.ietf.org; Thu, 21 Feb 2008 10:18:31 +0000 Received: from [213.154.224.22] (xod.nlnetlabs.nl [213.154.224.22]) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1LAIG1S072717; Thu, 21 Feb 2008 11:18:17 +0100 (CET) (envelope-from jelte@NLnetLabs.nl) Message-ID: <47BD4FE5.1000800@NLnetLabs.nl> Date: Thu, 21 Feb 2008 11:18:13 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24gL0ROU0VYVCBjaGFpcg==?= CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT @ IETF-71 action plan and agenda items References: <200802201505.m1KF5UwB079041@ogud.com> In-Reply-To: <200802201505.m1KF5UwB079041@ogud.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig634F80C8778DC16589D72345" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 21 Feb 2008 11:18:17 +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) --------------enig634F80C8778DC16589D72345 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C3=93lafur Gu=C3=B0mundsson /DNSEXT chair wrote: >=20 > Document editors: > Please update your documents before the deadline on Monday if t= here > are resolved issues. >=20 > For unresolved issues write summary post to namedroppers to foc= us > the discussion on the mailing list. >=20 >=20 > Send in agenda requests to me, so far I have: (alphabetical) > AXFR-clarify > AXFR-over-UDP > DNAME-bis > DNS-profile > dnssec-update > forgery-resilience >=20 Well, I've submitted a new version of -rsa-sha256 last weekend. Open issues on my end are the status of the new algorithms (optional/mandatory), and I need to add a little text about nsec3 or remove the references altogether. So a 15-second slot might be nice ;) I've put up an html wdiff of -02 to -03 here by the way: http://tjeb.nl/Publications/Current_Work/draft-ietf-dnsext-dnssec-rsasha2= 56-wdiff-02-03.html Jelte --------------enig634F80C8778DC16589D72345 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 iD8DBQFHvU/o4nZCKsdOncURAiK6AJ0YL9nVq3dK/I2HoUAq1tGP4pKJ8ACeP/7+ k+USNvGl/36Ep4CcGfagVmI= =NnsK -----END PGP SIGNATURE----- --------------enig634F80C8778DC16589D72345-- -- to unsubscribe send a message to namedroppers-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 Feb 21 02:29: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 C655D28C611; Thu, 21 Feb 2008 02:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=1.467, 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 MoFZNXpl29T8; Thu, 21 Feb 2008 02:29:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBB9428C2E3; Thu, 21 Feb 2008 02:29:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JS8Xb-000Bb6-I4 for namedroppers-data@psg.com; Thu, 21 Feb 2008 10:20:35 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JS8XX-000BaK-Ef for namedroppers@ops.ietf.org; Thu, 21 Feb 2008 10:20:34 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 669931C00E1 for ; Thu, 21 Feb 2008 11:20:30 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 61E741C00D4 for ; Thu, 21 Feb 2008 11:20:30 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 5EF5958E9F2 for ; Thu, 21 Feb 2008 11:20:30 +0100 (CET) Date: Thu, 21 Feb 2008 11:20:30 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP Message-ID: <20080221102030.GA28098@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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, Nov 19, 2007 at 10:48:11AM -0500, The IESG wrote a message of 24 lines which said: > The IESG has received a request from the DNS Extensions WG (dnsext) to > consider the following document: > > - 'Domain Name System (DNS) IANA Considerations ' > as a BCP > > The IESG plans to make a decision in the next few weeks, Hmmm, did it really took more than two months for someone to raise this: https://datatracker.ietf.org/idtracker/draft-ietf-dnsext-2929bis/comment/77828/? Date and Time: 2008-02-19, 12:57:25 Document: draft-ietf-dnsext-2929bis Version: 06 Commented by: Russ Housley Comment: I am holding the discuss for IANA. The IANA considerations call for a maillist to be created at iana.org. I think we want it to be at ietf.org. Please tell me why you think the one at IANA is preferred. -- to unsubscribe send a message to namedroppers-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 Feb 21 03:56: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 A5EEF28C712; Thu, 21 Feb 2008 03:56:26 -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 tTjipuARwymK; Thu, 21 Feb 2008 03:56:25 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAAD228C46D; Thu, 21 Feb 2008 03:56:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JS9vo-000JzR-RW for namedroppers-data@psg.com; Thu, 21 Feb 2008 11:49:40 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JS9vh-000JyE-NT for namedroppers@ops.ietf.org; Thu, 21 Feb 2008 11:49:39 +0000 X-IronPort-AV: E=Sophos;i="4.25,385,1199664000"; d="scan'208";a="12886646" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 21 Feb 2008 11:49:30 +0000 In-Reply-To: <47BD4FE5.1000800@NLnetLabs.nl> To: Jelte Jansen Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT @ IETF-71 action plan and agenda items MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: roy@nominet.org.uk Date: Thu, 21 Feb 2008 11:49:29 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 21/02/2008 11:49:30 AM, Serialize complete at 21/02/2008 11:49:30 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Jelte Jansen wrote on 02/21/2008 10:18:13 AM: > Open issues on my end are the status of the new algorithms > (optional/mandatory), and I need to add a little text about nsec3 or > remove the references altogether. So a 15-second slot might be nice ;) What I would like to see is that support for RSA/SHA256 and RSA/SHA512 DNSKEY's implies support for NSEC3-SHA1, so that we do not require new aliases to use these keys with NSEC3-SHA1. 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 Fri Feb 22 08:22: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 9F70628C339; Fri, 22 Feb 2008 08:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-2.076, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 1bdqoflktPY6; Fri, 22 Feb 2008 08:22:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1FFE28CBF8; Fri, 22 Feb 2008 08:20:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSaSl-000FAb-7n for namedroppers-data@psg.com; Fri, 22 Feb 2008 16:09:27 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSaSe-000F9S-II for namedroppers@ops.ietf.org; Fri, 22 Feb 2008 16:09:22 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jma347bf4a56; Sat, 23 Feb 2008 00:23:09 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb47ba1946; Tue, 19 Feb 2008 06:22:14 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 19 Feb 2008 06:22:13 +0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B723A6D20; Mon, 18 Feb 2008 13:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-EQ1fTTOj7p; Mon, 18 Feb 2008 13:00:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747F128C0D0; Mon, 18 Feb 2008 13:00:03 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AB0E13A6876; Mon, 18 Feb 2008 13:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt Message-Id: <20080218210001.AB0E13A6876@core3.amsl.com> Date: Mon, 18 Feb 2008 13:00:01 -0800 (PST) Cc: namedroppers@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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-02.txt Pages : 21 Date : 2008-02-18 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-forgery-resilience-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-18125037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-forgery-resilience-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18125037.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --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 Fri Feb 22 09:23: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 B0C3928C38C; Fri, 22 Feb 2008 09:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 620gjDfeJXUq; Fri, 22 Feb 2008 09:23:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B441328C10C; Fri, 22 Feb 2008 09:23:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSbUL-000OZi-Di for namedroppers-data@psg.com; Fri, 22 Feb 2008 17:15:09 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSbUB-000OWQ-1B for namedroppers@ops.ietf.org; Fri, 22 Feb 2008 17:15:03 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 8F68528C30F; Fri, 22 Feb 2008 09:15:01 -0800 (PST) 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-10.txt Message-Id: <20080222171501.8F68528C30F@core3.amsl.com> Date: Fri, 22 Feb 2008 09:15:01 -0800 (PST) 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-10.txt Pages : 16 Date : 2008-02-22 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2672bis-dname-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-22091412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-22091412.I-D\@ietf.org> --OtherAccess-- --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 Sun Feb 24 21:43: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 3435C3A6B98; Sun, 24 Feb 2008 21:43:26 -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 c4sLEp9ZSZVK; Sun, 24 Feb 2008 21:43:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3D3C3A697D; Sun, 24 Feb 2008 21:43:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTVvs-000KVp-Eh for namedroppers-data@psg.com; Mon, 25 Feb 2008 05:31:20 +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 1JTVvp-000KVZ-HE for namedroppers@ops.ietf.org; Mon, 25 Feb 2008 05:31:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8177611433; Mon, 25 Feb 2008 05:31:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Markku Savela cc: namedroppers@ops.ietf.org Subject: Re: EDNS0 (RFC-2671) questions In-Reply-To: Your message of "Thu, 18 Mar 2004 15:25:36 +0200." <200403181325.i2IDPake015440@burp.tkv.asdf.org> References: <200403181325.i2IDPake015440@burp.tkv.asdf.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 25 Feb 2008 05:31:16 +0000 Message-ID: <73738.1203917476@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion sorry for the late reply. > Date: Thu, 18 Mar 2004 15:25:36 +0200 > From: Markku Savela > To: namedroppers@ops.ietf.org > Subject: EDNS0 (RFC-2671) questions > Sender: owner-namedroppers@ops.ietf.org > > 1) assuming I send query, which includes the OPT RR (to increase the > packet length). If I receive a reply with TC=1 (truncation) and > don't find OPT RR in the reply, then I assume the RCODE is the > non-extended one? yes. > [Just verifying, that I can trust all implementations do it right: > if they build an answer and run out of space before inserting the > OPT RR, they also fall back to old plain RCODE?] i don't know if all implementations do this right. but your interpretation is correct, in the opinion of the author. i will add the following text to EDNS0-bis to cover this case. .LP 5.4. If EDNS is used in a request, and the response arrives with TC set and with no EDNS OPT RR, a requestor should assume that truncation prevented the OPT RR from being appended by the responder, and further, that EDNS is not used in the response. Correspondingly, an EDNS responder who cannot fit all necessary elements (including an OPT RR) into a response, should respond with a normal (unextended) DNS response, possibly setting TC if the response will not fit in the unextended response message's 512-octet size. > This extended-RCODE makes it somewhat akward, to find RCODE, you have > to traverse through all data in Question, Answer and Authority > sections, then look OPT RR from Additional section. Doable, but still > icky, just to get few extra bits of RCODE that are rarely used. Would > have been easier if there was single RCODE value in fixed header to > indicate that extended RCODE is in use. yes, it would have been better, you're right. > 2) Can UDP payload size be < 512? > > I didn't see any mention of it. Maybe I missed it. I think RFC should > state that attempting to use less than 512 is not allowed (and will be > ignored). [If < 512 is accepted, there might be some DOS potential in > it also] agreed. i've added two sentences to EDNS0-bis to cover this case. .LP 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS field) is the number of octets of the largest UDP payload that can be reassembled and delivered in the sender's network stack. Note that path MTU, with or without fragmentation, may be smaller than this. Values lower than 512 are undefined, and may be treated as format errors, or may be treated as equal to 512, at the implementor's discretion. thank you VERY much for your review, your observations, and your suggestions. -- to unsubscribe send a message to namedroppers-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 Feb 24 21: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 904C53A6CA4; Sun, 24 Feb 2008 21:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ+-pUvTHGwY; Sun, 24 Feb 2008 21:53:15 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D98228C0FF; Sun, 24 Feb 2008 21:53:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTWBa-000Lnb-Js for namedroppers-data@psg.com; Mon, 25 Feb 2008 05:47:34 +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 1JTW8g-000LYg-43 for namedroppers@ops.ietf.org; Mon, 25 Feb 2008 05:46:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D15331142F; Mon, 25 Feb 2008 05:44:31 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Alfred =?hp-roman8?B?SM5uZXM=?= cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rfc2671bis-edns0-00 (fwd) In-Reply-To: Your message of "Tue, 01 Jan 2008 09:06:59 +0100." <200801010807.JAA25219@TR-Sys.de> References: <200801010807.JAA25219@TR-Sys.de> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2008 05:44:31 +0000 Message-ID: <74306.1203918271@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion thanks again for this. all of your recommendations will appear in edns0bis= -00. re: > From: Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D > Subject: draft-ietf-dnsext-rfc2671bis-edns0-00 (fwd) > To: namedroppers@ops.ietf.org > Date: Tue, 1 Jan 2008 09:06:59 +0100 (MEZ) > X-Mailer: ELM [$Revision: 1.17.214.3 $] > Sender: owner-namedroppers@ops.ietf.org >=20 > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K.=20=20 > With the massive amount of spam, it is easy to miss and therefore=20 > delete relevant posts by non-subscribers.=20 > Please fix your subscription addresses. ] >=20 > ----- Forwarded message from Alfred H=CEnes ----- >=20 > From A.Hoenes@TR-Sys.de Sat Dec 29 15:53:25 MEZ 2007 > Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/= 16.3) > id AA190880004; Sat, 29 Dec 2007 15:53:24 +0100 > Return-Path: > Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) > id PAA20672; Sat, 29 Dec 2007 15:53:23 +0100 (MEZ) > From: Alfred H=CEnes > To: vixie@isc.org > Message-Id: <200712291453.PAA20672@TR-Sys.de> > Date: Sat, 29 Dec 2007 15:53:22 +0100 (MEZ) > Subject: draft-ietf-dnsext-rfc2671bis-edns0-00 >=20 > Hello, > after studying the recently published Internet-Draft authored by you, > draft-ietf-dnsext-rfc2671bis-edns0-00, > I'd like to submit a few comments. >=20 > The items below are presented in textual order. > Occasionally, to give more context, I quote larger blocks of > text literally and show the replacement proposed using the > shorthand notation: >=20 > > --- > >=20 > I also sometimes use change bars ('|' in column 1) and up/down > pointing marker lines ('^^^'/'vvv') to emphasize the location > of textual issues, proposed corrections, or new text. > Modified or proposed new text has been (re-)adjusted to match > RFC formatting rules, where appropriate. > I also try to accomodate published RFC-Ed policy on style and > punctuation etc. in my proposals. >=20 >=20 > (1) Document Metadata and purpose >=20 > The draft name seems to indicate that this draft is intended as > a replacement for RFC 2671, but that is not stated explicitely. >=20 > Also, other parts of the draft look like a hybrid of an update to, > and a full replacement for, RFC 2671. I strongly recommend to > build an unambiguous, self-contained replacement that will fully > obsolete RFC 2671. All other solutions would certainly be a > never ending source of confusion. >=20 > (BTW: RFC 2821 once has incorporated the SMTP extension mechanism, > ESMTP, into the updated SMTP specifiation, and the 2821bis draft > continues this way. > This conforms to the protocol design principle accepted in the > IETF, that the basic specification of a protocol that is envisioned > to be extended in various ways should always already describe and > standardize the purposely crafted extensibility mechanisms needed > to this end, to ensure interoperability with future extensions. > Thus, it certainly would be very useful to incorporate the EDNS > mechanism into an updated basic DNS protocol specification (which > would be welcome for many more reasons anyway), but such effort is > probably far out of scope currently.) >=20 > I suggest to add (in common style) to the document heading: >=20 > | Intended Status: Standards Track > | Obsoletes: 2671 (if approved) >=20 >=20 > (2) Section 1 >=20 > In line with item (1) above, I suggest to add a paragraph to > Section 1 (e.g., at the beginning of 1.2.) that introduces RFC 2671 > and clarifies the relationship of this draft to it, for instance: >=20 > 1.2. > | [RFC2671] originally has proposed extensions to the basic DNS > | protocol to overcome these deficiencies. This memo refines that > | specification and obsoletes RFC 2671. >=20 > Unextended agents ... >=20 >=20 > (3) Section 2 and Section 3 >=20 > IMHO, the draft is not explicit enough in stating its role in > specifying the extensions / affected protocol elements. >=20 > Also, as I understand the structure of the draft, Section 2 is > intended as descriptive text, and the subsequent sections contain > the normative text. >=20 > I suggest to add, at the end of Section 2.1, a statement indicating > the action performed by this memo, for instance: >=20 > | The OPT pseudo-RR specified in Section 4 contains subfields that > | carry a bit field extension of the RCODE field and additional flag > | bits, respectively; for details see Section 4.6 below. >=20 > W.r.t. Section 2.2, Section 7 contains the statement: > This document assigns label type 0b01xxxxxx as "EDNS Extended Label > Type." We request that IANA record this assignment. >=20 > Hence, in Section 2.2 it should be made explicit that this memo > reinforces the allocation made in Section 3 of RFC 2671. >=20 > Preferably, the text in Section 3 should only contain precise > normative content. The current text in Section 3 is only a review > of the legacy, which should be appended to (or merged into) the > current text of Section 2.2. This should be followed by a short > preview/description of what this memo does w.r.t. label types. > For instance, add to the end of 2.2: >=20 > | Section 3 of this document reserves DNS labels with a first octet > | in the range of 64-127 decimal (label type 01) for future > | standardization of Extended DNS Labels. >=20 > Similarly, in Section 2.3 the action of the memo should be made > explicit. For instance, add to the end of 2.3: >=20 > | To this end, the OPT pseudo-RR specified in Section 4 contains a > | maximum payload size field; for details see Section 4.5 below. >=20 >=20 > (4) Section 3 >=20 > As stated above, I strongly recommend to only place normative text > (and/or 'meta-normative' text, if you like) into Section 3. > This text should be self-contained; the reader should not need the > descriptive/informative sections to understand/implement the > specification. >=20 > For instance, the new text for Section 3 could be: >=20 > | The first octet in the on-the-wire representation of a DNS label > | specifies the label type; the basic DNS specification [RFC1035] > | dedicates the two most significant bits of that octet for this > | purpose. > | > | This document reserves DNS label type 0b01 for use as an indication > | for Extended Label Types. A specific extended label type is selected > | by the 6 least significant bits of the first octet. Thus, Extended > | Label Types are indicated by the values 64-127 (0b01xxxxxx) in the > | first octet of the label. > | > | Allocations from this range are to be made for IETF documents fully > | describing the syntax and semantics as well as the applicability of > | the particular Extended Label Type. > | > | This document does not describe any specific Extended Label Type. >=20 > Note: > Some details, like the word 'reserves' in the second paragraph above > (vs. 'allocates'), and the allocation policy indicated in the 3rd > paragraph, will need to be discussed. >=20 >=20 > (5) Section 4.3 >=20 > To improve the readability of the specification, I strongly recommend to > explicitely state the numeical value of the RR type already allocated > for the OPT pseudo-RR. >=20 > Thus, please change: >=20 > Field Name Field Type Description > ------------------------------------------------------ > NAME domain name empty (root domain) > | TYPE u_int16_t OPT > [...] > --- > Field Name Field Type Description > ------------------------------------------------------ > NAME domain name empty (root domain) > | TYPE u_int16_t OPT (41) > [...] > ^^^^^ >=20 > (6) Section 4.4 >=20 > In the artwork in Section 4.4, there are no single-octet fields; > Thus, the headline indicating byte offsets should be improved upon > for added clarity. I suggest to change: >=20 > +0 (MSB) +1 (LSB) > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > 0: | [...] > --- v v v > | : +0 (MSB) : +1 (LSB) : > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > 0: | [...] >=20 >=20 >=20 > (7) Section 4.6 >=20 > Note: > This change recommended in item (6) above is not needed so much > for the artwork in Section 4.6, but for the sake of uniformity, > it might be applied there as well. >=20 > I suggest to *not* quote the decimal representation of numerical field > values in the text, to distinguish these from literal text constants. > (The text also is inconsistent in using <"> and <''> for this purpose.) > Thereby, the single occurrence of a violaton of 'rational quoting' > in the text will be nullified as well. >=20 > Thus, I suggest to change: >=20 > EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note > | that EXTENDED-RCODE value "0" indicates that an > ^ ^ v v v v > | unextended RCODE is in use (values "0" through "15"). > --- > EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note > | that EXTENDED-RCODE value 0 indicates that an > | unextended RCODE is in use (values 0 through 15). >=20 > and: >=20 > VERSION Indicates the implementation level of whoever sets it. > Full conformance with this specification is indicated > | by version ``0.'' Requestors are encouraged to set > ^^ ^^^ > this to the lowest implemented level capable of > expressing a transaction, [...] > --- > VERSION Indicates the implementation level of whoever sets it. > Full conformance with this specification is indicated > | by version 0. Requestors are encouraged to set this > to the lowest implemented level capable of expressing > a transaction, [...] >=20 >=20 > (8) Section 7 >=20 > Neither RFC 2929 nor I-D 2929bis cover the EDNS sub-registries > rooted in RFC 2671: >=20 > "EDNS Extended Label Type" > "EDNS Option Codes" > "EDNS Version Numbers" >=20 > Thus, the draft should advise IANA to 're-parent' those sub-registries > to this memo, and it should contain full IANA considerations for all > three sub-registries, including allocation policy statements, > in conformance with BCP 26, RFC 2424. >=20 > Also, I recommend to more clearly and uniformly state the specific > sub-registry addressed in all allocation statements, for the ease of > readers less experienced with DNS details (including IANA staff). >=20 >=20 > (9) Section 9 >=20 > I suggest to use the common punctuation style, in conformance with > contemporary RFC author guides. >=20 > For instance, change: >=20 > | [RFC1035] P. Mockapetris, ``Domain Names - Implementation and > | Specification,'' RFC 1035, USC/Information Sciences > | Institute, November 1987. > --- > | [RFC1035] P. Mockapetris, "Domain Names - Implementation and > | Specification", STD 13, RFC 1035, November 1987. >=20 >=20 > | [RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate > | Requirement Levels,'' RFC 2119, Harvard University, March > 1997. > --- > | [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate > | Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > etc. ... >=20 >=20 > Best regards, > and my best wishes for the New Year, > Alfred H=CEnes. >=20 > -- >=20 > +------------------------+--------------------------------------------+ > | 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 | > +------------------------+--------------------------------------------+ >=20 >=20 > ----- End of forwarded message from Alfred H=CEnes ----- >=20 >=20 > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 25 12:00: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 34F9728CBD5; Mon, 25 Feb 2008 12:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCvnHvL1I4qT; Mon, 25 Feb 2008 12:00:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1D9C3A6E0C; Mon, 25 Feb 2008 11:54:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTjF3-000JYV-7f for namedroppers-data@psg.com; Mon, 25 Feb 2008 19:44:01 +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 1JTjF0-000JY3-8c for namedroppers@ops.ietf.org; Mon, 25 Feb 2008 19:43:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C857E11436 for ; Mon, 25 Feb 2008 19:43:57 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: edns0-bis submitted X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 25 Feb 2008 19:43:57 +0000 Message-ID: <12278.1203968637@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion the -00 draft was submitted to internet-drafts@ietf.org last night but has not shown up yet (presumably the secretariat is busy). a courtesy copy can be read at http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt -- to unsubscribe send a message to namedroppers-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 Feb 25 12:13: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 64ED928C7CD; Mon, 25 Feb 2008 12:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-0.383, 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 DCPXxLcN35IN; Mon, 25 Feb 2008 12:13:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE21628CA41; Mon, 25 Feb 2008 12:07:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTjTf-000Lis-9q for namedroppers-data@psg.com; Mon, 25 Feb 2008 19:59:07 +0000 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTjTc-000LiN-Ko for namedroppers@ops.ietf.org; Mon, 25 Feb 2008 19:59:06 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m1PJwvgk013579; Mon, 25 Feb 2008 13:58:57 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m1PJwuOb012053; Mon, 25 Feb 2008 13:58:57 -0600 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Feb 2008 14:58:55 -0500 Date: Mon, 25 Feb 2008 14:58:53 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@localhost.localdomain To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair cc: ietf@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP In-Reply-To: <200712192303.lBJN3RK5021391@ogud.com> Message-ID: References: <200712192303.lBJN3RK5021391@ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Feb 2008 19:58:56.0158 (UTC) FILETIME=[DA799BE0:01C877E8] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 25 Feb 2008 13:58:58 -0600 (CST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion >> This draft does not address at least one issue raised in WGLC. It also >> contains substantial changes made after the close of WGLC that have >> received too little attention from the WG. Accordingly, I continue to >> oppose publication of this document[1]. I suggest that the IESG refer it >> back to the WG and, once a new document is advanced, issue a new IETF last >> call. > > Sam, > most of the changes are results of the allocation experiment that was > conducted. The working group was fully aware of them and the changes made to > the document see: > http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html While it may well the be case that MOST of the changes resulted from the experiment and were called out to the WG, the change I cited (re: creating IANA registries using templates) was neither a result of the experiment (having been made before the experiment), nor called out. As for the WG being "fully aware" of the changes resulting from the experiment, I note that between the end of WGLC in November 2006 and the start of IETF last call a year later (which included the time of the experiment), the namedroppers list appears to have seen fourteen posts about 2929bis. The post-experiment discussion of these changes was minimal at best. >> And an example of one of the changes that I think has received too little >> review: >> >> The document allows templates to create IANA registries. Is that >> altogether desirable? Has the expert been given enough guidance to review >> such requests? > > This is an excellent IETF wide question it is outside the DNSEXT > WG expertize to judge this issue. > At this point there is no specific guidance to the expert(s) on > what to do in this case. I'm glad you agree that it is an excellent question. I suspect it's one of the things IANA plans to weigh in on. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 26 09:53: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 815C83A68B5; Tue, 26 Feb 2008 09:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Ucqk8niyZz; Tue, 26 Feb 2008 09:53:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D00143A6BE5; Tue, 26 Feb 2008 09:53:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JU3pp-000No4-SQ for namedroppers-data@psg.com; Tue, 26 Feb 2008 17:43:21 +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 1JU3ph-000NnS-SA for namedroppers@ops.ietf.org; Tue, 26 Feb 2008 17:43:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9F39411437; Tue, 26 Feb 2008 17:43:12 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org cc: dagon@cc.gatech.edu Subject: dns-0x20.txt X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 26 Feb 2008 17:43:12 +0000 Message-ID: <69903.1204047792@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion 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: From owner-namedroppers@ops.ietf.org Tue Feb 26 10:56: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 E1C6B3A6BDD; Tue, 26 Feb 2008 10:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucAVfCXFDyCs; Tue, 26 Feb 2008 10:56:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DEB73A67CC; Tue, 26 Feb 2008 10:56:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JU4sX-0007Ds-FW for namedroppers-data@psg.com; Tue, 26 Feb 2008 18:50:13 +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 1JU4sL-0007CP-NC for namedroppers@ops.ietf.org; Tue, 26 Feb 2008 18:50:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1430711434; Tue, 26 Feb 2008 18:50:01 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie to: namedroppers@ops.ietf.org cc: dagon@cc.gatech.edu Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Tue, 26 Feb 2008 17:43:12 GMT." <69903.1204047792@sa.vix.com> References: <69903.1204047792@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 26 Feb 2008 18:50:01 +0000 Message-ID: <72809.1204051801@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion someone asked, why didn't we make this more general, and include the relationship between stub (libc) resolvers and full (caching) resolvers. the reason is, that relationship more often than not has a hotel middlebox, and we have no expectation that the question section in the response will be a copy of the one in the request, and any attempt to use the 0x20 bits in the question section as a covert channel from the stub resolver to itself via the full resolver, would have to have a fallback plan. the fallback plan would be subject to downgrade attacks (similar to the cookie approach that's been elsewhere proposed) and is thus not worth pursuing. we are however at a shining moment in history with there are no authority servers within range of my dns requests who do other than a bit for bit copy of the question section, and thus, the proposal focuses on the relationship between full (caching) resolvers and authority servers, where deployment is safe and sane and can begin immediately, in parallel with the spec updates. -- to unsubscribe send a message to namedroppers-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 Feb 26 11: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 53BD828C517; Tue, 26 Feb 2008 11:11:13 -0800 (PST) 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 Y9+WjjOYFrWo; Tue, 26 Feb 2008 11:11:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43BFC28C2FF; Tue, 26 Feb 2008 11:11:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JU58T-0009Sd-1F for namedroppers-data@psg.com; Tue, 26 Feb 2008 19:06:41 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JU58R-0009SN-R0 for namedroppers@ops.ietf.org; Tue, 26 Feb 2008 19:06:40 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 4A145D6C02; Tue, 26 Feb 2008 19:06:38 +0000 (GMT) Date: Tue, 26 Feb 2008 19:06:37 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: dagon@cc.gatech.edu, Alex Bligh Subject: Re: dns-0x20.txt Message-ID: <1F495D52645E117797B3885C@Ximines.local> In-Reply-To: <69903.1204047792@sa.vix.com> References: <69903.1204047792@sa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion --On 26 February 2008 17:43:12 +0000 Paul Vixie wrote: > for more, go to . Very clever. 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 Feb 26 20:36: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 122243A6D79; Tue, 26 Feb 2008 20:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu2Z0MVQaQBg; Tue, 26 Feb 2008 20:36:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94DFB3A6A04; Tue, 26 Feb 2008 20:36:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUDtt-000FWn-3s for namedroppers-data@psg.com; Wed, 27 Feb 2008 04:28:13 +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 1JUDtp-000FWL-Lc for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 04:28:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0BBC11142F for ; Wed, 27 Feb 2008 04:28:09 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: i'm thinking that EDNS0-bis is just not very sexy X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Feb 2008 04:28:09 +0000 Message-ID: <96993.1204086489@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion so far 9 people have fetched the EDNS0-bis draft, whereas 74 people have fetched the DNS-0x20 draft. does this indicate a lack of interest in clarifying EDNS0? or that if we want EDNS0 reviewed, we should hire a consultant? those url's again are: http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt http://sa.vix.com/~vixie/dns-0x20.txt -- to unsubscribe send a message to namedroppers-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 Feb 26 21:44: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 4785D28C2CA; Tue, 26 Feb 2008 21:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=0.428, 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 DLUBgLlKNb8Q; Tue, 26 Feb 2008 21:44:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1B1928C253; Tue, 26 Feb 2008 21:44:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUEzZ-000N0K-TP for namedroppers-data@psg.com; Wed, 27 Feb 2008 05:38:09 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUEzX-000Mzt-AH for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 05:38:08 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JUEzW-0000eR-0A; Wed, 27 Feb 2008 00:38:06 -0500 Message-ID: <47C4F733.7050001@ca.afilias.info> Date: Wed, 27 Feb 2008 00:37:55 -0500 From: Brian Dickson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: i'm thinking that EDNS0-bis is just not very sexy References: <96993.1204086489@sa.vix.com> In-Reply-To: <96993.1204086489@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: > so far 9 people have fetched the EDNS0-bis draft, > whereas 74 people have fetched the DNS-0x20 draft. > > does this indicate a lack of interest in clarifying > EDNS0? or that if we want EDNS0 reviewed, we should > hire a consultant? > Neither, I think. Rather, it reflects well on the thought that went into the document and the prior input, with high expectations on the quality and relevance of the resulting draft. When you expect something to be bad, you sniff it. But not when you expect it to be fine. (Perverse, but true. Bad milk, spoiled meat, moldy cheese, anything written by d**n **nder**n.) I have reviewed the -bis draft, and see nothing wrong with it. I am in favor of moving it forward to whatever the next step is towards publication as an RFC. 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 Tue Feb 26 21:54: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 B753E3A6989; Tue, 26 Feb 2008 21:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=1.008, 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 d7I0xTgpX7QV; Tue, 26 Feb 2008 21:54:54 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39CEC3A6D6B; Tue, 26 Feb 2008 21:54:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUFC4-000OGd-VE for namedroppers-data@psg.com; Wed, 27 Feb 2008 05:51:04 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUFC2-000OGE-6A for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 05:51:03 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2008 06:51:01 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1R5p0aC007606; Wed, 27 Feb 2008 06:51:01 +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.12.10/8.12.6) with ESMTP id m1R5osME008506; Wed, 27 Feb 2008 05:50:56 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, 27 Feb 2008 06:50:53 +0100 Received: from [172.16.3.85] ([10.61.64.205]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 06:50:53 +0100 Cc: namedroppers@ops.ietf.org Message-Id: <510BA825-74B5-43DD-8054-771394A58234@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Vixie In-Reply-To: <96993.1204086489@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: i'm thinking that EDNS0-bis is just not very sexy Date: Wed, 27 Feb 2008 06:50:50 +0100 References: <96993.1204086489@sa.vix.com> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 27 Feb 2008 05:50:53.0477 (UTC) FILETIME=[B6DC2550:01C87904] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=331; t=1204091461; x=1204955461; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20i'm=20thinking=20that=20EDNS0-bis=20is= 20just=20not=20very=20sexy |Sender:=20; bh=4bKjr5Ss6B1GqmZUmSIGsPis7tdwc+1UZHbhDk4VIGs=; b=ilSbgYqkwgAD+4dDXTV7ABtuNdfmtAnsTZ5JLjFlVsF+D+/26ivKlNjm3Y HwSLDpJRwQ3I5js7b75b52uLFhhRvIprvfQAd3ncll6jHoH/McBrxPgAUGnH cC3BVfxjLJ; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 27 feb 2008, at 05.28, Paul Vixie wrote: > so far 9 people have fetched the EDNS0-bis draft, I think this document is good, and support it. I have specifically looked at sections 4.5.3, 4.5.4 and 5.4 as the "bootstrap" issues have been the ones that have created issues for me. This is much better. 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 Tue Feb 26 22:13: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 ED9B53A6A04; Tue, 26 Feb 2008 22:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-1.972, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RohQbr-vIu1z; Tue, 26 Feb 2008 22:13:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5DD128C376; Tue, 26 Feb 2008 22:13:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUFTH-0000Gu-JN for namedroppers-data@psg.com; Wed, 27 Feb 2008 06:08:51 +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 1JUFTE-0000GY-LL for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 06:08:50 +0000 Received: from [192.168.101.143] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1R68dfx062732; Wed, 27 Feb 2008 01:08:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <96993.1204086489@sa.vix.com> References: <96993.1204086489@sa.vix.com> Date: Wed, 27 Feb 2008 14:07:30 +0800 To: Paul Vixie From: Edward Lewis Subject: Re: i'm thinking that EDNS0-bis is just not very sexy 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 4:28 +0000 2/27/08, Paul Vixie wrote: >so far 9 people have fetched the EDNS0-bis draft, >whereas 74 people have fetched the DNS-0x20 draft. > >does this indicate a lack of interest in clarifying >EDNS0? or that if we want EDNS0 reviewed, we should >hire a consultant? I find that, as an editor, you have to really push for discussion on a document. I hadn't been aware of the EDNS0-bis. Mostly because my "day job" is busier and the IETF has become background noise. (That's why I said the previous AXFR doc wouldn't be updated until after the IETF meeting. BTW - Thanks to those who sent off-list comments, I've been too busy to reply. I will get back to the AXFR issue, but just not now.) > >those url's again are: > >http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt >http://sa.vix.com/~vixie/dns-0x20.txt Are either on the IETF site? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Feb 26 22:51: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 8D4DA28C4CD; Tue, 26 Feb 2008 22:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRCLwqzlz7TH; Tue, 26 Feb 2008 22:51:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E65A28C4B9; Tue, 26 Feb 2008 22:51:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUG22-00046z-UV for namedroppers-data@psg.com; Wed, 27 Feb 2008 06:44: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 1JUG1s-00045B-12 for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 06:44:37 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 562AC1142F for ; Wed, 27 Feb 2008 06:44:35 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: i'm thinking that EDNS0-bis is just not very sexy In-Reply-To: Your message of "Wed, 27 Feb 2008 14:07:30 +0800." References: <96993.1204086489@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Feb 2008 06:44:35 +0000 Message-ID: <3047.1204094675@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > >those url's again are: > > > >http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt > >http://sa.vix.com/~vixie/dns-0x20.txt > > Are either on the IETF site? the first was submitted before the -00 cutoff, but has not appeared. indeed i have heard no ack, no nak, nothing from the secretariat. i cc'd olafur as wg chair so that he would know when it was submitted ("i have witnesses"). the second was not submitted, since it was finished after the -00 cutoff date, but i think it's topical, and timely, and ought to be discussed, in philly. -- to unsubscribe send a message to namedroppers-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 Feb 26 23:20:31 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 62B223A6D70; Tue, 26 Feb 2008 23:20:31 -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 X51uhyf8vJY1; Tue, 26 Feb 2008 23:20:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 10E8A3A6954; Tue, 26 Feb 2008 23:20:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUGV4-00092E-SY for namedroppers-data@psg.com; Wed, 27 Feb 2008 07:14:46 +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 1JUGV1-00091s-W4 for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 07:14:45 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=first1; 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=blLdFk4pEm4QeMnp4YYZvIHsnf2P1Gp5d2mNsHLbgFj5nF0nwT1D37ufGGXcOtLBjLPBz69jvea3omBhq/11PuCjcOKX64BQnXeLDxRYfOrEauYfh3HgELXkN5oD89HGFRDVab9VnCHM5mJx4vSKjpVXZEjoqv/CLf5qPuJjcU8=; Received: by smtp.spodhuis.org with local id 1JUGV0-000K6m-DQ; Wed, 27 Feb 2008 07:14:42 +0000 Date: Tue, 26 Feb 2008 23:14:42 -0800 From: Phil Pennock To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: i'm thinking that EDNS0-bis is just not very sexy Message-ID: <20080227071442.GA77169@redoubt.spodhuis.org> Mail-Followup-To: Paul Vixie , namedroppers@ops.ietf.org References: <96993.1204086489@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96993.1204086489@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 2008-02-27 at 04:28 +0000, Paul Vixie wrote: > http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt Apologies if this was covered, but I've checked archives and not found mention of this. What happened to the extended label type reservation of 0bxx111111 ? If this is no longer reserved, shouldn't that withdrawal be noted in the IANA considerations? Regards, -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 Wed Feb 27 01:15: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 74ABD3A6781; Wed, 27 Feb 2008 01:15:45 -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 N-Uofb3PFvrp; Wed, 27 Feb 2008 01:15:44 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2FE23A6DF4; Wed, 27 Feb 2008 01:15:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUIG1-000Js1-7Q for namedroppers-data@psg.com; Wed, 27 Feb 2008 09:07:21 +0000 Received: from [2001:7b8:206:1:216:76ff:feb8:3c02] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUIFp-000JqY-T3 for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 09:07:11 +0000 Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1R96rfE046001 for ; Wed, 27 Feb 2008 10:06:53 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200802270906.m1R96rfE046001@bartok.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: Re: i'm thinking that EDNS0-bis is just not very sexy In-reply-to: Your message of Wed, 27 Feb 2008 04:28:09 +0000. <96993.1204086489@sa.vix.com> Date: Wed, 27 Feb 2008 10:06:53 +0100 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 27 Feb 2008 10:06:53 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion so far 9 people have fetched the EDNS0-bis draft, whereas 74 people have fetched the DNS-0x20 draft. The draft made the cut-off, so the numbers are incomparable. jaap -- to unsubscribe send a message to namedroppers-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 Feb 27 06:59: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 706D03A6862; Wed, 27 Feb 2008 06:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, 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 Af-DPOZCkcws; Wed, 27 Feb 2008 06:59:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E10128C6A7; Wed, 27 Feb 2008 06:58:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUNSM-0007gG-OF for namedroppers-data@psg.com; Wed, 27 Feb 2008 14:40:26 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUNRU-0007Yn-5A for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 14:39:49 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id B61517C8E3; Wed, 27 Feb 2008 14:39:29 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id AFE8D7616A; Wed, 27 Feb 2008 16:39:28 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18373.30240.362882.927915@guava.gson.org> Date: Wed, 27 Feb 2008 16:39:28 +0200 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: <69903.1204047792@sa.vix.com> References: <69903.1204047792@sa.vix.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul Vixie wrote: > 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. "Citation needed". Although there have certainly been many publicized cases of cache pollution over the years, I'm not aware of a single case where that pollution was shown to have resulted from an ID guessing attack. Demonstrations of vulnerability, yes, but not actual attacks. If you know of any documented cases, please share them. > 4.3. Much effort has been expended in trying to make the DNS transaction > ID more random and less predictable. Ultimately such efforts are > hopeless since with only 16 bits to fight over, a determined attacker > can use a purely random attack, or even a constant attack, and > theoretically, eventually, statistically speaking, break through the > requestor's defenses. Saying that efforts to make the ID unpredictable are "hopeless" sounds like there is no point in even trying, which is certainly not the case. Even with the technique you describe, the ID still needs to be unpredictable, and for the 0x20 bits to bring any added benefit, they need to be unpredictable, too. How about replacing "hopeless" by "insufficient"? -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 07:21: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 F273D3A6A14; Wed, 27 Feb 2008 07:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-2.054, 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 Vc4Eq4bq-AFL; Wed, 27 Feb 2008 07:20:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82FD43A6E15; Wed, 27 Feb 2008 07:20:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUNu4-000D3F-Ru for namedroppers-data@psg.com; Wed, 27 Feb 2008 15:09:04 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUNti-000CzM-MK for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 15:08:53 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id 59FCA7C8E3; Wed, 27 Feb 2008 15:08:41 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 42D697616A; Wed, 27 Feb 2008 17:08:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18373.31992.915401.604818@guava.gson.org> Date: Wed, 27 Feb 2008 17:08:40 +0200 To: Paul Vixie Cc: namedroppers@ops.ietf.org, david.conrad@icann.org Subject: Re: edns0-bis submitted In-Reply-To: <12278.1203968637@sa.vix.com> References: <12278.1203968637@sa.vix.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Paul Vixie wrote: > http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt Back in 2002, David Conrad pointed out some problems with the interaction between EDNS0 and DNSSEC in It seems to me that this update fails to address those problems, and may even make them them worse by explicitly allowing requestors to take packet loss as an indication that a responder doesn't support EDNS0. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 07:23: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 098023A6A14; Wed, 27 Feb 2008 07:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whcw-vipRcYi; Wed, 27 Feb 2008 07:23:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55D153A68C8; Wed, 27 Feb 2008 07:23:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUNuY-000D89-4F for namedroppers-data@psg.com; Wed, 27 Feb 2008 15:09:34 +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 1JUNuP-000D5s-L9 for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 15:09:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 47FA511425; Wed, 27 Feb 2008 15:09:25 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: gson@araneus.fi (Andreas Gustafsson) cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Wed, 27 Feb 2008 16:39:28 +0200." <18373.30240.362882.927915@guava.gson.org> References: <69903.1204047792@sa.vix.com> <18373.30240.362882.927915@guava.gson.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Feb 2008 15:09:25 +0000 Message-ID: <24919.1204124965@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > 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. > > "Citation needed". Although there have certainly been many publicized cases > of cache pollution over the years, I'm not aware of a single case where that > pollution was shown to have resulted from an ID guessing attack. > Demonstrations of vulnerability, yes, but not actual attacks. If you know > of any documented cases, please share them. if i did know of any, i probably couldn't talk about them. so how about if i change this text to say "...many cache pollution vulnerabilities demonstrated..." since that was what i actually meant. > > 4.3. Much effort has been expended in trying to make the DNS transaction > > ID more random and less predictable. Ultimately such efforts are > > hopeless since with only 16 bits to fight over, a determined attacker > > can use a purely random attack, or even a constant attack, and > > theoretically, eventually, statistically speaking, break through the > > requestor's defenses. > > Saying that efforts to make the ID unpredictable are "hopeless" sounds > like there is no point in even trying, which is certainly not the > case. Even with the technique you describe, the ID still needs to be > unpredictable, and for the 0x20 bits to bring any added benefit, they > need to be unpredictable, too. How about replacing "hopeless" by > "insufficient"? done. draft is updated at http://sa.vix.com/~vixie/dns-0x20.txt, and also contains a change that was due to wouter@nlnetlabs, such that the tuple used for matching incoming responses to outstanding requests is correctly limited to the RCODE=0 or RCODE=3 case, and for OPCODE=0. -- to unsubscribe send a message to namedroppers-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 Feb 27 13:01: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 4C99A3A698E; Wed, 27 Feb 2008 13:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSRu8jw+gUMw; Wed, 27 Feb 2008 13:01:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90B0A3A6944; Wed, 27 Feb 2008 13:01:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTEq-00021C-5u for namedroppers-data@psg.com; Wed, 27 Feb 2008 20:50:52 +0000 Received: from [2001:4f8:3:bb::20] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTDv-0001tL-0p for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 20:50:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3609011438 for ; Wed, 27 Feb 2008 20:50:05 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: i'm thinking that EDNS0-bis is just not very sexy In-Reply-To: Your message of "Tue, 26 Feb 2008 23:14:42 PST." <20080227071442.GA77169@redoubt.spodhuis.org> References: <96993.1204086489@sa.vix.com> <20080227071442.GA77169@redoubt.spodhuis.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Feb 2008 20:50:05 +0000 Message-ID: <39608.1204145405@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt > > Apologies if this was covered, but I've checked archives and not found > mention of this. > > What happened to the extended label type reservation of 0bxx111111 ? it was dependent on the extended label type reservation, which was removed. > If this is no longer reserved, shouldn't that withdrawal be noted in the > IANA considerations? you're right, but moreso, we should tell IANA to delete the ELT registry. -- to unsubscribe send a message to namedroppers-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 Feb 27 13:06: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 E21CE3A6920; Wed, 27 Feb 2008 13:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmu8O2eZNi6H; Wed, 27 Feb 2008 13:06:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7AD43A6819; Wed, 27 Feb 2008 13:06:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTOs-0003pO-Cb for namedroppers-data@psg.com; Wed, 27 Feb 2008 21:01:14 +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 1JUTOZ-0003jx-2R for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 21:00:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1066B11425 for ; Wed, 27 Feb 2008 19:59:55 +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, 27 Feb 2008 13:24:54 CST." <47C5B906.7090904@isc.org> References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Feb 2008 19:59:55 +0000 Message-ID: <37367.1204142395@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I once proposed using a subset of UDP ports, per master. > > That is, if you open (say) 64 ports, when speaking with master 1.2.3.4, > you always use port[0], and 1.2.3.5 will always get port[1]. You can > change the ports periodically. in bind 9.5.0-beta i see an option called "querypool". can you tell us how that feature maps to your suggested port mapping/churning? > This means that to discover all known ports (say, if you wanted to fake > a master) you need to know what the port will be. Since a given address > always gets the same port, an attacker would need to have a lot of > addresses to discover all ports. as far as that goes, a full resolver would be harder to pollute if it randomly chose an authority server each time, rather than sorting by RTT or always using them in order. and if that was a common implementation choice, then zones would be "more secure" if they had more authority servers, since it would be harder for an attacker to guess what server a response had to come from. that may be worth a separate I-D -- anybody see a problem with it? > Additionally, why not just add this to EDNS0 as an option? That is, > make a huge number? I'm not entirely certain the claim that request > names are copied directly holds up to all devices. An EDNS0 option > would allow any length of additional ID space, and servers can remember > who participates and who does not, to minimize delay and maximize trust. this falls apart in the first millisecond after a downgrade attack, so, no. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 13:09: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 97A2328C372; Wed, 27 Feb 2008 13:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdpRmKA0XE7k; Wed, 27 Feb 2008 13:09:26 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CBAE28C4AE; Wed, 27 Feb 2008 13:09:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTOn-0003o4-0n for namedroppers-data@psg.com; Wed, 27 Feb 2008 21:01: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 1JUTOZ-0003jw-2T for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 21:00:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4EF411142F; Wed, 27 Feb 2008 17:33:01 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: gson@araneus.fi (Andreas Gustafsson) cc: namedroppers@ops.ietf.org, david.conrad@icann.org Subject: Re: edns0-bis submitted In-Reply-To: Your message of "Wed, 27 Feb 2008 17:08:40 +0200." <18373.31992.915401.604818@guava.gson.org> References: <12278.1203968637@sa.vix.com> <18373.31992.915401.604818@guava.gson.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Feb 2008 17:33:01 +0000 Message-ID: <30604.1204133581@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt > > Back in 2002, David Conrad pointed out some problems with the > interaction between EDNS0 and DNSSEC in > > > > It seems to me that this update fails to address those problems, and > may even make them them worse by explicitly allowing requestors to take > packet loss as an indication that a responder doesn't support EDNS0. i don't think there is a fix for the problem david describes. does anybody have any suggestions, given that EDNS is deployed, and useful, and necessary, and DNSSEC is not deployed, and may not be finished yet (see NSEC3 and DLV), and the world is not exactly beating a path to DNSSEC's door? "send diffs." -- to unsubscribe send a message to namedroppers-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 Feb 27 13:25: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 03CA83A696E; Wed, 27 Feb 2008 13:25:06 -0800 (PST) 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 6Gc+VPJsH+SC; Wed, 27 Feb 2008 13:25:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E2133A692F; Wed, 27 Feb 2008 13:25:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTgx-0006wU-80 for namedroppers-data@psg.com; Wed, 27 Feb 2008 21:19:55 +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 1JUTgm-0006um-Td for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 21:19:49 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 9F2EC327A74; Wed, 27 Feb 2008 11:24:54 -0800 (PST) Received: from [10.42.120.8] (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id E7D03327A73; Wed, 27 Feb 2008 11:24:53 -0800 (PST) Message-ID: <47C5B906.7090904@isc.org> Date: Wed, 27 Feb 2008 13:24:54 -0600 From: Michael Graff User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt References: <69903.1204047792@sa.vix.com> In-Reply-To: <69903.1204047792@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 using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I once proposed using a subset of UDP ports, per master. That is, if you open (say) 64 ports, when speaking with master 1.2.3.4, you always use port[0], and 1.2.3.5 will always get port[1]. You can change the ports periodically. This means that to discover all known ports (say, if you wanted to fake a master) you need to know what the port will be. Since a given address always gets the same port, an attacker would need to have a lot of addresses to discover all ports. Additionally, why not just add this to EDNS0 as an option? That is, make a huge number? I'm not entirely certain the claim that request names are copied directly holds up to all devices. An EDNS0 option would allow any length of additional ID space, and servers can remember who participates and who does not, to minimize delay and maximize trust. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHxbkGZXirchfeIY0RAi6FAJ9PYxPaw5PNvxiXrxXWsTaoBxFkTwCcDkxC rIgnZi30KDIQvkrudN/vVjo= =g7fM -----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 Feb 27 13:31: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 CE2E83A679C; Wed, 27 Feb 2008 13:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=-0.793, 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 sNJgYiekwHJf; Wed, 27 Feb 2008 13:31:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C2783A691A; Wed, 27 Feb 2008 13:31:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTno-00081i-CX for namedroppers-data@psg.com; Wed, 27 Feb 2008 21:27:00 +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 1JUTnV-0007yI-8M for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 21:26:43 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1RLQa5S070091 for ; Wed, 27 Feb 2008 16:26:36 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200802272126.m1RLQa5S070091@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 16:26:30 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: DNSEXT@IETF-71 Tue 13:00-15:00 Mime-Version: 1.0 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 posted updated agenda that reflects all the requests that I have got but one (still evaluating it). Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 13:42: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 D6C5028C326; Wed, 27 Feb 2008 13:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.416, 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 mVyRuaXeKce1; Wed, 27 Feb 2008 13:42:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D07528C39D; Wed, 27 Feb 2008 13:42:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTzE-0009qD-R2 for namedroppers-data@psg.com; Wed, 27 Feb 2008 21:38:48 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTzB-0009pZ-Ml for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 21:38:47 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JUTz9-0001iA-Tq; Wed, 27 Feb 2008 16:38:43 -0500 Message-ID: <47C5D857.6040500@ca.afilias.info> Date: Wed, 27 Feb 2008 16:38:31 -0500 From: Brian Dickson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Vixie CC: Andreas Gustafsson , namedroppers@ops.ietf.org, david.conrad@icann.org Subject: Re: edns0-bis submitted References: <12278.1203968637@sa.vix.com> <18373.31992.915401.604818@guava.gson.org> <30604.1204133581@sa.vix.com> In-Reply-To: <30604.1204133581@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: >>> http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt >>> >> Back in 2002, David Conrad pointed out some problems with the >> interaction between EDNS0 and DNSSEC in >> >> >> >> It seems to me that this update fails to address those problems, and >> may even make them them worse by explicitly allowing requestors to take >> packet loss as an indication that a responder doesn't support EDNS0. >> > > i don't think there is a fix for the problem david describes. does anybody > have any suggestions, given that EDNS is deployed, and useful, and necessary, > and DNSSEC is not deployed, and may not be finished yet (see NSEC3 and DLV), > and the world is not exactly beating a path to DNSSEC's door? > > "send diffs." > Well, what about having some way to detect EDNS0 capability, via a non-EDNS0 query? Rather than doing what effectively amounts to negative caching, do backwards-compatible forward probing. Since servers supporting EDNS0 are much more likely to be running more recent code, and more likely to update their code reasonably often (more than once a decade), a recommended future implementation "hack", that allows signaling capabilities in the data itself, is one possibility that is definitely feasible and doesn't require changes to the protocol proper, per se. E.g. similar to the 'id.server CH txt "foo.bar"', something similar that says 'edns0.server CH txt "yes"'. Thoughts? 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 Wed Feb 27 13:43: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 7883D3A6B93; Wed, 27 Feb 2008 13:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lvPXQXwLLD4; Wed, 27 Feb 2008 13:43:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97AD13A6983; Wed, 27 Feb 2008 13:43:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUTyk-0009ll-UX for namedroppers-data@psg.com; Wed, 27 Feb 2008 21:38:18 +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 1JUTyi-0009lE-6l for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 21:38:17 +0000 Received: from Miffy.lan (a82-95-132-144.adsl.xs4all.nl [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m1RLc9L6047018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2008 22:38:11 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Cc: namedroppers@ops.ietf.org Message-Id: <70B788FA-9E77-4637-9CCF-BCD4DEFBC04F@NLnetLabs.nl> From: Olaf Kolkman To: Paul Vixie In-Reply-To: <12278.1203968637@sa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-355301167" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: edns0-bis submitted Date: Wed, 27 Feb 2008 22:38:04 +0100 References: <12278.1203968637@sa.vix.com> 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, 27 Feb 2008 22:38:11 +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-25-355301167 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Source of confusion, and possible lack of perceived interest: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt Same file name different content: http://tinyurl.com/yvnxlr The new draft may not appear given the conflict in filename. I do not know exactly how the software/secretariat deals with this. --Olaf --Apple-Mail-25-355301167 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. iEYEARECAAYFAkfF2DwACgkQtN/ca3YJIofXVgCg8C6i8+mmAyMX0sp4DfxaHvJQ ELYAnAiLoigGlPpQuH33rEWFT46Rb41o =KcCU -----END PGP SIGNATURE----- --Apple-Mail-25-355301167-- -- to unsubscribe send a message to namedroppers-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 Feb 27 15:28: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 50A933A6A1F; Wed, 27 Feb 2008 15:28:53 -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 9H434Ke+u9nz; Wed, 27 Feb 2008 15:28:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8BEF3A6AC4; Wed, 27 Feb 2008 15:28:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUVbI-000NAk-Gd for namedroppers-data@psg.com; Wed, 27 Feb 2008 23:22:12 +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 1JUVb7-000N7O-E8 for namedroppers@ops.ietf.org; Wed, 27 Feb 2008 23:22:07 +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 m1RNLj3L033154; Thu, 28 Feb 2008 10:21:45 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802272321.m1RNLj3L033154@drugs.dv.isc.org> To: Paul Vixie Cc: gson@araneus.fi (Andreas Gustafsson), namedroppers@ops.ietf.org, david.conrad@icann.org From: Mark Andrews Subject: Re: edns0-bis submitted In-reply-to: Your message of "Wed, 27 Feb 2008 17:33:01 -0000." <30604.1204133581@sa.vix.com> Date: Thu, 28 Feb 2008 10:21:45 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > > http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt > > > > Back in 2002, David Conrad pointed out some problems with the > > interaction between EDNS0 and DNSSEC in > > > > ml> > > > > It seems to me that this update fails to address those problems, and > > may even make them them worse by explicitly allowing requestors to take > > packet loss as an indication that a responder doesn't support EDNS0. > > i don't think there is a fix for the problem david describes. does anybody > have any suggestions, given that EDNS is deployed, and useful, and necessary, > and DNSSEC is not deployed, and may not be finished yet (see NSEC3 and DLV), > and the world is not exactly beating a path to DNSSEC's door? You just don't take packet loss as a indication of no EDNS support. A RFC 1034 nameserver should respond to EDNS packets. One that doesn't is not RFC compliant. RFC 1034 had error codes for a reason. They are supposed to be used. 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. I'm tempted to say don't do any fallbacks on packet loss and just treat "packet loss" as "packet loss". Mark > "send diffs." > > -- > to 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 Feb 27 16:05: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 B43F83A6D57; Wed, 27 Feb 2008 16:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WUXKSjWmPK6; Wed, 27 Feb 2008 16:05:38 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81D873A6AE3; Wed, 27 Feb 2008 16:05:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWBz-0001wa-EF for namedroppers-data@psg.com; Thu, 28 Feb 2008 00:00:07 +0000 Received: from [131.111.8.139] (helo=ppsw-9.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWBw-0001w3-Ql for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 00:00:06 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:52433) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1JUWBn-0002gI-Tn (Exim 4.67) (return-path ); Wed, 27 Feb 2008 23:59:55 +0000 Received: from cet1 by draco.cus.cam.ac.uk with local (Exim 4.68) (envelope-from ) id 1JUWBn-00018L-4H; Wed, 27 Feb 2008 23:59:55 +0000 Subject: Re: edns0-bis submitted To: olaf@NLnetLabs.nl (Olaf Kolkman) Date: Wed, 27 Feb 2008 23:59:55 +0000 (GMT) Cc: namedroppers@ops.ietf.org, paul@vix.com In-Reply-To: <70B788FA-9E77-4637-9CCF-BCD4DEFBC04F@NLnetLabs.nl> from "Olaf Kolkman" at Feb 27, 8 10:38:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Olaf writes: > Source of confusion, and possible lack of perceived interest: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt (updated 28 December) Yup, thank you for the clarification(?). My original thought when I saw Paul Vixie's message was "but I had that one month(s) ago". And also, "how does Paul know how many times it has been fetched from the Internet Drafts mirrors, anyway?". Not to mention "I fetch them by ftp, dammit, not http, like it or lump it". -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-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 Feb 27 16:23: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 61F4C28C483; Wed, 27 Feb 2008 16:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.937 X-Spam-Level: X-Spam-Status: No, score=-4.937 tagged_above=-999 required=5 tests=[AWL=-0.442, 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 vMNvtUCv670d; Wed, 27 Feb 2008 16:23:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70D2228C5F7; Wed, 27 Feb 2008 16:22:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWTr-0004Zo-JD for namedroppers-data@psg.com; Thu, 28 Feb 2008 00:18:35 +0000 Received: from [216.82.253.51] (helo=mail153.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWTo-0004ZT-Tr for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 00:18:34 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1204157906!2757885!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 533 invoked from network); 28 Feb 2008 00:18:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 28 Feb 2008 00:18:26 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1S0IQ2Z023228 for ; Wed, 27 Feb 2008 17:18:26 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m1S0IPhm011931 for ; Wed, 27 Feb 2008 18:18:25 -0600 (CST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m1S0IOs3011928 for ; Wed, 27 Feb 2008 18:18:25 -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: Wed, 27 Feb 2008 19:18:20 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790038E3F18@de01exm64.ds.mot.com> In-Reply-To: <72809.1204051801@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns-0x20.txt Thread-Index: Ach4qty9NFTy9zvRT/CsIstK4VSVwwA872/A References: <69903.1204047792@sa.vix.com> <72809.1204051801@sa.vix.com> From: "Eastlake III Donald-LDE008" To: "Paul Vixie" Cc: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Hi, I like the dns-0x20 idea although presumably in some cases, like resolving a country code or resolving x69.us, it would add only two or three bits. If you are talking about my cookie proposal below (current draft at http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt ) I'm not aware of any downgrade attack. Could you enlighten me? Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Paul Vixie Sent: Tuesday, February 26, 2008 1:50 PM To: namedroppers@ops.ietf.org Cc: dagon@cc.gatech.edu Subject: Re: dns-0x20.txt=20 ... via the full resolver, would have to have a fallback plan. the fallback plan would be subject to downgrade attacks (similar to the cookie approach that's been elsewhere proposed) and is thus not worth pursuing. ... -- to unsubscribe send a message to namedroppers-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 Feb 27 16:23: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 9BFF73A6AE3; Wed, 27 Feb 2008 16:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[AWL=-0.402, 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 LKOF1I-l253c; Wed, 27 Feb 2008 16:23:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7479D3A6921; Wed, 27 Feb 2008 16:23:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWVe-0004ox-1U for namedroppers-data@psg.com; Thu, 28 Feb 2008 00:20:26 +0000 Received: from [216.82.241.179] (helo=mail119.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWVb-0004oQ-K6 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 00:20:24 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1204158016!31755939!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3779 invoked from network); 28 Feb 2008 00:20:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 28 Feb 2008 00:20:17 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1S0KGmD023520 for ; Wed, 27 Feb 2008 17:20:16 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m1S0KGSA016000 for ; Wed, 27 Feb 2008 18:20:16 -0600 (CST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m1S0KFqc015991 for ; Wed, 27 Feb 2008 18:20:15 -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: Wed, 27 Feb 2008 19:20:13 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.com> In-Reply-To: <47C5B906.7090904@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns-0x20.txt Thread-Index: Ach5iR2dz8j8zgK0RQi/22JyQNjQCgAFlYbw References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> From: "Eastlake III Donald-LDE008" To: "Michael Graff" Cc: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Hi, On using an EDNS0 option, please see my draft at http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt . For simplicity is proposes a fixed size but it would be trivial to make it variable. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Michael Graff Sent: Wednesday, February 27, 2008 2:25 PM To: Paul Vixie; namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt ... Additionally, why not just add this to EDNS0 as an option? That is, make a huge number? I'm not entirely certain the claim that request names are copied directly holds up to all devices. An EDNS0 option would allow any length of additional ID space, and servers can remember who participates and who does not, to minimize delay and maximize trust. - --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 Wed Feb 27 16:31: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 9CE3B3A6B2B; Wed, 27 Feb 2008 16:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kAqqYR2fAN0; Wed, 27 Feb 2008 16:31:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6C4B28C255; Wed, 27 Feb 2008 16:31:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWaz-0005ZB-Jf for namedroppers-data@psg.com; Thu, 28 Feb 2008 00:25: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 1JUWax-0005Yq-5p for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 00:25:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C2B4411429 for ; Thu, 28 Feb 2008 00:25:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT@IETF-71 Tue 13:00-15:00 In-Reply-To: Your message of "Wed, 27 Feb 2008 16:26:30 EST." <200802272126.m1RLQa5S070091@ogud.com> References: <200802272126.m1RLQa5S070091@ogud.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Feb 2008 00:25:54 +0000 Message-ID: <47744.1204158354@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > I posted updated agenda that reflects all the requests that I have got > but one (still evaluating it). note, i'll be in philly (on arin business) but i'm not signed up for ietf since there's no "day pass" and i just won't pay $635 to attend a single WG meeting. therefore, look for me in the hotel's main bar area, at lunch time on tuesday, after the DNSEXT meeting is over, if you think i'm wrongheaded or misinformed about dns-0x20 or edns0-bis. -- to unsubscribe send a message to namedroppers-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 Feb 27 16: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 99E723A6E37; Wed, 27 Feb 2008 16:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcXEMhdvycSE; Wed, 27 Feb 2008 16:49:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C25E63A6E5A; Wed, 27 Feb 2008 16:47:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUWrJ-00081o-GZ for namedroppers-data@psg.com; Thu, 28 Feb 2008 00:42:49 +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 1JUWrG-00080i-C3 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 00:42:48 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C586A11432; Thu, 28 Feb 2008 00:42:45 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Chris Thompson cc: olaf@NLnetLabs.nl (Olaf Kolkman), namedroppers@ops.ietf.org Subject: Re: edns0-bis submitted In-Reply-To: Your message of "Wed, 27 Feb 2008 23:59:55 GMT." References: X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Feb 2008 00:42:45 +0000 Message-ID: <48405.1204159365@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > Yup, thank you for the clarification(?). My original thought when I saw > Paul Vixie's message was "but I had that one month(s) ago". And also, > "how does Paul know how many times it has been fetched from the Internet > Drafts mirrors, anyway?". Not to mention "I fetch them by ftp, dammit, > not http, like it or lump it". olafur told me to resubmit it as a -00 before the -00 deadline so i did. i'll change it to say -01 and submit it again. -- to unsubscribe send a message to namedroppers-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 Feb 27 16:58: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 1E6EA3A6A1F; Wed, 27 Feb 2008 16:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc4x6t6EU8fh; Wed, 27 Feb 2008 16:58:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8637F3A6B97; Wed, 27 Feb 2008 16:58:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUX2M-0009ia-CG for namedroppers-data@psg.com; Thu, 28 Feb 2008 00:54:14 +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 1JUX2J-0009iD-Mw for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 00:54:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6E4E911432 for ; Thu, 28 Feb 2008 00:54:11 +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, 27 Feb 2008 19:18:20 EST." <3870C46029D1F945B1472F170D2D9790038E3F18@de01exm64.ds.mot.com> References: <69903.1204047792@sa.vix.com> <72809.1204051801@sa.vix.com> <3870C46029D1F945B1472F170D2D9790038E3F18@de01exm64.ds.mot.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Feb 2008 00:54:11 +0000 Message-ID: <48860.1204160051@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > If you are talking about my cookie proposal below (current draft at > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt) > I'm not aware of any downgrade attack. Could you enlighten me? i hadn't read that and wasn't aware of it, but it's similar to the idea i was thinking of, which was first proposed by me during the work that led up to the publication of RFC 2671. basically, EDNS0 is susceptible to a downgrade attack, and any cookie carried in an OPT RR is susceptible to that downgrade attack. if somebody is flooding you with answers that don't have an OPT RR, and then injects a query that causes you to go upstream and you begin by probing for EDNS0 by including an OPT RR in your upstream query, and then you open up the hose that has the answer flood in it, and one of those answers has the right port number and query ID in it, then you'll take it, because you will think that the other end, that you're just now probing, doesn't speak EDNS0. i admit this is a slim window but then so is guessing somebody's PRNG state and i think that if we're going to try to improve things, we should improve them rather than just adding more of the same. like for example DNSSEC. * * * marka has made the revolutionary (to me at least) proposal that once you've heard EDNS0 from a responder, you should remember that you did, and you should not be willing to believe that they've lost this capability. i'm a little worried about the cost of that state, and i'm a little worried about timing it out in the case of an actual real-world server downgrade, but i'm intrigued. especially in light of brian's proposal that the probing be done prospectively rather than opportunistically. brian, please note, i wanted it done opportunistically because it would result in zero extra packets once full deployment was reached, but in light of subsequent events, i'd be willing to say 100% is never going to be reached, and extra packets will therefore always be with us, and so we might as well send them prospectively. if we do what marka said and we do what brian said, then cookies can work, assuming that the prospective probe packet is allowed to contain a random string which must be echoed back exactly, so that only a congestion attack can prevent the probe from succeeding. (maybe the probe needs retries.) what a hairball. -- to unsubscribe send a message to namedroppers-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 Feb 27 17:33: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 D74273A6A8C; Wed, 27 Feb 2008 17:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIDe6xP5vMY7; Wed, 27 Feb 2008 17:33:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1F5B3A6990; Wed, 27 Feb 2008 17:33:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUXY3-000DYT-PO for namedroppers-data@psg.com; Thu, 28 Feb 2008 01:26:59 +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 1JUXY1-000DXQ-A5 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 01:26:58 +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 m1S1Qo8c053431; Thu, 28 Feb 2008 12:26:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802280126.m1S1Qo8c053431@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: dns-0x20.txt In-reply-to: Your message of "Thu, 28 Feb 2008 00:54:11 -0000." <48860.1204160051@sa.vix.com> Date: Thu, 28 Feb 2008 12:26:50 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > marka has made the revolutionary (to me at least) proposal that once you've > heard EDNS0 from a responder, you should remember that you did, and you > should not be willing to believe that they've lost this capability. i'm a > little worried about the cost of that state, and i'm a little worried about > timing it out in the case of an actual real-world server downgrade, but i'm > intrigued. I don't remember saying that. 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. 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 Wed Feb 27 17:56: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 874AA3A6A20; Wed, 27 Feb 2008 17:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQh-fCF4R4gv; Wed, 27 Feb 2008 17:56:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C48C3A695A; Wed, 27 Feb 2008 17:56:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUXvI-000GB2-K4 for namedroppers-data@psg.com; Thu, 28 Feb 2008 01:51: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 1JUXvG-000GAn-B8 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 01:50:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0486A11434; Thu, 28 Feb 2008 01:50:57 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mark Andrews cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Thu, 28 Feb 2008 12:26:50 +1100." <200802280126.m1S1Qo8c053431@drugs.dv.isc.org> References: <200802280126.m1S1Qo8c053431@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Feb 2008 01:50:57 +0000 Message-ID: <51421.1204163457@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > 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." -- to unsubscribe send a message to namedroppers-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 Feb 27 18:01: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 21AFB3A69F2; Wed, 27 Feb 2008 18:01:40 -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 roYPCsB5cbhd; Wed, 27 Feb 2008 18:01:39 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 163553A696F; Wed, 27 Feb 2008 18:01:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUY1E-000Gtt-Qo for namedroppers-data@psg.com; Thu, 28 Feb 2008 01:57:08 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUY1C-000Gso-F8 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 01:57:07 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 9539A114028; Thu, 28 Feb 2008 01:57:04 +0000 (UTC) (envelope-from Evan_Hunt@isc.org) Received: by farside.isc.org (Postfix, from userid 10292) id 3E126E60A2; Thu, 28 Feb 2008 01:57:04 +0000 (UTC) Date: Thu, 28 Feb 2008 01:57:04 +0000 From: Evan Hunt To: Mark Andrews Cc: Paul Vixie , Andreas Gustafsson , namedroppers@ops.ietf.org, david.conrad@icann.org Subject: Re: edns0-bis submitted Message-ID: <20080228015704.GB50588@isc.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.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > i don't think there is a fix for the problem david describes. The problem he describes--part of it, anyway--is that an RCODE of SERVFAIL, FORMERR or NOTIMPL is ambiguous; it might mean "What is this 'EDNS0' of which you speak?" or it might mean some other stuff. However, section 5.1 of the draft says including an OPT RR in a message unambiguously declares that the server *does* grok EDNS0. So, tie them together: A responder MUST include an OPT RR in any message to an EDNS0 requestor, even if the message is a SERVFAIL, NOTIMPL, or FORMERR. No more ambiguity; if the OPT is there, that means the error was *not* related to a lack of EDNS0 support. (For all I know that may already be SOP among server implementations; it seems worth specifying anyway.) -- Evan Hunt -- evan_hunt@isc.org Internet Systems Consortium, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 19:00: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 82EF93A6E35; Wed, 27 Feb 2008 19:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mtmv9Tr0k4Oy; Wed, 27 Feb 2008 19:00:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 060573A6D6D; Wed, 27 Feb 2008 19:00:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUYu4-0004Nr-Og for namedroppers-data@psg.com; Thu, 28 Feb 2008 02:53:48 +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 1JUYu1-0004NQ-V3 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 02:53:47 +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 m1S2rXo8073333; Thu, 28 Feb 2008 13:53:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802280253.m1S2rXo8073333@drugs.dv.isc.org> To: Evan Hunt Cc: Paul Vixie , Andreas Gustafsson , namedroppers@ops.ietf.org, david.conrad@icann.org From: Mark Andrews Subject: Re: edns0-bis submitted In-reply-to: Your message of "Thu, 28 Feb 2008 01:57:04 -0000." <20080228015704.GB50588@isc.org> Date: Thu, 28 Feb 2008 13:53:33 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > > i don't think there is a fix for the problem david describes. > > The problem he describes--part of it, anyway--is that an RCODE of > SERVFAIL, FORMERR or NOTIMPL is ambiguous; it might mean "What is > this 'EDNS0' of which you speak?" or it might mean some other stuff. SERVFAIL is query dependent. FORMERR/NOTIMPL is server dependent. > However, section 5.1 of the draft says including an OPT RR in a > message unambiguously declares that the server *does* grok EDNS0. > > So, tie them together: A responder MUST include an OPT RR in any > message to an EDNS0 requestor, even if the message is a SERVFAIL, > NOTIMPL, or FORMERR. No more ambiguity; if the OPT is there, that > means the error was *not* related to a lack of EDNS0 support. > > (For all I know that may already be SOP among server implementations; > it seems worth specifying anyway.) > > -- > Evan Hunt -- evan_hunt@isc.org > Internet Systems Consortium, Inc. -- 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 Feb 27 23:33: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 2E8013A680C; Wed, 27 Feb 2008 23:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAAv0GEUssLe; Wed, 27 Feb 2008 23:33:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D06AB3A6A7E; Wed, 27 Feb 2008 23:33:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUd7M-000Axg-D1 for namedroppers-data@psg.com; Thu, 28 Feb 2008 07:23:48 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUd7J-000AwV-L2 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 07:23:46 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 0270911401F for ; Thu, 28 Feb 2008 03:23:18 +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 556B4E6056 for ; Thu, 28 Feb 2008 03:23:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m1S3Ltgw073526; Thu, 28 Feb 2008 14:21:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802280321.m1S3Ltgw073526@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: dns-0x20.txt In-reply-to: Your message of "Thu, 28 Feb 2008 01:50:57 -0000." <51421.1204163457@sa.vix.com> Date: Thu, 28 Feb 2008 14:21:55 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > 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. 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. 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. 5.7. A client MAY treat SERVFAIL as indicating lack of support for EDNS for this query only. -- 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 Feb 28 00:35: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 4F6B93A6A74; Thu, 28 Feb 2008 00:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=1.342, 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 8YIUlAkzdDp5; Thu, 28 Feb 2008 00:35:43 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60E193A6835; Thu, 28 Feb 2008 00:35:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUe8m-000Kjt-2a for namedroppers-data@psg.com; Thu, 28 Feb 2008 08:29:20 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUe8j-000KjZ-LW for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 08:29:18 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A732B1C0158; Thu, 28 Feb 2008 09:29:14 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id A26641C014B; Thu, 28 Feb 2008 09:29:14 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9571858E9F2; Thu, 28 Feb 2008 09:29:14 +0100 (CET) Date: Thu, 28 Feb 2008 09:29:14 +0100 From: Stephane Bortzmeyer To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-02.txt Message-ID: <20080228082914.GA26864@nic.fr> References: <20080218210001.AB0E13A6876@core3.amsl.com> <200802182322.m1INMNPY034159@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802182322.m1INMNPY034159@drugs.dv.isc.org> 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 Tue, Feb 19, 2008 at 10:22:23AM +1100, Mark Andrews wrote a message of 43 lines which said: > This is the second time in recent weeks that a draft that > should have been there was not. Instead of draft I'm getting > the expired boiler plate for the previous revision of the > draft. Something is systematically going wrong. This has been reported to AMS ([rt.amsl.com #2282]) and they replied the problem is now fixed (but the draft disappeared, it has to be re-submitted). -- to unsubscribe send a message to namedroppers-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 Feb 28 02:04: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 5D2443A67E2; Thu, 28 Feb 2008 02:04:38 -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 IgD17fj0rqDN; Thu, 28 Feb 2008 02:04:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1A6F3A6A0C; Thu, 28 Feb 2008 02:04:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUfVH-0005Jz-6l for namedroppers-data@psg.com; Thu, 28 Feb 2008 09:56:39 +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 1JUfVE-0005JX-6V for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 09:56:37 +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 m1S98dOS004550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 10:08:40 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47C67A17.4000407@nlnetlabs.nl> Date: Thu, 28 Feb 2008 10:08:39 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Eastlake III Donald-LDE008 CC: Michael Graff , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.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]); Thu, 28 Feb 2008 10:08:40 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eastlake III Donald-LDE008 wrote: | Hi, | | On using an EDNS0 option, please see my draft at | http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt | . | For simplicity is proposes a fixed size but it would be trivial to make | it variable. I like the idea of using an EDNS0 option to contain random data. Perhaps without a complicated hashing scheme (as you have), 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 occasional timeout or reboot presents small windows of downgrade attack. State could be stored on disk though.). Anyway, your proposal is nice. 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 full resolver may break the uppercase bit in the binary data). DNSSEC, as it gets deployed, makes spoof protection mechanisms obsolete. And DNSSEC is already deployed on some TLDs. Configuring keys is a much more reliable way to prevent spoofing for them. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHxnoXkDLqNwOhpPgRAos6AKCce9CbypK9lXx+Rxz5RE5QkfAjKACcCn1T /X66EP/lYDaDhkSAzSxo8OE= =ljuu -----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 Feb 28 02:08: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 D8D4628C233; Thu, 28 Feb 2008 02:08:24 -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 1rijsJFGU+Hp; Thu, 28 Feb 2008 02:08:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5566D3A67ED; Thu, 28 Feb 2008 02:07:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUfVM-0005Kf-Kv for namedroppers-data@psg.com; Thu, 28 Feb 2008 09:56:44 +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 1JUfVG-0005JX-Gf for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 09:56:40 +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 m1S8wAW3003730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 09:58:10 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47C677A2.3050207@nlnetlabs.nl> Date: Thu, 28 Feb 2008 09:58:10 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: edns-0 References: <200802280321.m1S3Ltgw073526@drugs.dv.isc.org> In-Reply-To: <200802280321.m1S3Ltgw073526@drugs.dv.isc.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, 28 Feb 2008 09:58:10 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----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. | 5.7. A client MAY treat SERVFAIL as indicating lack of support | for EDNS for this query only. I fail to see relevance of the statement. I suggest to remove it. I agree with the 'packet loss is packet loss' statement earlier. If some firewall drops packets, then there is packet loss. If the firewall wanted to support DNS, it could send a DNS error. Also, about the topic: every EDNS query gets an EDNS answer. This is incorrect. Some queries with EDNS do not get EDNS in the answer. For example: parsing fails on the server in the query section, result is formerr with no EDNS OPT in the reply. There are many more cases (mostly errors). A different query or trying later may return with EDNS. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHxneikDLqNwOhpPgRAs7+AJ9FbIUe1q+qeccv+I172ULsdBNkhwCfdr4e AzyBRjpnvQRWzsIEXKU6WnA= =jAuT -----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 Feb 28 02: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 276B53A6B6E; Thu, 28 Feb 2008 02:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 se1U8nadZxnL; Thu, 28 Feb 2008 02:26:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B0EA3A6B9E; Thu, 28 Feb 2008 02:26:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUfuM-0009Nj-7t for namedroppers-data@psg.com; Thu, 28 Feb 2008 10:22:34 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUfuJ-0009My-I9 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 10:22:32 +0000 Received: from [81.149.244.44] (account jim HELO [172.16.1.41]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 220252; Thu, 28 Feb 2008 10:22:30 +0000 In-Reply-To: <200802280126.m1S1Qo8c053431@drugs.dv.isc.org> References: <200802280126.m1S1Qo8c053431@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <64596508-A1BE-4CDD-A0CE-3D2E434442BF@rfc1035.com> Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: dns-0x20.txt Date: Thu, 28 Feb 2008 10:21:27 +0000 To: Mark Andrews X-Mailer: Apple Mail (2.753) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Feb 28, 2008, at 01:26, Mark Andrews wrote: > 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. Mark, I agree that DNS stuff which doesn't support EDNS is broken. However there's no standards-track RFC that says "thou MUST implement ENDS" or "those that don't are broken". This was why Lawrence and I came up with draft-ietf-enum-edns0-00.txt. The prime motivation for that was to ensure handset manufacturers and the like put EDNS support in their ENUM-aware resolvers. Since there's currently no other IETF document that says they should do this, they won't add this to the handset firmware or whatever. -- to unsubscribe send a message to namedroppers-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 Feb 28 02:49: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 159D83A67E2; Thu, 28 Feb 2008 02:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbR1tvtHpLBG; Thu, 28 Feb 2008 02:48:56 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E8753A680F; Thu, 28 Feb 2008 02:48:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUgE6-000Cln-Tm for namedroppers-data@psg.com; Thu, 28 Feb 2008 10:42:58 +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 1JUgE1-000CjN-BO for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 10:42:54 +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 m1SAgZrQ071594; Thu, 28 Feb 2008 21:42:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802281042.m1SAgZrQ071594@drugs.dv.isc.org> To: Wouter Wijngaards Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: edns-0 In-reply-to: Your message of "Thu, 28 Feb 2008 09:58:10 BST." <47C677A2.3050207@nlnetlabs.nl> Date: Thu, 28 Feb 2008 21:42:35 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > -----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. The aboves is what should happen. > > | 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. This is to deal with what does happen. > | 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. Similarly this is to deal with what does happen. > > | 5.7. A client MAY treat SERVFAIL as indicating lack of support > | for EDNS for this query only. > > I fail to see relevance of the statement. I suggest to remove it. SERVFAIL is a catch all response. A RFC 1034 server may still end up emitting this to a EDNS query .... > I agree with the 'packet loss is packet loss' statement earlier. > If some firewall drops packets, then there is packet loss. If the > firewall wanted to support DNS, it could send a DNS error. > > Also, about the topic: every EDNS query gets an EDNS answer. > This is incorrect. Some queries with EDNS do not get EDNS in the answer. > For example: parsing fails on the server in the query section, result is > formerr with no EDNS OPT in the reply. There are many more cases (mostly > errors). A different query or trying later may return with EDNS. If you parse the OPT record you should add it to the response. This allows FORMERR to signal that you don't understand something else. What we got wrong with EDNS is the rcode handling. We shouldn't have pasted the bits together. We should have just put the rcode in both places, for rcodes > 14 you would have a "extended rcode" indication (15) in the header. We could fix this with EDNS1. > Best regards, > ~ Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFHxneikDLqNwOhpPgRAs7+AJ9FbIUe1q+qeccv+I172ULsdBNkhwCfdr4e > AzyBRjpnvQRWzsIEXKU6WnA= > =jAuT > -----END PGP SIGNATURE----- -- 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 Feb 28 02:56: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 54CAA28C4EE; Thu, 28 Feb 2008 02:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuLJdd7tEvo3; Thu, 28 Feb 2008 02:56:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A64E28C565; Thu, 28 Feb 2008 02:56:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUgNa-000E9b-LN for namedroppers-data@psg.com; Thu, 28 Feb 2008 10:52: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 1JUgNU-000E8g-Tj for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 10:52:42 +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 m1SAqYKn071750; Thu, 28 Feb 2008 21:52:34 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802281052.m1SAqYKn071750@drugs.dv.isc.org> To: Jim Reid Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: dns-0x20.txt In-reply-to: Your message of "Thu, 28 Feb 2008 10:21:27 -0000." <64596508-A1BE-4CDD-A0CE-3D2E434442BF@rfc1035.com> Date: Thu, 28 Feb 2008 21:52:34 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > On Feb 28, 2008, at 01:26, Mark Andrews wrote: > > > 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. > > Mark, I agree that DNS stuff which doesn't support EDNS is broken. > However there's no standards-track RFC that says "thou MUST implement > ENDS" or "those that don't are broken". I said "respond" not "talks EDNS". RFC 1034 has FORMERR so the server can tell the client that it doesn't understand the request. Servers that don't emit FORMERR when they don't understand the request are *broken*. > This was why Lawrence and I > came up with draft-ietf-enum-edns0-00.txt. The prime motivation for > that was to ensure handset manufacturers and the like put EDNS > support in their ENUM-aware resolvers. Since there's currently no > other IETF document that says they should do this, they won't add > this to the handset firmware or whatever. -- 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 Feb 28 03:09: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 AAA9128C3A0; Thu, 28 Feb 2008 03:09:16 -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 cCrXycJ43cbm; Thu, 28 Feb 2008 03:09:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FBE928C41A; Thu, 28 Feb 2008 03:09:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUgYA-000GG3-3t for namedroppers-data@psg.com; Thu, 28 Feb 2008 11:03:42 +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 1JUgXt-000G9w-Vw for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 11:03:32 +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 m1SB3BTQ014467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 12:03:11 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <47C694EF.7060901@nlnetlabs.nl> Date: Thu, 28 Feb 2008 12:03:11 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: edns-0 References: <200802281042.m1SAgZrQ071594@drugs.dv.isc.org> In-Reply-To: <200802281042.m1SAgZrQ071594@drugs.dv.isc.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, 28 Feb 2008 12:03:11 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: |> The aboves is what should happen. Agreed. |> This is to deal with what does happen. |> Similarly this is to deal with what does happen. Yes, you're right. Those middleboxes are going to make the edns draft very complicated. But it shouldn't break DNSSEC to deal with it. |> SERVFAIL is a catch all response. A RFC 1034 server may still |> end up emitting this to a EDNS query .... Yep. So that warrants some discussion about it; not sure what, 'an EDNS query may elicit a SERVFAIL response from a non-EDNS server'? Split up the text to describe some cases that show the server supports EDNS (it is in the reply), that it doesn't (rcode NOTIMPL for one), and inconclusive errors (like packet loss). |> If you parse the OPT record you should add it to the response. |> This allows FORMERR to signal that you don't understand something |> else. Good idea. |> What we got wrong with EDNS is the rcode handling. We |> shouldn't have pasted the bits together. We should have |> just put the rcode in both places, for rcodes > 14 you would |> have a "extended rcode" indication (15) in the header. We |> could fix this with EDNS1. Yes it is a bother, and support for EDNS rcodes is lacking. But it is a waste of 4 bits. Maybe define for every EDNS rcode a fallback rcode for in the header? (i.e. FIREWALL_EDNS_SIZE_ERROR(NOTIMPL)) Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHxpTvkDLqNwOhpPgRArGuAJ9MoIdUdtHTEmNcy0IDquxFKgnajACfXCBJ pZunxcV8JLOebtI5WTjPghM= =vDe1 -----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 Feb 28 03:10: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 964CB3A680F; Thu, 28 Feb 2008 03:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6M+VFhfnKro; Thu, 28 Feb 2008 03:10:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0EC03A6A13; Thu, 28 Feb 2008 03:10:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUgXf-000G7d-Tn for namedroppers-data@psg.com; Thu, 28 Feb 2008 11:03:11 +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 1JUgXU-000G5m-J5 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 11:03:05 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m1SB2dlP024671; Thu, 28 Feb 2008 13:02:39 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m1SB2dwf024668; Thu, 28 Feb 2008 13:02:39 +0200 Date: Thu, 28 Feb 2008 13:02:39 +0200 (EET) From: Pekka Savola To: Wouter Wijngaards cc: Mark Andrews , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: edns-0 In-Reply-To: <47C677A2.3050207@nlnetlabs.nl> Message-ID: References: <200802280321.m1S3Ltgw073526@drugs.dv.isc.org> <47C677A2.3050207@nlnetlabs.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/6016/Thu Feb 28 00:42:18 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Thu, 28 Feb 2008, Wouter Wijngaards wrote: > | 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. Which is better, in the grand scheme of things, firewalls which try to parse and validate DNS packets (and are always falling behind the DNS features that they should understand), or that firewalls that try to understand as little as possible about DNS packets? I'd argue that trying to get firewalls to have more and more DNS parsing logic is sinking in a swamp. No matter what we try to do, we sink down and down.. Wouldn't it better to a) just cope with firewalls (whether they do silent discard or not), or b) recommend they send back an ICMP error message? -- 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 Thu Feb 28 06: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 35F053A6E4E; Thu, 28 Feb 2008 06:01:07 -0800 (PST) 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 rnYMlPVZGLUY; Thu, 28 Feb 2008 06:01:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 118313A68BF; Thu, 28 Feb 2008 06:00:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUj6V-000HNK-VL for namedroppers-data@psg.com; Thu, 28 Feb 2008 13:47:19 +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 1JUj6M-000HMJ-6p for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 13:47:14 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 89AD0327A73; Thu, 28 Feb 2008 05:47:09 -0800 (PST) Received: from [10.42.120.8] (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 884BD327A5A; Thu, 28 Feb 2008 05:47:08 -0800 (PST) Message-ID: <47C6BB5A.6030909@isc.org> Date: Thu, 28 Feb 2008 07:47:06 -0600 From: Michael Graff User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> <37367.1204142395@sa.vix.com> In-Reply-To: <37367.1204142395@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 using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: |> This means that to discover all known ports (say, if you wanted to fake |> a master) you need to know what the port will be. Since a given address |> always gets the same port, an attacker would need to have a lot of |> addresses to discover all ports. | | as far as that goes, a full resolver would be harder to pollute if it randomly | chose an authority server each time, rather than sorting by RTT or always | using them in order. and if that was a common implementation choice, then | zones would be "more secure" if they had more authority servers, since it | would be harder for an attacker to guess what server a response had to come | from. that may be worth a separate I-D -- anybody see a problem with it? The next logical step is to ask all authority servers and only believe an answer when you get confirmation. It'll double the traffic, but DNS isn't that much now, is it? (1/2 :) Or use DNSSEC. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHxrtaLdqv0r6eD6YRAvcrAJ9JtqZ9Et1u0Qg4ykNAEVsyfFUTqQCfXBT5 P7mhDumTU2IMKTXBXShgL+8= =mCGS -----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 Feb 28 09:43: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 AE9E93A6E6D; Thu, 28 Feb 2008 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXBt7b5iIyc0; Thu, 28 Feb 2008 09:43:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22CDC28C127; Thu, 28 Feb 2008 09:42:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUmdV-0003h6-Ap for namedroppers-data@psg.com; Thu, 28 Feb 2008 17:33:37 +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 1JUmd6-0003dN-ER for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 17:33:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 889111142F; Thu, 28 Feb 2008 17:33:11 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Wouter Wijngaards cc: Eastlake III Donald-LDE008 , Michael Graff , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Thu, 28 Feb 2008 10:08:39 +0100." <47C67A17.4000407@nlnetlabs.nl> References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.com> <47C67A17.4000407@nlnetlabs.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Feb 2008 17:33:11 +0000 Message-ID: <87806.1204219991@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > 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 full resolver > may break the uppercase bit in the binary data). binary labels are already not usable. case folding is universal. > DNSSEC, as it gets deployed, makes spoof protection mechanisms obsolete. > And DNSSEC is already deployed on some TLDs. Configuring keys is a much > more reliable way to prevent spoofing for them. agreed, but it's still years away (at a minimum) from universal deployment. -- to unsubscribe send a message to namedroppers-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 Feb 28 11:40: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 27A923A6C2F; Thu, 28 Feb 2008 11:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 KTRAgqNUCxfO; Thu, 28 Feb 2008 11:40:21 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA4B028C851; Thu, 28 Feb 2008 11:40:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUoTX-000MWT-Lh for namedroppers-data@psg.com; Thu, 28 Feb 2008 19:31:27 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUoTN-000MVI-AV for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 19:31:21 +0000 Received: from user-64-9-234-185.googlewifi.com (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id E061033C2E; Thu, 28 Feb 2008 11:31:16 -0800 (PST) Date: Thu, 28 Feb 2008 11:31:16 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Paul Vixie Cc: Wouter Wijngaards , Eastlake III Donald-LDE008 , Michael Graff , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: <87806.1204219991@sa.vix.com> References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.com> <47C67A17.4000407@nlnetlabs.nl> <87806.1204219991@sa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At Thu, 28 Feb 2008 17:33:11 +0000, Paul Vixie wrote: > > 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 full resolver > > may break the uppercase bit in the binary data). > > binary labels are already not usable. case folding is universal. If this means RFC2673, I don't think dns-0x20 necessarily breaks it because it uses separate bits to indicate the labels are binary. We can simply specify the 0x20 resolver MUST NOT modify binary labels. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 28 12:52: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 244693A67B3; Thu, 28 Feb 2008 12:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A4-Rp-qFkBR; Thu, 28 Feb 2008 12:52:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E67028C15E; Thu, 28 Feb 2008 12:52:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUpc1-0008Yi-Dq for namedroppers-data@psg.com; Thu, 28 Feb 2008 20:44:17 +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 1JUpby-0008Xz-4f for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 20:44:15 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8EA6011429; Thu, 28 Feb 2008 20:44:13 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Wouter Wijngaards , Eastlake III Donald-LDE008 , Michael Graff , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Thu, 28 Feb 2008 11:31:16 PST." References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> <3870C46029D1F945B1472F170D2D9790038E3F1A@de01exm64.ds.mot.com> <47C67A17.4000407@nlnetlabs.nl> <87806.1204219991@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Feb 2008 20:44:13 +0000 Message-ID: <95468.1204231453@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > binary labels are already not usable. case folding is universal. > > If this means RFC2673, I don't think dns-0x20 necessarily breaks it > because it uses separate bits to indicate the labels are binary. We > can simply specify the 0x20 resolver MUST NOT modify binary labels. i will add that note to the draft. bitstring labels are dead, anyway, but we ought to make sure there's an applicability statement for 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 Thu Feb 28 17: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 AD6973A6A4F; Thu, 28 Feb 2008 17:58:57 -0800 (PST) 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 k89vuUYxibpJ; Thu, 28 Feb 2008 17:58:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E02073A69AA; Thu, 28 Feb 2008 17:58:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUuOw-0003Ng-Lk for namedroppers-data@psg.com; Fri, 29 Feb 2008 01:51:06 +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 1JUuOl-0003Lc-R7 for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 01:50:57 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m1T1oqrd090522 for ; Thu, 28 Feb 2008 20:50:52 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m1T1oqpS090521 for namedroppers@ops.ietf.org; Thu, 28 Feb 2008 20:50:52 -0500 (EST) (envelope-from namedroppers) Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JU4yV-00089B-P5 for namedroppers@ops.ietf.org; Tue, 26 Feb 2008 18:56:44 +0000 X-IronPort-AV: E=Sophos;i="4.25,408,1199664000"; d="scan'208";a="15474635" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Feb 2008 18:56:21 +0000 In-Reply-To: <69903.1204047792@sa.vix.com> References: <69903.1204047792@sa.vix.com> To: Paul Vixie Cc: dagon@cc.gatech.edu, namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Roy.Arends@nominet.org.uk Date: Tue, 26 Feb 2008 19:56:18 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/02/2008 06:56:20 PM, Serialize complete at 26/02/2008 06:56:20 PM Content-Type: text/plain; charset="US-ASCII" 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. ] Paul Vixie wrote on 02/26/2008 06:43:12 PM: > This document describes a method by which an initiator can improve > transaction identity using the 0x20 bit in DNS labels. Clever! 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 Thu Feb 28 19:04: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 B33443A68B8; Thu, 28 Feb 2008 19:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, 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 r7hx4QjWRWh1; Thu, 28 Feb 2008 19:04:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 445C03A6872; Thu, 28 Feb 2008 19:04:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUvRo-000CJP-8R for namedroppers-data@psg.com; Fri, 29 Feb 2008 02:58:08 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUvRh-000CIn-SJ for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 02:58:06 +0000 Received: from user-64-9-234-185.googlewifi.com (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 8C56A33C2E; Thu, 28 Feb 2008 18:58:01 -0800 (PST) Date: Thu, 28 Feb 2008 18:58:01 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Graff Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: <47C5B906.7090904@isc.org> References: <69903.1204047792@sa.vix.com> <47C5B906.7090904@isc.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion At Wed, 27 Feb 2008 13:24:54 -0600, Michael Graff wrote: > That is, if you open (say) 64 ports, when speaking with master 1.2.3.4, > you always use port[0], and 1.2.3.5 will always get port[1]. You can > change the ports periodically. > > This means that to discover all known ports (say, if you wanted to fake > a master) you need to know what the port will be. Since a given address > always gets the same port, an attacker would need to have a lot of > addresses to discover all ports. I suspect it's not that helpful, especially such a relatively small number of ports as 64. For example, a professional attacker conducting a bot net would easily identify all the ports. IPv6 may make it even easier (since the attacker can validly send probe queries from millions of source addresses from a single host). --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 29 09:59: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 F3F0D28C597; Fri, 29 Feb 2008 09:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=-0.172, 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 P5RyOwemtn67; Fri, 29 Feb 2008 09:59:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD9E228C2B4; Fri, 29 Feb 2008 09:59:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9IH-000PPb-OP for namedroppers-data@psg.com; Fri, 29 Feb 2008 17:45:13 +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 1JV9I4-000PMZ-GT for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 17:45:07 +0000 Received: from yxu1b27.hopcount.ca ([199.212.90.27]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9I0-000Bd2-LX; Fri, 29 Feb 2008 17:44:56 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <2E7BB4EB-08BD-4E80-AEAA-17CDD8FB02E8@ca.afilias.info> From: Joe Abley To: Paul Vixie In-Reply-To: <48860.1204160051@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: dns-0x20.txt Date: Fri, 29 Feb 2008 12:44:56 -0500 References: <69903.1204047792@sa.vix.com> <72809.1204051801@sa.vix.com> <3870C46029D1F945B1472F170D2D9790038E3F18@de01exm64.ds.mot.com> <48860.1204160051@sa.vix.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 27-Feb-2008, at 19:54, Paul Vixie wrote: > marka has made the revolutionary (to me at least) proposal that once > you've > heard EDNS0 from a responder, you should remember that you did, and > you > should not be willing to believe that they've lost this capability. I'm worried about how you would determine that the responder was the same across subsequent queries sent to the same address and port. Anycast servers provide meat for this concern. If the query frequency is very low, even routine server renumbering or system administration might provide some protein. On the face of it, this proposal does not seem very robust. 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 Fri Feb 29 10:03: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 492DD28C5BD; Fri, 29 Feb 2008 10:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oahrOENZKaI4; Fri, 29 Feb 2008 10:03:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6168B28C2B4; Fri, 29 Feb 2008 10:03:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9Tv-0001u5-GG for namedroppers-data@psg.com; Fri, 29 Feb 2008 17:57:15 +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 1JV9Tk-0001s4-Ks for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 17:57:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4EC991146C; Fri, 29 Feb 2008 17:57:04 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Joe Abley cc: namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt In-Reply-To: Your message of "Fri, 29 Feb 2008 12:44:56 EST." <2E7BB4EB-08BD-4E80-AEAA-17CDD8FB02E8@ca.afilias.info> 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> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 29 Feb 2008 17:57:04 +0000 Message-ID: <54773.1204307824@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > marka has made the revolutionary (to me at least) proposal that once > > you've heard EDNS0 from a responder, you should remember that you did, and > > you should not be willing to believe that they've lost this capability. > > I'm worried about how you would determine that the responder was the same > across subsequent queries sent to the same address and port. NSID? > Anycast servers provide meat for this concern. If the query frequency is > very low, even routine server renumbering or system administration might > provide some protein. > > On the face of it, this proposal does not seem very robust. 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? -- to unsubscribe send a message to namedroppers-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 Feb 29 10:18: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 B536C3A68ED; Fri, 29 Feb 2008 10:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 ELigf03zIdCn; Fri, 29 Feb 2008 10:18:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5743628C647; Fri, 29 Feb 2008 10:17:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9gx-0004TT-Ty for namedroppers-data@psg.com; Fri, 29 Feb 2008 18:10:43 +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 1JV9gi-0004R5-Tu for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 18:10:38 +0000 Received: from yxu1b27.hopcount.ca ([199.212.90.27]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9gh-000BpB-7e; Fri, 29 Feb 2008 18:10:27 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <91770DC3-8CDD-406E-95FE-DB2D2CA77FDF@ca.afilias.info> From: Joe Abley To: Paul Vixie In-Reply-To: <54773.1204307824@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: dns-0x20.txt Date: Fri, 29 Feb 2008 13:10:25 -0500 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> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 29-Feb-2008, at 12:57, Paul Vixie wrote: >>> marka has made the revolutionary (to me at least) proposal that once >>> you've heard EDNS0 from a responder, you should remember that you >>> did, and >>> you should not be willing to believe that they've lost this >>> capability. >> >> I'm worried about how you would determine that the responder was >> the same >> across subsequent queries sent to the same address and port. > > NSID? If we're talking green fields, sure, but I don't think it's reasonable to expect non-EDNS-capable servers to support NSID. >> Anycast servers provide meat for this concern. If the query >> frequency is >> very low, even routine server renumbering or system administration >> might >> provide some protein. >> >> On the face of it, this proposal does not seem very robust. > > 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? EDNS is deployed, though, and DNSSEC (largely) is not, so the practical results of insisting might be very different. 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 Fri Feb 29 10:23: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 2F5C83A6D51; Fri, 29 Feb 2008 10:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 Nn-yRfbD5lN3; Fri, 29 Feb 2008 10:23:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BCE0E3A6DEE; Fri, 29 Feb 2008 10:22:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9oX-00064Z-Nq for namedroppers-data@psg.com; Fri, 29 Feb 2008 18:18:33 +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 1JV9oN-00061T-Q0 for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 18:18:30 +0000 Received: from yxu1b27.hopcount.ca ([199.212.90.27]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV9oM-000BrE-Cs; Fri, 29 Feb 2008 18:18:22 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <2C25D04B-0850-480D-95EE-E410C25F5D09@ca.afilias.info> From: Joe Abley To: Paul Vixie In-Reply-To: <54773.1204307824@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: dns-0x20.txt Date: Fri, 29 Feb 2008 13:18:22 -0500 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> X-Mailer: Apple Mail (2.919.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On 29-Feb-2008, at 12:57, Paul Vixie wrote: >> I'm worried about how you would determine that the responder was >> the same >> across subsequent queries sent to the same address and port. > > NSID? Oh, and NSID doesn't work, unless you have administrative control of all the servers you are talking to, and are able to ensure that the NSID data returned by individual servers is unique. 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 Fri Feb 29 13:58: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 1EE7328C6E7; Fri, 29 Feb 2008 13:58:34 -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 IxwlyXvK5M9t; Fri, 29 Feb 2008 13:58:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F23D03A685C; Fri, 29 Feb 2008 13:57:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVD3m-0000pX-Gp for namedroppers-data@psg.com; Fri, 29 Feb 2008 21:46:30 +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 1JVD2i-0000hN-FJ for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 21:46:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m1TInFxi018537; Fri, 29 Feb 2008 18:49:17 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m1TInBsK018536; Fri, 29 Feb 2008 18:49:11 GMT Date: Fri, 29 Feb 2008 18:49:11 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dns-0x20.txt Message-ID: <20080229184911.GA18505@vacation.karoshi.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> <2C25D04B-0850-480D-95EE-E410C25F5D09@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C25D04B-0850-480D-95EE-E410C25F5D09@ca.afilias.info> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion On Fri, Feb 29, 2008 at 01:18:22PM -0500, Joe Abley wrote: > > On 29-Feb-2008, at 12:57, Paul Vixie wrote: > > >>I'm worried about how you would determine that the responder was > >>the same > >>across subsequent queries sent to the same address and port. > > > >NSID? > > Oh, and NSID doesn't work, unless you have administrative control of > all the servers you are talking to, and are able to ensure that the > NSID data returned by individual servers is unique. > > > Joe I think paul is thinking of anycast as what he calls "owned" anycast, where a single org has the administreative control of all the servers... "unowned" anycast has no such restriction and then your concerns are perfectly valid. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 29 15: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 2988528C6D2; Fri, 29 Feb 2008 15:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=1.158, 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 wDCX5O7EB0Qk; Fri, 29 Feb 2008 15:28:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E2A828C898; Fri, 29 Feb 2008 15:28:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVEXr-0006kM-91 for namedroppers-data@psg.com; Fri, 29 Feb 2008 23:21:39 +0000 Received: from [216.82.253.51] (helo=mail153.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVEXp-0006ju-48 for namedroppers@ops.ietf.org; Fri, 29 Feb 2008 23:21:37 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1204320890!6432205!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 5235 invoked from network); 29 Feb 2008 21:34:50 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-3.tower-153.messagelabs.com with SMTP; 29 Feb 2008 21:34:50 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m1TLYlSu029706 for ; Fri, 29 Feb 2008 14:34:50 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m1TLYkXI004954 for ; Fri, 29 Feb 2008 15:34:47 -0600 (CST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m1TLYjfW004945 for ; Fri, 29 Feb 2008 15:34:46 -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: Fri, 29 Feb 2008 16:34:43 -0500 Message-ID: <3870C46029D1F945B1472F170D2D97900391DDAB@de01exm64.ds.mot.com> In-Reply-To: <48860.1204160051@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns-0x20.txt Thread-Index: Ach5pobx/xr7NbpxTnGcWuOzEkaQOQBb+sbw References: <69903.1204047792@sa.vix.com> <72809.1204051801@sa.vix.com> <3870C46029D1F945B1472F170D2D9790038E3F18@de01exm64.ds.mot.com> <48860.1204160051@sa.vix.com> From: "Eastlake III Donald-LDE008" To: "Paul Vixie" Cc: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Hi, See below... > -----Original Message----- > From: owner-namedroppers@ops.ietf.org=20 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Paul Vixie > Sent: Wednesday, February 27, 2008 7:54 PM > To: namedroppers@ops.ietf.org > Subject: Re: dns-0x20.txt=20 >=20 > > If you are talking about my cookie proposal below (current draft at > >=20 > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cook ies-03.txt) > > I'm not aware of any downgrade attack. Could you enlighten me? >=20 > i hadn't read that and wasn't aware of it, but it's similar=20 > to the idea i > was thinking of, which was first proposed by me during the=20 > work that led > up to the publication of RFC 2671. basically, EDNS0 is=20 > susceptible to a > downgrade attack, and any cookie carried in an OPT RR is=20 > susceptible to > that downgrade attack. That's not exactly true of my proposal. See further below. > if somebody is flooding you with answers that don't have an=20 > OPT RR, and > then injects a query that causes you to go upstream and you=20 > begin by probing > for EDNS0 by including an OPT RR in your upstream query, and=20 > then you open > up the hose that has the answer flood in it, and one of those=20 > answers has > the right port number and query ID in it, then you'll take=20 > it, because you > will think that the other end, that you're just now probing,=20 > doesn't speak > EDNS0. What you are talking about can reasonably be called a flaw, but it isn't really what I understand as a "downgrade attack". The canonical example of a downgrade attack is where you go through some protocol to set up a secure connection but you forget to secure the initial negotiation over what cryptographic algorithm to use. Thus an attacker can always force you to use the weakest algorithm you will accept, that is, downgrade you for all the rest of that session to a less secure cipher or whatever. What you are talking about is a small window which might get some bad data through but, with my proposal, this window does not occur on every transaction but only occasionally (like maybe once a day) for a particular respondent. If you look at Section 5 of http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt you would expect any initial DNS resolvers and servers shipped with this Cookies mechanism to default to the Enabled mode. That way, as soon as they complete one transaction with successful cookies, they latch into Enforced mode as soft state for the particular server or resolver at the other end. This doesn't last forever and they would fall back to Enabled no later than the next time the local secret is reset. Of course, if you know the other end supports cookies and are willing to go to the effort, you can configure the resolver/server to always Enforce cookies for that correspondent and you are then immune to the attack suggested. (Well, 2**64 immune...) Thanks, Donald > i admit this is a slim window but then so is guessing=20 > somebody's PRNG state > and i think that if we're going to try to improve things, we=20 > should improve > them rather than just adding more of the same. like for=20 > example DNSSEC. >=20 > * * * >=20 > marka has made the revolutionary (to me at least) proposal=20 > that once you've > heard EDNS0 from a responder, you should remember that you=20 > did, and you > should not be willing to believe that they've lost this=20 > capability. i'm a > little worried about the cost of that state, and i'm a little=20 > worried about > timing it out in the case of an actual real-world server=20 > downgrade, but i'm > intrigued. >=20 > especially in light of brian's proposal that the probing be=20 > done prospectively > rather than opportunistically. brian, please note, i wanted it done > opportunistically because it would result in zero extra=20 > packets once full > deployment was reached, but in light of subsequent events,=20 > i'd be willing to > say 100% is never going to be reached, and extra packets will=20 > therefore always > be with us, and so we might as well send them prospectively. >=20 > if we do what marka said and we do what brian said, then=20 > cookies can work, > assuming that the prospective probe packet is allowed to=20 > contain a random > string which must be echoed back exactly, so that only a=20 > congestion attack > can prevent the probe from succeeding. (maybe the probe=20 > needs retries.) >=20 > what a hairball. >=20 > -- > to unsubscribe send a message to=20 > 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 Feb 29 23: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 7EC863A6B99; Fri, 29 Feb 2008 23:26:52 -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 bgHJAoA9IpNP; Fri, 29 Feb 2008 23:26:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECFB23A6AEC; Fri, 29 Feb 2008 23:26:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JVLwY-000ABY-Ld for namedroppers-data@psg.com; Sat, 01 Mar 2008 07:15:38 +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 1JVLwT-000AAO-Lc for namedroppers@ops.ietf.org; Sat, 01 Mar 2008 07:15:36 +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 m2170ogJ098411; Sat, 1 Mar 2008 18:00:51 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200803010700.m2170ogJ098411@drugs.dv.isc.org> To: Joe Abley Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: dns-0x20.txt In-reply-to: Your message of "Fri, 29 Feb 2008 13:10:25 CDT." <91770DC3-8CDD-406E-95FE-DB2D2CA77FDF@ca.afilias.info> Date: Sat, 01 Mar 2008 18:00:50 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion > > On 29-Feb-2008, at 12:57, Paul Vixie wrote: > > >>> marka has made the revolutionary (to me at least) proposal that once > >>> you've heard EDNS0 from a responder, you should remember that you > >>> did, and > >>> you should not be willing to believe that they've lost this > >>> capability. > >> > >> I'm worried about how you would determine that the responder was > >> the same > >> across subsequent queries sent to the same address and port. > > > > NSID? > > If we're talking green fields, sure, but I don't think it's reasonable > to expect non-EDNS-capable servers to support NSID. > > >> Anycast servers provide meat for this concern. If the query > >> frequency is > >> very low, even routine server renumbering or system administration > >> might > >> provide some protein. > >> > >> On the face of it, this proposal does not seem very robust. > > > > 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? > > EDNS is deployed, though, and DNSSEC (largely) is not, so the > practical results of insisting might be very different. It's been a implict requirement since EDNS was first published. > 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: -- 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: