From stepladdersuq@sarmasiksanatlar.com Wed Jul 1 07:06:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8153A6B8C; Wed, 1 Jul 2009 07:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.389 X-Spam-Level: X-Spam-Status: No, score=-68.389 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OBujqaCKTcl; Wed, 1 Jul 2009 07:06:12 -0700 (PDT) Received: from 189-46-124-15.dsl.telesp.net.br (189-46-124-15.dsl.telesp.net.br [189.46.124.15]) by core3.amsl.com (Postfix) with ESMTP id 0EE5D28C534; Wed, 1 Jul 2009 07:06:11 -0700 (PDT) Message-ID: <000d01c9fa55$22d999e0$6400a8c0@stepladdersuq> From: dnsext-archive@ietf.org To: Subject: Lose the fat immediately Date: Wed, 1 Jul 2009 11:06:32 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9FA55.22D999E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9FA55.22D999E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Get Noticed with Acai Berry.   How I lost 30 pounds in 30 days With Acai Berry   Knock here   best regards Jorden=20 Floyd     ------=_NextPart_000_0007_01C9FA55.22D999E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Get= Noticed with Acai Berry.
&n= bsp;
How I lost 30 pounds in 30 days With Acai Berry
 
<= A=20 href=3D"http://bcyocyrd.eu.interia.pl">Knock here
 
best regards Jorden=20 Floyd
 
 
------=_NextPart_000_0007_01C9FA55.22D999E0-- From funkierqi697@riverstonemanor.com Wed Jul 1 11:14:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89493A6839; Wed, 1 Jul 2009 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.823 X-Spam-Level: X-Spam-Status: No, score=-19.823 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTCoOVuTd9yw; Wed, 1 Jul 2009 11:14:13 -0700 (PDT) Received: from 200-100-42-230.dial-up.telesp.net.br (200-100-42-230.dial-up.telesp.net.br [200.100.42.230]) by core3.amsl.com (Postfix) with ESMTP id 8A05A3A6832; Wed, 1 Jul 2009 11:13:40 -0700 (PDT) Received: from 200.100.42.230 by riverstonemanor.dyndns.org; Wed, 1 Jul 2009 15:11:32 -0300 Date: Wed, 1 Jul 2009 15:11:32 -0300 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Time to give yourself an Edge over the other guys Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Are you having difficulty viewing our HTML email?
View this email in a browser window.

Your daily reminder

 
Over 550000 men can't be wrong!
 
 

(c) 2009 dvz Inc.

 

This email was delivered to you by Iwqtuoeyn. If you would like to be removed from this email distribution list, please click here. We will honor your request. To report abuse, please click here.

Like this newsletter? Please forward to a friend!

 
From unpreparedzw10@terryhill.com Wed Jul 1 11:45:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4353A6867; Wed, 1 Jul 2009 11:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.371 X-Spam-Level: X-Spam-Status: No, score=-82.371 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbytmJqd4BJR; Wed, 1 Jul 2009 11:45:47 -0700 (PDT) Received: from h141.3.172.72.ip.alltel.net (h141.3.172.72.ip.alltel.net [72.172.3.141]) by core3.amsl.com (Postfix) with ESMTP id 9D8603A67F0; Wed, 1 Jul 2009 11:45:45 -0700 (PDT) Message-ID: <000d01c9fa7c$24e0f0e0$6400a8c0@unpreparedzw10> From: dnsext-archive@lists.ietf.org To: Subject: Free trial of hollywoods weight loss secret Acai Berry. Date: Wed, 1 Jul 2009 13:45:45 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9FA7C.24E0F0E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9FA7C.24E0F0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get the worlds # 1 food Acai Berry in your diet.   #1 Super food , Acai Berry.=20   Enjoy your new body , Get Acai Now.=20               &nb= sp;      =20 Please visit     best regards Patrick=20 Strong ------=_NextPart_000_0007_01C9FA7C.24E0F0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Get the worlds # 1 food Acai Berry in your = diet.
 
#1 Super food , Acai Berry. =
 
Enjoy your new body , Get Acai Now. <= /FONT>
 
          &n= bsp;        =20 Please visit
 
 
best regards Patrick=20 Strong
------=_NextPart_000_0007_01C9FA7C.24E0F0E0-- From philodendradsd770@trabesnor.com Wed Jul 1 16:35:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736AB3A6B79; Wed, 1 Jul 2009 16:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.376 X-Spam-Level: X-Spam-Status: No, score=-79.376 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, JOIN_MILLIONS=1.777, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hXPLqzzCFuM; Wed, 1 Jul 2009 16:35:01 -0700 (PDT) Received: from c-24-0-186-45.hsd1.pa.comcast.net (c-24-0-186-45.hsd1.pa.comcast.net [24.0.186.45]) by core3.amsl.com (Postfix) with ESMTP id 962083A68D7; Wed, 1 Jul 2009 16:35:01 -0700 (PDT) Message-ID: <000d01c9faa4$70eb2910$6400a8c0@philodendradsd770> From: aaa-archive@lists.ietf.org To: Subject: Join millions of Acai Berry users but do it for Free Date: Wed, 1 Jul 2009 19:34:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9FAA4.70EB2910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9FAA4.70EB2910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you experience difficulty viewing=20 this message, you can view it in your browser. =20 =20 =20 eNews June=20 2009 =20 =20 =20 =20 =20 FLush out your bodies toxins and start feeling great with Acai Berry.= Just a small click =20   =20 =20 =20 Update your details | Unsubscribe or edit=20 optionsPlease forward this eNewsletter to a=20 friends ------=_NextPart_000_0007_01C9FAA4.70EB2910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

eNews J= une=20 2009


= FLush out your bodies toxins and start feeling= great with Acai Berry.

Just a small cl= ick
  Update your details | Unsubscribe or edit=20 options
Please forward this eNewsletter to a=20 friends

------=_NextPart_000_0007_01C9FAA4.70EB2910-- From atavismpwk0@tottengroup.com Wed Jul 1 16:42:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507293A6C62; Wed, 1 Jul 2009 16:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.197 X-Spam-Level: X-Spam-Status: No, score=-86.197 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, GB_I_LETTER=-2, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg4INGODrVFb; Wed, 1 Jul 2009 16:42:43 -0700 (PDT) Received: from 229.pool85-57-135.dynamic.orange.es (210.pool85-57-146.dynamic.orange.es [85.57.146.210]) by core3.amsl.com (Postfix) with ESMTP id 429703A6C38; Wed, 1 Jul 2009 16:42:29 -0700 (PDT) Message-ID: <000d01c9faa5$40d15be0$6400a8c0@atavismpwk0> From: action@ietf.org To: Subject: The easiest way to stay in shape Date: Thu, 2 Jul 2009 01:40:02 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9FAA5.40D15BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9FAA5.40D15BE0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable If you experience difficulty viewing=20 this message, you can view it in your browser. =20 =20 =20 eNews June=20 2009 =20 =20 =20 =20 =20 Improve your health with Acai Berry, lose wieght feel great and keep = it off easily.Click on our site =20   =20 =20 =20 Update your details | Unsubscribe or edit=20 optionsPlease forward this eNewsletter to a=20 friends ------=_NextPart_000_0007_01C9FAA5.40D15BE0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

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

eNews J= une=20 2009


<= FONT size=3D4>Improve your health with Acai Berry, lose wieg= ht feel great and keep it off easily.

Click on our sit= e
  Update your details | Unsubscribe or edit=20 options
Please forward this eNewsletter to a=20 friends

------=_NextPart_000_0007_01C9FAA5.40D15BE0-- From owner-namedroppers@ops.ietf.org Thu Jul 2 09:23:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA9A3A6C25; Thu, 2 Jul 2009 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca6YCBaA4INs; Thu, 2 Jul 2009 09:23:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57C503A6BFE; Thu, 2 Jul 2009 09:23:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMP1U-000JWA-Iy for namedroppers-data0@psg.com; Thu, 02 Jul 2009 16:20:32 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMP1I-000JVD-HM for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 16:20:26 +0000 Received: from [192.168.1.104] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n62GKCpp018348; Thu, 2 Jul 2009 12:20:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6E84C5F60655486683DC6009213B02AA@localhost> References: <6E84C5F60655486683DC6009213B02AA@localhost> Date: Thu, 2 Jul 2009 12:20:09 -0400 To: "George Barwood" From: Edward Lewis Subject: Re: [dnsext] Clarification on RFC 2181 Cc: Content-Type: multipart/alternative; boundary="============_-965570880==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-965570880==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 16:49 +0100 7/2/09, George Barwood wrote: >and updates the parent and child zone files. You are confusing authoritative zones and the cache. In RFC 1034, 4.3.2, take a note of step 2: 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. And step 4: 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. The cache is not divided into zones, like the=20 authoritative data is. The significance is that=20 the authoritative data is first divided by zone,=20 then by "location" in the zone. The cache is=20 just a tree representing all else it has. (The=20 name with the NS set is not linked to the name in=20 the NS set, owning the A record.) And then=20 there's the negative cache. (This is why cache=20 servers can't act like authorities.) >When the original A record expires from the resolver cache, the original NS >record will remain for some time, but there is no hope of resolving it. There is hope. There is always hope. The server=20 in question simply asks for the needed A=20 (/address) record. >The resolver will go to the parent, and receive the new NS and A record, >but since the child NS has priority by RFC 2181, the NS will not be replace= d, >and there will be a blackout until the original NS record expires. The NS is not replaced because you aren't asking=20 for that. You do use the A record to ask the=20 query again. >Section 5.4 does state >"The challenge for the server is to determine which of the data sets is > correct, if one is, and retain that, while ignoring the other." > >It seems to me that to avoid problems newly fetched data from the Parent >should replace old child data, but this seems contrary to 5.4.1. > >So I'm feeling somewhat conflicted/confused - help! >=B6-=A7"=E6=ECr=B8=9Bz=C7=A7u=A9=9E"=C6 z=DA'jg=9D=AE=8Aiz=BB+z=AB=9E"=DA)"= '-~=8A=E0=C2+a=B6=17=B0=A2=B7n=9E=CB=9B=B1=CA=E2m=E8=A7j=C8=A7=82W=A5=8Aw=9A= "=D8^=99=EB,j=07-{=1B[=A1=DC=9A-=C8b=BD=E8m=B6=9F=FF=A2=9B"z=D7=E8=AE=0F=E5= =8A=CBl=FEv=A6y=DA=E8=A6=97=AB" =46or some reason, most of the mail I see sent by=20 you (George) has a garbled ending. Just FYI. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-965570880==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] Clarification on RFC 2181
At 16:49 +0100 7/2/09, George Barwood wrote:

>and updates the parent and child zone files.
You are confusing authoritative zones and the cache.

In RFC 1034, 4.3.2, take a note of step 2:

   2. Search the available zones for the zone which is the nearest
      ancestor to QNAME.  If such a zone is found, go to step 3,
      otherwise step 4.
And step 4:

   4. Start matching down in the cache.  If QNAME is found in the
      cache, copy all RRs attached to it that match QTYPE into the
      answer section.  If there was no delegation from
      authoritative data, look for the best one from the cache, and
      put it in the authority section.  Go to step 6.
The cache is not divided into zones, like the authoritative data is.  The significance is that the authoritative data is first divided by zone, then by "location" in the zone.  The cache is just a tree representing all else it has.  (The name with the NS set is not linked to the name in the NS set, owning the A record.)  And then there's the negative cache.  (This is why cache servers can't act like authorities.)

>When the original A record expires from the resolver cache, the original NS
>record will remain for some time, but there is no hope of resolving it.
There is hope.  There is always hope.  The server in question simply asks for the needed A (/address) record.

>The resolver will go to the parent, and receive the new NS and A record,
>but since the child NS has priority by RFC 2181, the NS will not be replaced,
>and there will be a blackout until the original NS record expires.
The NS is not replaced because you aren't asking for that.  You do use the A record to ask the query again.

>Section 5.4 does state
>"The challenge for the server is to determine which of the data sets is
> correct, if one is, and retain that, while ignoring the other."
>
>It seems to me that to avoid problems newly fetched data from the Parent
>should replace old child data, but this seems contrary to 5.4.1.
>
>So I'm feeling somewhat conflicted/confused - help!
>=B6=8B=A7=B2=E6=ECr=B8=9Bz=C7=A7u=A9=9E=B2=C6 z=DA'jg=9D=AE=8Aiz=BB+z=AB=9E=B2=DA)=B2'=AD~=8A=E0=C2+a=B6=17=B0=A2=B7n=9E=CB=9B=B1=CA= =E2m=E8=A7j=C8=A7=82W=A5=8Aw=9A=B2=D8^=99=EB,j=07=AD{=1B[=A1=DC=9A=AD=C8b=BD=E8m=B6=9F=FF=A2=9B"z=D7= =E8=AE=0F=E5=8A=CBl=FEv=A6y=DA=E8=A6=97=AB=B3

For some reason, most of the mail I see sent by you (George) has a garbled ending.  Just FYI.

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-965570880==_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 Jul 2 09:25:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8023A6B78; Thu, 2 Jul 2009 09:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5sm8Kbm2HeR; Thu, 2 Jul 2009 09:25:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9A673A6938; Thu, 2 Jul 2009 09:25:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMOzV-000JNH-Ll for namedroppers-data0@psg.com; Thu, 02 Jul 2009 16:18:29 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMOzK-000JMU-Gg for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 16:18:24 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C6C19A7BD8 for ; Thu, 2 Jul 2009 16:18:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: Your message of "Thu, 02 Jul 2009 16:49:03 +0100." <6E84C5F60655486683DC6009213B02AA@localhost> References: <6E84C5F60655486683DC6009213B02AA@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 02 Jul 2009 16:18:17 +0000 Message-ID: <6907.1246551497@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Thu, 2 Jul 2009 16:49:03 +0100 > ..., it seems that problems can arise if glue A records expire before NS > records. > > Example: > > example.com 432000 NS ns.example.com > ns.example.com 1000 A 1.2.3.4 > > Suppose a resolver has fetched these records from the child zone. > Now suppose that administrator changes the zone to > > example.com 432000 NS ns1.example.com > ns1.example.com 1000 A 1.2.3.4 > > and updates the parent and child zone files. > > When the original A record expires from the resolver cache, the original > NS record will remain for some time, but there is no hope of resolving > it. The resolver will go to the parent, why? the resolver already has a zone cut, it has no reason to iterate through the parent until the zone cut (NS+A) in its cache expires. > and receive the new NS and A > record, as above, it won't be receiving any such new NS+A until it has a reason to iterate through the parent again, which means, until after the current in-cache NS+A expires. > but since the child NS has priority by RFC 2181, the NS will not > be replaced, and there will be a blackout until the original NS record > expires. > > Section 5.4 does state > "The challenge for the server is to determine which of the data sets is > correct, if one is, and retain that, while ignoring the other." > > It seems to me that to avoid problems newly fetched data from the Parent > should replace old child data, but this seems contrary to 5.4.1. > > So I'm feeling somewhat conflicted/confused - help! for this question to be sequitur, you'd have to assume that the recursive server was going to periodically revalidate its cached delegation points. -- to unsubscribe send a message to namedroppers-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 Jul 2 10:05:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9015F3A69BA; Thu, 2 Jul 2009 10:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA8s2z8p8K89; Thu, 2 Jul 2009 10:05:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBBE93A6890; Thu, 2 Jul 2009 10:05:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMPfA-000MuA-00 for namedroppers-data0@psg.com; Thu, 02 Jul 2009 17:01:32 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMPey-000MtM-Lj for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 17:01:26 +0000 Received: from [192.168.1.104] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n62H1EN3018954; Thu, 2 Jul 2009 13:01:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> Date: Thu, 2 Jul 2009 13:00:06 -0400 To: From: Edward Lewis Subject: Re: [dnsext] Clarification on RFC 2181 Cc: "Edward Lewis" Content-Type: multipart/alternative; boundary="============_-965568420==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-965568420==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 17:41 +0100 7/2/09, George Barwood wrote: So asking for the old record will never succeed. The old NS RRset is useless, no good, unstuck, hopeless, dead and buried. The failure there is in the operations, not the protocol, for removing the old A record before caches have time to learn a new (NS) set. Kind of like "Your car will allow you to steer into that tree. Just don't do it." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-965568420==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Clarification on RFC 2181
At 17:41 +0100 7/2/09, George Barwood wrote:

So asking for the old record will never succeed.
The old NS RRset is useless, no good, unstuck, hopeless, dead and buried.
 
The failure there is in the operations, not the protocol, for removing the old A record before caches have time to learn a new (NS) set.

Kind of like "Your car will allow you to steer into that tree.  Just don't do it."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-965568420==_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 Jul 2 11:13:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F503A6DDE; Thu, 2 Jul 2009 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.554, 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 cC0gDO7Kn-OU; Thu, 2 Jul 2009 11:13:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43FFA3A6DDD; Thu, 2 Jul 2009 11:13:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMQhz-0001tm-V3 for namedroppers-data0@psg.com; Thu, 02 Jul 2009 18:08:31 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMQho-0001sw-Ky for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 18:08:26 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n62I8IQQ019693; Thu, 2 Jul 2009 14:08:18 -0400 (EDT) (envelope-from ogud@ogud.com) Received: from localhost (ogud@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) with ESMTP id n62I8HFW019690; Thu, 2 Jul 2009 14:08:18 -0400 (EDT) (envelope-from ogud@ogud.com) X-Authentication-Warning: stora.ogud.com: ogud owned process doing -bs Date: Thu, 2 Jul 2009 14:08:17 -0400 (EDT) From: Olafur Gudmundsson To: George Barwood cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: <6E84C5F60655486683DC6009213B02AA@localhost> Message-ID: References: <6E84C5F60655486683DC6009213B02AA@localhost> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 2 Jul 2009, George Barwood wrote: > RFC 2181, section 5.4.1 makes it clear that the NS from a child is > "more trustworthy" than a NS from the parent. I have some issues with this > notion of "trust", since both parent and child must be trusted regardless. > But leaving that aside, it seems that problems can arise if glue A records > expire before NS records. > > Example: > > example.com 432000 NS ns.example.com > ns.example.com 1000 A 1.2.3.4 > > Suppose a resolver has fetched these records from the child zone. > Now suppose that administrator changes the zone to > > example.com 432000 NS ns1.example.com > ns1.example.com 1000 A 1.2.3.4 > > and updates the parent and child zone files. Operator error, there is nothing that the protocol can do to prevent mistakes like this cause problems. DNS has number of timing windows that have to be respected or things cani/will go wrong, in this case: ns.example.com should not have been removed until after all instances of the prior NS set had expired from caches. 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 Jul 2 11:39:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFC03A6A36; Thu, 2 Jul 2009 11:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNku+++mfIAf; Thu, 2 Jul 2009 11:39:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47C8F3A6B7C; Thu, 2 Jul 2009 11:39:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMR7i-0004EG-Ol for namedroppers-data0@psg.com; Thu, 02 Jul 2009 18:35:06 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMR7T-0004Cc-0y for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 18:35:01 +0000 Received: by ewy3 with SMTP id 3so2037876ewy.41 for ; Thu, 02 Jul 2009 11:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=9vU4wPVKCO4nQWBTGQDFsHN4YUXPEgosu3JSUQOJ4R4=; b=WZefcG2WTVVfTElLI5A9/9jBtJv5TiAjX8+y70gCqKt6lgQ0Q5a5SlMQFnhVygLk38 3wCGx/ZstxKHJlALU7XKl8W4B06hgvzpm207Mj6EjjYFJBCPRL37Z+wtugSUSHZspEf7 AR2SJxz1A0byiDz5DhH7WzHXwsh+/bjmfTJwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Q/CaDyHXMmL+yOoo53E7jHuszIxQn4LFOCW6MnyjtI7XY29eghLxiFfGFvqrQZICIa VrNDvxg+He2tGIz9cN+WUixDizlfxM9USB+hLKjT3xpK61XFfP1Zs5+uhr44Pl77XUz/ Du+5xDDISBvcMHyATSnZITmGGYUj3LVSQmXts= MIME-Version: 1.0 Received: by 10.211.178.12 with SMTP id f12mr1290568ebp.98.1246559689119; Thu, 02 Jul 2009 11:34:49 -0700 (PDT) In-Reply-To: <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> From: bert hubert Date: Thu, 2 Jul 2009 20:34:29 +0200 Message-ID: <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> Subject: Re: [dnsext] Clarification on RFC 2181 To: George Barwood Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 2, 2009 at 6:41 PM, George Barwood wrote: > So asking for the old record will never succeed. > The old NS RRset is useless, no good, unstuck, hopeless, dead and buried. You'll find that all 'heavy duty' resolvers have code to deal with 'useless rrsets' to make sure parents are (re-)consulted, but not too often. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From spicedbj0@sarle.com Thu Jul 2 12:43:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D9C3A6DE7; Thu, 2 Jul 2009 12:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.453 X-Spam-Level: X-Spam-Status: No, score=-65.453 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4a+d39-c3Fy; Thu, 2 Jul 2009 12:43:39 -0700 (PDT) Received: from host198-215-static.40-88-b.business.telecomitalia.it (host198-215-static.40-88-b.business.telecomitalia.it [88.40.215.198]) by core3.amsl.com (Postfix) with ESMTP id 58D483A6BF1; Thu, 2 Jul 2009 12:43:39 -0700 (PDT) Received: from 88.40.215.198 by eforwardct.name-services.com; Thu, 2 Jul 2009 21:43:10 +0100 Content-type: text/html; charset="iso-8859-2" MIME-Version: 1.0 Message-ID: Date: Thu, 2 Jul 2009 21:43:10 +0100 From: "Carina Gillis" To: aaa-archive@lists.ietf.org Subject: How about buying yourself a two Bvlgari watches the same day? It's not impossible, mostly when you can get them for a couple hundred bucks Look rich and successful without having to spend thousands. Nothing impresses business colleagues and friends more than a diamond studded Patek Philippe, or a classic Brethling strapped around your wrist. Our e-store houses more than 20+ world famous brands. Prices for the originals range in the tends of thousands, but pick up a buy for just $199 up. Sale ends this week - so visit now for the best bargains. Site for everybody http://ourbestwatchs.net Carina Gillis (Norway) Thanks! www.ourbestwatchs.net From speedierlu194@markglenn.com Thu Jul 2 12:48:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305823A6BF1; Thu, 2 Jul 2009 12:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.201 X-Spam-Level: X-Spam-Status: No, score=-34.201 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+E3WQ8RWamS; Thu, 2 Jul 2009 12:48:27 -0700 (PDT) Received: from pool-70-22-71-251.balt.east.verizon.net (pool-70-22-15-161.balt.east.verizon.net [70.22.15.161]) by core3.amsl.com (Postfix) with ESMTP id 357FA3A6DE2; Thu, 2 Jul 2009 12:48:26 -0700 (PDT) Received: from 70.22.15.161 by markglenn.com.inbound10.luxsci.com; Thu, 2 Jul 2009 15:48:45 -0500 Content-type: text/html; charset="UTF-8" MIME-Version: 1.0 Message-ID: <7YBEQY.LZZ8JR5.38518802557MLAGKCKL4013@2761.70.22.15.161> Date: Thu, 2 Jul 2009 15:48:45 -0500 From: "Ashton Aragon" To: dnsext-archive@ietf.org Subject: Purchase 2 watches and receive 15% discount! Look rich and successful without having to spend thousands. Nothing impresses business colleagues and friends more than a diamond studded Rolex, or a classic Panerai strapped around your wrist. Our e-store houses more than 20+ world famous brands. Prices for the originals range in the tends of thousands, but pick up a buy for just $199 up. Sale ends this week - so visit now for the best bargains. Get in http://ourbestwatchs.net Ashton Aragon (IT) Thanks! www.ourbestwatchs.net From cosmogol-bounces@ietf.org Thu Jul 2 12:48:30 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006373A6DE8 for ; Thu, 2 Jul 2009 12:48:30 -0700 (PDT) Subject: The results of your email commands From: cosmogol-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1897264536==" Message-ID: Date: Thu, 02 Jul 2009 12:48:29 -0700 Precedence: bulk X-BeenThere: cosmogol@ietf.org X-Mailman-Version: 2.1.9 List-Id: DIscussion on state machine specification in IETF protocols X-List-Administrivia: yes Sender: cosmogol-bounces@ietf.org Errors-To: cosmogol-bounces@ietf.org --===============1897264536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============1897264536== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: cosmogol-request@core3.amsl.com Delivered-To: cosmogol-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305823A6BF1; Thu, 2 Jul 2009 12:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.201 X-Spam-Level: X-Spam-Status: No, score=-34.201 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+E3WQ8RWamS; Thu, 2 Jul 2009 12:48:27 -0700 (PDT) Received: from pool-70-22-71-251.balt.east.verizon.net (pool-70-22-15-161.balt.east.verizon.net [70.22.15.161]) by core3.amsl.com (Postfix) with ESMTP id 357FA3A6DE2; Thu, 2 Jul 2009 12:48:26 -0700 (PDT) Received: from 70.22.15.161 by markglenn.com.inbound10.luxsci.com; Thu, 2 Jul 2009 15:48:45 -0500 Content-type: text/html; charset="UTF-8" MIME-Version: 1.0 Message-ID: <7YBEQY.LZZ8JR5.38518802557MLAGKCKL4013@2761.70.22.15.161> Date: Thu, 2 Jul 2009 15:48:45 -0500 From: "Ashton Aragon" To: dnsext-archive@ietf.org Subject: Purchase 2 watches and receive 15% discount! Look rich and successful without having to spend thousands. Nothing impresses business colleagues and friends more than a diamond studded Rolex, or a classic Panerai strapped around your wrist. Our e-store houses more than 20+ world famous brands. Prices for the originals range in the tends of thousands, but pick up a buy for just $199 up. Sale ends this week - so visit now for the best bargains. Get in http://ourbestwatchs.net Ashton Aragon (IT) Thanks! www.ourbestwatchs.net --===============1897264536==-- From diffserv-interest-bounces@ietf.org Thu Jul 2 12:48:30 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044603A6DE8 for ; Thu, 2 Jul 2009 12:48:30 -0700 (PDT) Subject: The results of your email commands From: diffserv-interest-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0998933341==" Message-ID: Date: Thu, 02 Jul 2009 12:48:29 -0700 Precedence: bulk X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.9 List-Id: Differentiated services general discussion X-List-Administrivia: yes Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org --===============0998933341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============0998933341== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: diffserv-interest-request@core3.amsl.com Delivered-To: diffserv-interest-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305823A6BF1; Thu, 2 Jul 2009 12:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.201 X-Spam-Level: X-Spam-Status: No, score=-34.201 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+E3WQ8RWamS; Thu, 2 Jul 2009 12:48:27 -0700 (PDT) Received: from pool-70-22-71-251.balt.east.verizon.net (pool-70-22-15-161.balt.east.verizon.net [70.22.15.161]) by core3.amsl.com (Postfix) with ESMTP id 357FA3A6DE2; Thu, 2 Jul 2009 12:48:26 -0700 (PDT) Received: from 70.22.15.161 by markglenn.com.inbound10.luxsci.com; Thu, 2 Jul 2009 15:48:45 -0500 Content-type: text/html; charset="UTF-8" MIME-Version: 1.0 Message-ID: <7YBEQY.LZZ8JR5.38518802557MLAGKCKL4013@2761.70.22.15.161> Date: Thu, 2 Jul 2009 15:48:45 -0500 From: "Ashton Aragon" To: dnsext-archive@ietf.org Subject: Purchase 2 watches and receive 15% discount! Look rich and successful without having to spend thousands. Nothing impresses business colleagues and friends more than a diamond studded Rolex, or a classic Panerai strapped around your wrist. Our e-store houses more than 20+ world famous brands. Prices for the originals range in the tends of thousands, but pick up a buy for just $199 up. Sale ends this week - so visit now for the best bargains. Get in http://ourbestwatchs.net Ashton Aragon (IT) Thanks! www.ourbestwatchs.net --===============0998933341==-- From owner-namedroppers@ops.ietf.org Thu Jul 2 13:05:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8766A28C1A0; Thu, 2 Jul 2009 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjAXWdJ5zh9F; Thu, 2 Jul 2009 13:05:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAC083A68EE; Thu, 2 Jul 2009 13:05:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSST-000BzI-EJ for namedroppers-data0@psg.com; Thu, 02 Jul 2009 20:00:37 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSSH-000Bxu-Vm for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 20:00:31 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id E18713A6BF1; Thu, 2 Jul 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090702200001.E18713A6BF1@core3.amsl.com> Date: Thu, 2 Jul 2009 13:00:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Proxy Implementation Guidelines Author(s) : R. Bellis Filename : draft-ietf-dnsext-dnsproxy-06.txt Pages : 14 Date : 2009-07-02 This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnsproxy-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-02125310.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 2 13:38:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B3E3A6DE7; Thu, 2 Jul 2009 13:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ima2ODFl15dq; Thu, 2 Jul 2009 13:38:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 596D03A6DF8; Thu, 2 Jul 2009 13:38:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSxk-000EnZ-G4 for namedroppers-data0@psg.com; Thu, 02 Jul 2009 20:32:56 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSxY-000Emy-6Z for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 20:32:50 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id 622567C900; Thu, 2 Jul 2009 20:32:42 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 9D95475F61; Thu, 2 Jul 2009 23:32:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19021.6478.381852.351820@guava.gson.org> Date: Thu, 2 Jul 2009 23:32:14 +0300 To: namedroppers@ops.ietf.org Cc: bert hubert , George Barwood Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.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: bert hubert wrote: > You'll find that all 'heavy duty' resolvers have code to deal with > 'useless rrsets' to make sure parents are (re-)consulted, but not too > often. It's clear from RFC1035 that you sometimes have to re-consult the parent: The resolver may encounter a situation where no addresses are available for any of the name servers named in SLIST, and where the servers in the list are precisely those which would normally be used to look up their own addresses. This situation typically occurs when the glue address RRs have a smaller TTL than the NS RRs marking delegation, or when the resolver caches the result of a NS search. The resolver should detect this condition and restart the search at the next ancestor zone, or alternatively at the root. The question is, when you do have to re-consult the parent (or "restart the search" as RFC1035 puts it), do you override the NS RRset you already have (but for which you have no addresses) with the new one you get from the parent, even if the one you have was obtained from an "authoritative" source and the new one was not? My take is that you do override it, RFC2181 be damned. Preferring authoritative data over non-authoritative is fine for the purpose of constructing responses to clients, but it's a bad idea for the purpose of determining which servers to query. People tend get hung up on the term "authoritative". The way it's defined, the NS records on the child side are "authoritative" and the ones on the parent side are not. But the authority of the child stems from a delegation, and that delegation is granted by the parent, not just asserted by the child. If it weren't for the non-authoritative NS records in the parent, the child wouldn't be authoritative for its NS records in the first place. A resolver must respect the parent's prerogative to delegate, redelegate, and withdraw delegation from its children, which is more fundamental than the child's right to be considered "authoritative". If a resolver prefers the child's authoritative NS records over the parent's delegating NS records for the purpose of determining who is the correct delegee, it will not only be subject to the problem George described (which I'm sure can be worked around in other ways), but will also be vulnerable to other issues, such as former domain owners hanging on to domains they no longer own by continuing to publish their old "authoritative" NS records, perhaps with huge TTLs. -- 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 Thu Jul 2 13:38:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA673A6DE7; Thu, 2 Jul 2009 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.187 X-Spam-Level: X-Spam-Status: No, score=-4.187 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA9jy9DiynbP; Thu, 2 Jul 2009 13:38:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 101BD3A6906; Thu, 2 Jul 2009 13:38:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSyd-000EvW-Dk for namedroppers-data0@psg.com; Thu, 02 Jul 2009 20:33:51 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSyM-000ErG-6A for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 20:33:44 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=r9RcCBrGZWX0SDIgED4Q1tKOFuwInxTWUKAODcEft6JmFSXCtmJueHou WxgWo9nYtQWbi6crKV6hFSM2sW4coWFmx7L4x9McmN0vgohZU3kINev3x MlDpc4IzJ0rp68x; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246566814; x=1278102814; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20I-D=20Action:draft-ietf-dnsext-dnsproxy-06.txt |Date:=20Thu,=202=20Jul=202009=2021:33:28=20+0100 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0|In-Reply-To:=20<2009070220000 1.E18713A6BF1@core3.amsl.com>|References:=20<200907022000 01.E18713A6BF1@core3.amsl.com>; bh=wtSctvr1uv5eB6HQYz9xa48iEIXO+UKJW7o2yMWJCVs=; b=2E4VygvuJPi35AlFy99v4tu8Jf73Zc7RqCP23PrroWjhcm4LnKFvwel5 Xgh9b/bIYuARWFQZpUmbjekd54Dt8TRBGCFlkj/KpwNED0OdKRL+HCQXP TtTv9v6D49ZNr3g; X-IronPort-AV: E=Sophos;i="4.42,337,1243810800"; d="scan'208";a="15352400" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 02 Jul 2009 21:33:30 +0100 In-Reply-To: <20090702200001.E18713A6BF1@core3.amsl.com> References: <20090702200001.E18713A6BF1@core3.amsl.com> To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 2 Jul 2009 21:33:28 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 02/07/2009 09:33:31 PM, Serialize complete at 02/07/2009 09:33:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0070EDA7802575E7_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0070EDA7802575E7_= Content-Type: text/plain; charset="US-ASCII" > Title : DNS Proxy Implementation Guidelines > Author(s) : R. Bellis > Filename : draft-ietf-dnsext-dnsproxy-06.txt > Pages : 14 > Date : 2009-07-02 This update addresses comments from AD review: Section 4.1 - cleaned up tautological language and changed SHOULD to MUST (Adrian Farrel) Section 4.4.1 - made TCP support mandatory (from Lars Eggert) Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko) Section 6.3 - clarified rationale for handling errors (from Robert Sparks) Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0070EDA7802575E7_= Content-Type: text/html; charset="US-ASCII"
>    Title           : DNS Proxy Implementation Guidelines
>    Author(s)       : R. Bellis
>    Filename        : draft-ietf-dnsext-dnsproxy-06.txt
>    Pages           : 14
>    Date            : 2009-07-02

This update addresses comments from AD review:

      Section 4.1 - cleaned up tautological language and changed SHOULD
      to MUST (Adrian Farrel)
      Section 4.4.1 - made TCP support mandatory (from Lars Eggert)
      Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko)
      Section 6.3 - clarified rationale for handling errors (from Robert
      Sparks)

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
--=_alternative 0070EDA7802575E7_=-- -- to unsubscribe send a message to namedroppers-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 Jul 2 16:07:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8D03A6B60; Thu, 2 Jul 2009 16:07:45 -0700 (PDT) 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 Lg6pX6YsoTqX; Thu, 2 Jul 2009 16:07:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BE2C3A6ABA; Thu, 2 Jul 2009 16:07:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMVHI-0002lG-G4 for namedroppers-data0@psg.com; Thu, 02 Jul 2009 23:01:16 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMVH7-0002kI-0S for namedroppers@ops.ietf.org; Thu, 02 Jul 2009 23:01:10 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3687EA7C5B for ; Thu, 2 Jul 2009 23:01:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: Your message of "Thu, 02 Jul 2009 23:32:14 +0300." <19021.6478.381852.351820@guava.gson.org> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 02 Jul 2009 23:01:04 +0000 Message-ID: <29210.1246575664@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Thu, 2 Jul 2009 23:32:14 +0300 > From: gson@araneus.fi (Andreas Gustafsson) > > bert hubert wrote: > > You'll find that all 'heavy duty' resolvers have code to deal with > > 'useless rrsets' to make sure parents are (re-)consulted, but not too > > often. > > ... > > My take is that you do override it, RFC2181 be damned. Preferring > authoritative data over non-authoritative is fine for the purpose of > constructing responses to clients, but it's a bad idea for the purpose of > determining which servers to query. > > ... so a reasonable policy might be that if all nameserver names are unreachable then put the delegation in a hold-down state for 180+random(90) seconds during which you servfail all queries requiring that delegation be followed, and then discard the NS RRset, so that subsequent queries will cause re-iteration via the parent, hopefully to get reachable nameservers next time? this fits with RFC 2181 since by the time new delegation responses come from the parent, the previously-cached child apex NS RRset will be gone. it also leaves it up to the zone's editor/operator to complete screw himself/herself if the parent's delegation results in reachability whereas the child apex NS RRset results in unreachability. that problem should remain out of scope! -- to unsubscribe send a message to namedroppers-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 Jul 2 18:49:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118AC3A6C53; Thu, 2 Jul 2009 18:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuHRbVYE+GUU; Thu, 2 Jul 2009 18:49:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 018693A683F; Thu, 2 Jul 2009 18:49:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMXp2-000E1I-HW for namedroppers-data0@psg.com; Fri, 03 Jul 2009 01:44:16 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMXor-000E0X-8U for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 01:44:10 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0D672E606E; Fri, 3 Jul 2009 01:44:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n631hgvr046341; Fri, 3 Jul 2009 11:43:42 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907030143.n631hgvr046341@drugs.dv.isc.org> To: Edward Lewis Cc: "George Barwood" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Clarification on RFC 2181 In-reply-to: Your message of "Thu, 02 Jul 2009 12:20:09 -0400." Date: Fri, 03 Jul 2009 11:43:42 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Edward Lewis writes: > For some reason, most of the mail I see sent by > you (George) has a garbled ending. Just FYI. This is the mailing list software adding this to the end of a base64 encoded body without adding a new mime section. I've complained about this already but no-one seems to want to fix / upgrade the mailing list software. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Adding it either makes the messages completely unreadable or adds "garbage" to the end. In neither case does the information make it through. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From flyersdet@pierreb.net Thu Jul 2 19:00:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751303A6C54; Thu, 2 Jul 2009 19:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.728 X-Spam-Level: X-Spam-Status: No, score=-16.728 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SUBJECT_FUZZY_TION=0.156, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnV+huPAqjOU; Thu, 2 Jul 2009 19:00:25 -0700 (PDT) Received: from 189-46-217-203.dsl.telesp.net.br (189-46-217-203.dsl.telesp.net.br [189.46.217.203]) by core3.amsl.com (Postfix) with ESMTP id B19473A6C78; Thu, 2 Jul 2009 18:59:34 -0700 (PDT) Received: from 189.46.217.203 by mx1.daemonmail.net; Thu, 2 Jul 2009 22:58:06 -0300 From: ee10121c2@ietf.org To: ee10121c2@ietf.org Subject: Competition for women can be fierce guys Date: Thu, 2 Jul 2009 22:58:06 -0300 Message-ID: MIME-version: 1.0 Content-type: text/html; charset="utf-8"
Are you having difficulty viewing our HTML email?
View this email in a browser window.

Your daily reminder

 
The number one male growth solution
 
 

(c) 2009 slas Inc.

 

This email was delivered to you by Iwqtuoeyn. If you would like to be removed from this email distribution list, please click here. We will honor your request. To report abuse, please click here.

Like this newsletter? Please forward to a friend!

 
From operableecr1@totaea.com Fri Jul 3 00:56:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2C43A6CE2; Fri, 3 Jul 2009 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.203 X-Spam-Level: X-Spam-Status: No, score=-31.203 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_DYNAMIC_SPLIT_IP=3.493, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3LbBvT3dP1y; Fri, 3 Jul 2009 00:56:58 -0700 (PDT) Received: from 67.sub-75-216-246.myvzw.com (46.sub-75-216-219.myvzw.com [75.216.219.46]) by core3.amsl.com (Postfix) with ESMTP id E26FF3A6CE7; Fri, 3 Jul 2009 00:55:49 -0700 (PDT) Date: Fri, 3 Jul 2009 00:56:11 -0800 Message-Id: <0AWPJR93768.MD483QNB7X90923@75.216.219.46.totaea.com> From: dix@ietf.org To: dix@ietf.org Subject: Doesn't Keep You Up At Night...Stimulant Free Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
don't let food be your greatest concern.
 
focus and attack, look great with no further delay, feel it for free
 
Acai Super Berry Capsules, you will love your new body.
 
                    Asking you to click
 
 
best regards Judi Callahan
From owner-namedroppers@ops.ietf.org Fri Jul 3 02:18:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BAA83A6C7B; Fri, 3 Jul 2009 02:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIoQwjPfZ8F4; Fri, 3 Jul 2009 02:18:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BED93A6BAB; Fri, 3 Jul 2009 02:18:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMenT-000J1l-Lt for namedroppers-data0@psg.com; Fri, 03 Jul 2009 09:11:07 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMenI-000J0f-QV for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 09:11:02 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id 45D437C418; Fri, 3 Jul 2009 09:10:54 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 7FC9E75F61; Fri, 3 Jul 2009 12:10:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19021.51994.80438.865585@guava.gson.org> Date: Fri, 3 Jul 2009 12:10:50 +0300 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: <29210.1246575664@nsa.vix.com> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.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: Paul Vixie wrote: > so a reasonable policy might be that if all nameserver names are unreachable > then put the delegation in a hold-down state for 180+random(90) seconds during > which you servfail all queries requiring that delegation be followed, and then > discard the NS RRset, so that subsequent queries will cause re-iteration via > the parent, hopefully to get reachable nameservers next time? When you say "nameserver names are unreachable", do you mean we lack addresses for them or that we have addresses but fail to get a response when querying them? To be clear, I'm talking about the former case. Discarding the cached NS RRset is a resonable way to force the resolution process to restart at the parent, but I don't see a need to force SERVFAILs or to wait for a hold-down period. You can immediately restart the current resolution using the pruned cache, taking care to avoid infinite loops as always. -- 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 Jul 3 02:28:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2600B28C178; Fri, 3 Jul 2009 02:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.642 X-Spam-Level: X-Spam-Status: No, score=0.642 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 Ys4Vz+2oH2ji; Fri, 3 Jul 2009 02:28:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 193003A685D; Fri, 3 Jul 2009 02:28:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMf0y-000Jyf-Vh for namedroppers-data0@psg.com; Fri, 03 Jul 2009 09:25:04 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMf0j-000JxT-EV for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 09:24:59 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MMf3a-0008Az-QJ; Fri, 03 Jul 2009 11:27:46 +0200 Received: by bfk.de with local id 1MMf0c-0002R7-Dz; Fri, 03 Jul 2009 09:24:42 +0000 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> From: Florian Weimer Date: Fri, 03 Jul 2009 09:24:42 +0000 In-Reply-To: <29210.1246575664@nsa.vix.com> (Paul Vixie's message of "Thu\, 02 Jul 2009 23\:01\:04 +0000") Message-ID: <82fxdep19h.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: * Paul Vixie: > so a reasonable policy might be that if all nameserver names are unreacha= ble > then put the delegation in a hold-down state for 180+random(90) seconds d= uring > which you servfail all queries requiring that delegation be followed, and= then > discard the NS RRset, so that subsequent queries will cause re-iteration = via > the parent, hopefully to get reachable nameservers next time? Sure, seems to make sense, and it's claimed regularly that this such a common practice (with too agressive probing) that large zone operators have a vested interest in delegations working almost all the time. If resolver implementors actually implemented this---and something very similar for a certain range of validation failures, we wouldn't have to talk about how to properly handle NS/DS migrations. But I believe this merely a quality-of-implementation issue for resolvers. It's not something the protocol specs should be concerned with. A "how to be a good citizen's resolver' document would probably cover it, but the protocol specs always allow to discard cache contents for protocol-external reasons (all cache management is just that). --=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 Jul 3 02:58:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43D028C1FE; Fri, 3 Jul 2009 02:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 g-je83meanDX; Fri, 3 Jul 2009 02:58:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F21F228C133; Fri, 3 Jul 2009 02:58:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMfTa-000MU0-RE for namedroppers-data0@psg.com; Fri, 03 Jul 2009 09:54:38 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMfTP-000MST-Sc for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 09:54:33 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MMfWH-0003gz-3u; Fri, 03 Jul 2009 11:57:25 +0200 Received: by bfk.de with local id 1MMfTI-0005WB-MP; Fri, 03 Jul 2009 09:54:20 +0000 To: gson@araneus.fi (Andreas Gustafsson) Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> From: Florian Weimer Date: Fri, 03 Jul 2009 09:54:20 +0000 In-Reply-To: <19021.51994.80438.865585@guava.gson.org> (Andreas Gustafsson's message of "Fri\, 3 Jul 2009 12\:10\:50 +0300") Message-ID: <82zlbmnlbn.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: * Andreas Gustafsson: > Discarding the cached NS RRset is a resonable way to force the > resolution process to restart at the parent, but I don't see a need > to force SERVFAILs or to wait for a hold-down period. You can > immediately restart the current resolution using the pruned cache, > taking care to avoid infinite loops as always. This will essentiall turn off caching of delegations where the child zone is misconfigured in a particular way. This may not be a good idea. I think you should back off instead, not flooding the parent zone with queries. --=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 Jul 3 03:18:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66893A6BB3; Fri, 3 Jul 2009 03:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[AWL=-0.153, 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 UX5wJFBugzci; Fri, 3 Jul 2009 03:18:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD43E3A6A1A; Fri, 3 Jul 2009 03:18:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMfmC-000O5p-Cj for namedroppers-data0@psg.com; Fri, 03 Jul 2009 10:13:52 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMfm0-000O4K-2n for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 10:13:46 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MMfou-0006dc-Ua; Fri, 03 Jul 2009 12:16:41 +0200 Received: by bfk.de with local id 1MMflw-0001eY-AE; Fri, 03 Jul 2009 10:13:36 +0000 To: Ray.Bellis@nominet.org.uk Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt References: <20090702200001.E18713A6BF1@core3.amsl.com> From: Florian Weimer Date: Fri, 03 Jul 2009 10:13:36 +0000 In-Reply-To: (Ray Bellis's message of "Thu\, 2 Jul 2009 21\:33\:28 +0100") Message-ID: <82vdmankfj.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: * Ray Bellis: > Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko) At the DNS layer, you can't pass through EDNS0 without actually understanding it. For example, I think you should drop options which you don't implement because they could result in a reply you can't process, and you have no way to signal this failure to your downstream recipient. You can't even attribute it to a particular option. If you want to handle EDNS0, you really have to mandate clear UDP and TCP channels to the actual DNS servers, as if the proxy was performing destination NAT. No payload inspection is allowed, and certainly no caching. This is somewhat at odds with language in section 6.1, which suggests that it's okay with the draft if the proxy changes transaction IDs, as long as it properly randomizes them. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Jul 3 03:55:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEF928C19D; Fri, 3 Jul 2009 03:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.182 X-Spam-Level: X-Spam-Status: No, score=-4.182 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80vsjvjRBY82; Fri, 3 Jul 2009 03:55:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B12433A6863; Fri, 3 Jul 2009 03:55:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMgMj-0001A4-Cj for namedroppers-data0@psg.com; Fri, 03 Jul 2009 10:51:37 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMgMX-000198-Qh; Fri, 03 Jul 2009 10:51:31 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=gTHwYchCH2gpFDA6JGCp5IufqZssGKVsPSZiGq5xJOJJbMCJYGVc+Gth 6aOgrnt1FgngR2cVGP9Y4t8HbXMmaursyJ+DynoHg/la4rfuWfucqOAoU P0RuQMeRUfD7leG; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246618285; x=1278154285; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20I-D=20Action:draft-ietf-dnsext-dnsproxy-06.txt |Date:=20Fri,=203=20Jul=202009=2011:51:10=20+0100 |Message-ID:=20|To:=20Florian=20Weimer =20|Cc:=20namedroppers@ops.ietf.org,=0D =0A=09owner-namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<82vdmankfj.fsf@mid.bfk.de>|References: =20<20090702200001.E18713A6BF1@core3.amsl.com>=09=20<82vdmankfj.fsf@mid.bfk.de>; bh=s+KpOpEH53zO4qUNbo7n5sRQ4uM7YBd0LiVxo7cuT88=; b=pPoIoKmz2wiYuU3j/pQk6dpSWHglkTCNKEYK4ReJ1+pBDoNwro48+UZ0 Fch2bdDi6U0ZJ+LnmSHtwBWMAm5fuchCrkqaMEuNNj2LwKwpXVWPzM84C /oIoFWuIq2I4T8F; X-IronPort-AV: E=Sophos;i="4.42,341,1243810800"; d="scan'208";a="11221132" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Jul 2009 11:51:13 +0100 In-Reply-To: <82vdmankfj.fsf@mid.bfk.de> References: <20090702200001.E18713A6BF1@core3.amsl.com> <82vdmankfj.fsf@mid.bfk.de> To: Florian Weimer Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 3 Jul 2009 11:51:10 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2009 11:51:15 AM, Serialize complete at 03/07/2009 11:51:15 AM Content-Type: multipart/alternative; boundary="=_alternative 003B9DE3802575E8_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 003B9DE3802575E8_= Content-Type: text/plain; charset="US-ASCII" > At the DNS layer, you can't pass through EDNS0 without actually > understanding it. Actually many DNS proxies do "pass-through" EDNS0 perfectly happily, because those proxies literally do almost nothing except forward the packet to an upstream resolver. They pretty much do provide the clear channel that you mention below. The only time this is a problem is if the EDNS0 buffer size sent by the client is larger than the maximum response size that the proxy itself can handle. > If you want to handle EDNS0, you really have to mandate clear UDP and > TCP channels to the actual DNS servers, as if the proxy was performing > destination NAT. No payload inspection is allowed, and certainly no > caching. This is somewhat at odds with language in section 6.1, which > suggests that it's okay with the draft if the proxy changes > transaction IDs, as long as it properly randomizes them. TBH I can't recall exactly _why_ some proxies generate their own transaction IDs. It is the only packet modification that's allowable without breaking TSIG though. Ray --=_alternative 003B9DE3802575E8_= Content-Type: text/html; charset="US-ASCII"
> At the DNS layer, you can't pass through EDNS0 without actually
> understanding it.


Actually many DNS proxies do "pass-through" EDNS0 perfectly happily, because those proxies literally do almost nothing except forward the packet to an upstream resolver.  They pretty much do provide the clear channel that you mention below.

The only time this is a problem is if the EDNS0 buffer size sent by the client is larger than the maximum response size that the proxy itself can handle.

> If you want to handle EDNS0, you really have to mandate clear UDP and
> TCP channels to the actual DNS servers, as if the proxy was performing
> destination NAT.  No payload inspection is allowed, and certainly no
> caching.  This is somewhat at odds with language in section 6.1, which
> suggests that it's okay with the draft if the proxy changes
> transaction IDs, as long as it properly randomizes them.

TBH I can't recall exactly _why_ some proxies generate their own transaction IDs.  It is the only packet modification that's allowable without breaking TSIG though.

Ray
--=_alternative 003B9DE3802575E8_=-- -- to unsubscribe send a message to namedroppers-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 Jul 3 04:39:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34BE3A6AFF; Fri, 3 Jul 2009 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlYoWcm4+iuo; Fri, 3 Jul 2009 04:39:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5561E3A6E54; Fri, 3 Jul 2009 04:39:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMh0t-0004C5-KN for namedroppers-data0@psg.com; Fri, 03 Jul 2009 11:33:07 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMh0i-0004BK-Sb for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 11:33:02 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id D58A67C908; Fri, 3 Jul 2009 11:32:54 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id DCF9C75F61; Fri, 3 Jul 2009 14:32:52 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19021.60510.581052.428499@guava.gson.org> Date: Fri, 3 Jul 2009 14:32:46 +0300 To: Florian Weimer Cc: gson@araneus.fi (Andreas Gustafsson), Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: <82zlbmnlbn.fsf@mid.bfk.de> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> <82zlbmnlbn.fsf@mid.bfk.de> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian Weimer wrote: > > Discarding the cached NS RRset is a resonable way to force the > > resolution process to restart at the parent, but I don't see a need > > to force SERVFAILs or to wait for a hold-down period. You can > > immediately restart the current resolution using the pruned cache, > > taking care to avoid infinite loops as always. > > This will essentiall turn off caching of delegations where the child > zone is misconfigured in a particular way. Which particular way would that be? I can imagine something like this happening in a resolver that prefers child data over parent data for purposes of locating the child servers, but the point I'm trying to make is that resolvers shouldn't do that. -- 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 Jul 3 05:04:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8349D3A6963; Fri, 3 Jul 2009 05:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P33BfphlSHsB; Fri, 3 Jul 2009 05:04:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFD8828C288; Fri, 3 Jul 2009 05:03:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMhRY-0006Hg-Sd for namedroppers-data0@psg.com; Fri, 03 Jul 2009 12:00:40 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMhRF-0006Fg-OH for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 12:00:34 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n63C0C2U053419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2009 14:00:15 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A4DF2CC.2000207@nlnetlabs.nl> Date: Fri, 03 Jul 2009 14:00:12 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt References: <20090702200001.E18713A6BF1@core3.amsl.com> <82vdmankfj.fsf@mid.bfk.de> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 03 Jul 2009 14:00:15 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/03/2009 12:51 PM, Ray.Bellis@nominet.org.uk wrote: > TBH I can't recall exactly _why_ some proxies generate their own > transaction IDs. It is the only packet modification that's allowable > without breaking TSIG though. I would think to provide multiplexing, to make IDs unique per query. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpN8swACgkQkDLqNwOhpPiXJQCfeLrKIUdz1Eyv+JEe7B1gIprC nM8AniXI94GPg+vGvKYtUaSOc8r9DIxT =E0W2 -----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 Jul 3 05:04:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953793A6E50; Fri, 3 Jul 2009 05:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=-0.147, 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 Gq7afgQH+fdr; Fri, 3 Jul 2009 05:04:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AEB63A67EB; Fri, 3 Jul 2009 05:04:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMhSO-0006MN-C7 for namedroppers-data0@psg.com; Fri, 03 Jul 2009 12:01:32 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMhSD-0006LF-2z for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 12:01:26 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MMhV9-0005Hx-El; Fri, 03 Jul 2009 14:04:23 +0200 Received: by bfk.de with local id 1MMhSA-0008WU-Bw; Fri, 03 Jul 2009 12:01:18 +0000 To: Andreas Gustafsson Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> <82zlbmnlbn.fsf@mid.bfk.de> <19021.60510.581052.428499@guava.gson.org> From: Florian Weimer Date: Fri, 03 Jul 2009 12:01:16 +0000 In-Reply-To: <19021.60510.581052.428499@guava.gson.org> (Andreas Gustafsson's message of "Fri\, 3 Jul 2009 14\:32\:46 +0300") Message-ID: <82iqianfg3.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: * Andreas Gustafsson: > Florian Weimer wrote: >> > Discarding the cached NS RRset is a resonable way to force the >> > resolution process to restart at the parent, but I don't see a need >> > to force SERVFAILs or to wait for a hold-down period. You can >> > immediately restart the current resolution using the pruned cache, >> > taking care to avoid infinite loops as always. >>=20 >> This will essentiall turn off caching of delegations where the child >> zone is misconfigured in a particular way. > > Which particular way would that be? A child zone which looks like this: @ IN SOA ... @ IN A 192.0.2.1 @ IN NS ns That is, record for "ns". The delegation uses something else not involving "ns". > I can imagine something like this happening in a resolver that > prefers child data over parent data for purposes of locating the > child servers, but the point I'm trying to make is that resolvers > shouldn't do that. I'm generally sympathetic to that. But this will make it more difficult to pull DNS traffic over to IPv6. (I guess the primary application of deliberate glue mismatch is to introduce AAAA records.) --=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 Jul 3 05:07:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8593A67EB; Fri, 3 Jul 2009 05:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.152 X-Spam-Level: X-Spam-Status: No, score=-4.152 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C7qtEpvzJOJ; Fri, 3 Jul 2009 05:07:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06C2928C288; Fri, 3 Jul 2009 05:07:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMhW3-0006iD-Mn for namedroppers-data0@psg.com; Fri, 03 Jul 2009 12:05:19 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMhVs-0006ge-1N for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 12:05:13 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=BddyptfRe5XLX2bRriNQJU3/DmWoucHDM4xMEY26qgVx3oW+8BsyQTuY hSFhJ8fWyXIk6mjX3zLX/wdEDzqL1XDVRIP0oXCrahgmgVVAm228ta+Bq NV7g3qPr1Fm1zOJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246622708; x=1278158708; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20I-D=20Action:draft-ietf-dnsext-dnsproxy-06.txt |Date:=20Fri,=203=20Jul=202009=2013:05:01=20+0100 |Message-ID:=20|To:=20"W.C.A.=20Wijngaar ds"=20|Cc:=20namedroppers@ops.ietf.o rg|MIME-Version:=201.0|In-Reply-To:=20<4A4DF2CC.2000207@n lnetlabs.nl>|References:=20<20090702200001.E18713A6BF1@co re3.amsl.com>=09=20<82vdmankfj.fsf@mid.b fk.de>=20=20<4A4DF2CC.2000207@nlnetlabs. nl>; bh=TBapaqgm4PWn6Dktd7wUMszJRoDwddBdK8YymyDXenI=; b=alNghJIiHQQ5Zg/ZOVG87XtzUKbumBCbJpIkNkqVTmoONl7Ot/yLr6j4 0xVLCwr3zi+rW+hv1sC53Yn08IB2N+3uaBF57f6yn3IMOzcuDfx9VCmd/ 4QtZCuB0mWBqTvZ; X-IronPort-AV: E=Sophos;i="4.42,341,1243810800"; d="scan'208";a="11222733" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Jul 2009 13:05:04 +0100 In-Reply-To: <4A4DF2CC.2000207@nlnetlabs.nl> References: <20090702200001.E18713A6BF1@core3.amsl.com> <82vdmankfj.fsf@mid.bfk.de> <4A4DF2CC.2000207@nlnetlabs.nl> To: "W.C.A. Wijngaards" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 3 Jul 2009 13:05:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2009 01:05:06 PM, Serialize complete at 03/07/2009 01:05:06 PM Content-Type: multipart/alternative; boundary="=_alternative 004260A6802575E8_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 004260A6802575E8_= Content-Type: text/plain; charset="US-ASCII" "W.C.A. Wijngaards" wrote on 03/07/2009 13:00:12: > I would think to provide multiplexing, to make IDs unique per query. That's what I thought, but then I couldn't figure out why they couldn't do it on the locally chosen source port instead. (By which I mean the one chosen by the proxy for the forwarded packet, not the original source port used by the client). Clearly resolvers which always use port 53 as the source port would have to use the QID, but the proxies don't do that. Ray --=_alternative 004260A6802575E8_= Content-Type: text/html; charset="US-ASCII" "W.C.A. Wijngaards" <wouter@NLnetLabs.nl> wrote on 03/07/2009 13:00:12:
> I would think to provide multiplexing, to make IDs unique per query.

That's what I thought, but then I couldn't figure out why they couldn't do it on the locally chosen source port instead.  (By which I mean the one chosen by the proxy for the forwarded packet, not the original source port used by the client).

Clearly resolvers which always use port 53 as the source port would have to use the QID, but the proxies don't do that.

Ray
--=_alternative 004260A6802575E8_=-- -- to unsubscribe send a message to namedroppers-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 Jul 3 07:50:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5404C28C2C5; Fri, 3 Jul 2009 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlPZNUduHSq4; Fri, 3 Jul 2009 07:50:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5759B28C1E7; Fri, 3 Jul 2009 07:48:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMjyE-000Jdf-G8 for namedroppers-data0@psg.com; Fri, 03 Jul 2009 14:42:34 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMjy1-000JcC-FQ; Fri, 03 Jul 2009 14:42:26 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4DBE3E606E; Fri, 3 Jul 2009 14:42:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n63EgDNr061329; Sat, 4 Jul 2009 00:42:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907031442.n63EgDNr061329@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Florian Weimer , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org From: Mark Andrews References: <20090702200001.E18713A6BF1@core3.amsl.com> <82vdmankfj.fsf@mid.bfk.de> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt In-reply-to: Your message of "Fri, 03 Jul 2009 11:51:10 +0100." Date: Sat, 04 Jul 2009 00:42:13 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > > At the DNS layer, you can't pass through EDNS0 without actually > > understanding it. > > Actually many DNS proxies do "pass-through" EDNS0 perfectly happily, > because those proxies literally do almost nothing except forward the > packet to an upstream resolver. They pretty much do provide the clear > channel that you mention below. > > The only time this is a problem is if the EDNS0 buffer size sent by the > client is larger than the maximum response size that the proxy itself can > handle. > > > If you want to handle EDNS0, you really have to mandate clear UDP and > > TCP channels to the actual DNS servers, as if the proxy was performing > > destination NAT. No payload inspection is allowed, and certainly no > > caching. This is somewhat at odds with language in section 6.1, which > > suggests that it's okay with the draft if the proxy changes > > transaction IDs, as long as it properly randomizes them. > > TBH I can't recall exactly _why_ some proxies generate their own > transaction IDs. So you can correctly match responses to the request and forward the correct response to the correct requestor. You only have the first 12 bytes of the request to do this with and "id" is often the only differentiator. If you have two request from two sources with the same "id" you can't correctly do that. You need to maintain your own "id" space and use that to map back to the original id. Mark > It is the only packet modification that's allowable > without breaking TSIG though. > > Ray > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 07:56:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED7728C16D; Fri, 3 Jul 2009 07:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVjlWuehjwKo; Fri, 3 Jul 2009 07:56:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 295353A6EBC; Fri, 3 Jul 2009 07:56:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMk8H-000KYd-Qi for namedroppers-data0@psg.com; Fri, 03 Jul 2009 14:52:57 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMk86-000KX9-O1 for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 14:52:52 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D6694E606E; Fri, 3 Jul 2009 14:52:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n63Eqgq7061525; Sat, 4 Jul 2009 00:52:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907031452.n63Eqgq7061525@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: "W.C.A. Wijngaards" , namedroppers@ops.ietf.org From: Mark Andrews References: <20090702200001.E18713A6BF1@core3.amsl.com> <82vdmankfj.fsf@mid.bfk.de> <4A4DF2CC.2000207@nlnetlabs.nl> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt In-reply-to: Your message of "Fri, 03 Jul 2009 13:05:01 +0100." Date: Sat, 04 Jul 2009 00:52:42 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > "W.C.A. Wijngaards" wrote on 03/07/2009 13:00:12: > > I would think to provide multiplexing, to make IDs unique per query. > > That's what I thought, but then I couldn't figure out why they couldn't do > it on the locally chosen source port instead. (By which I mean the one > chosen by the proxy for the forwarded packet, not the original source port > used by the client). > > Clearly resolvers which always use port 53 as the source port would have > to use the QID, but the proxies don't do that. Each port can have its own id space. That way you can support more than 2^16 outstanding queries. Mark > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 08:06:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D55E28C28E; Fri, 3 Jul 2009 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtBNuxOCLIyC; Fri, 3 Jul 2009 08:06:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B335128C1D7; Fri, 3 Jul 2009 08:06:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMkIB-000LXE-GY for namedroppers-data0@psg.com; Fri, 03 Jul 2009 15:03:11 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMkHz-000LVo-Oj for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 15:03:05 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 830131C0122; Fri, 3 Jul 2009 17:02:58 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7E3E11C00E5; Fri, 3 Jul 2009 17:02:58 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 722D77B0039; Fri, 3 Jul 2009 17:02:58 +0200 (CEST) Date: Fri, 3 Jul 2009 17:03:11 +0200 From: Stephane Bortzmeyer To: Olafur Gudmundsson Cc: George Barwood , namedroppers@ops.ietf.org Subject: [dnsext] Re: Clarification on RFC 2181 Message-ID: <20090703150311.GA14966@nic.fr> References: <6E84C5F60655486683DC6009213B02AA@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 02, 2009 at 02:08:17PM -0400, Olafur Gudmundsson wrote a message of 38 lines which said: > DNS has number of timing windows that have to be respected or things > cani/will go wrong, in this case: ns.example.com should not have > been removed until after all instances of the prior NS set had > expired from caches. And, of course, such timing rules will be *much* more important with DNSSEC, which will soon bring to a name server near you, a lot more ways to crash your service :-) -- to unsubscribe send a message to namedroppers-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 Jul 3 08:58:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CB43A6E22; Fri, 3 Jul 2009 08:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXqPM57i5+7o; Fri, 3 Jul 2009 08:58:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFD1B3A67EB; Fri, 3 Jul 2009 08:58:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMl4L-000PLj-N2 for namedroppers-data0@psg.com; Fri, 03 Jul 2009 15:52:57 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMl4A-000PKO-GY for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 15:52:51 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n63FqgGD002020; Fri, 3 Jul 2009 08:52:42 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt Date: Fri, 3 Jul 2009 08:28:45 -0700 References: <20090702200001.E18713A6BF1@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: One minor nit: On fragmentation. (4.4.3) Method 1 (dropping fragments) must not be used, because it is incapable of ensuring that 4096B EDNS0 fragments can be passed. It is implied in the text, but it should be made explicit, because the de-facto MTU is the ethernet MTU, which is considerably less. Additionally, any NAT or firewall that allows through the first part of a UDP packet that is fragmented must allow the subsequent fragments through unless the specific fragment should be blocked by a security policy. If not, thats a bug that should be fixed. Any proxy MUST reassemble IP fragments before proceeding. On Jul 2, 2009, at 1:33 PM, Ray.Bellis@nominet.org.uk wrote: > > > Title : DNS Proxy Implementation Guidelines > > Author(s) : R. Bellis > > Filename : draft-ietf-dnsext-dnsproxy-06.txt > > Pages : 14 > > Date : 2009-07-02 > > This update addresses comments from AD review: > > Section 4.1 - cleaned up tautological language and changed > SHOULD > to MUST (Adrian Farrel) > Section 4.4.1 - made TCP support mandatory (from Lars Eggert) > Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko) > Section 6.3 - clarified rationale for handling errors (from > Robert > Sparks) > > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 09:41:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF2528C2C6; Fri, 3 Jul 2009 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM3+1p3k7x7F; Fri, 3 Jul 2009 09:41:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8ECAE28C2C5; Fri, 3 Jul 2009 09:41:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMlmG-0002kv-DE for namedroppers-data0@psg.com; Fri, 03 Jul 2009 16:38:20 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMlm5-0002k0-7U for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 16:38:14 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D799C2FE9666 for ; Fri, 3 Jul 2009 16:38:07 +0000 (UTC) Date: Fri, 3 Jul 2009 12:38:06 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt Message-ID: <20090703163805.GI8620@shinkuro.com> References: <20090702200001.E18713A6BF1@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 03, 2009 at 08:28:45AM -0700, Nicholas Weaver wrote: > One minor nit: > > On fragmentation. (4.4.3) > > Method 1 (dropping fragments) must not be used, because it is incapable > of ensuring that 4096B EDNS0 fragments can be passed. Do you have a text patch, please? This document went through WGLC already, and I'd expect that most details are worked out by this WG now, so if you have something you want "fixed" please state how you want it fixed. Thanks. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 09:54:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED1728C2D9; Fri, 3 Jul 2009 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJFMLeVrG-HB; Fri, 3 Jul 2009 09:54:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 560F428C2D7; Fri, 3 Jul 2009 09:53:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMlxu-0003dv-Sg for namedroppers-data0@psg.com; Fri, 03 Jul 2009 16:50:22 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMlxj-0003cy-TI for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 16:50:17 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 71A4AA7DBC; Fri, 3 Jul 2009 16:50:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: gson@araneus.fi (Andreas Gustafsson) cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: Your message of "Fri, 03 Jul 2009 12:10:50 +0300." <19021.51994.80438.865585@guava.gson.org> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 03 Jul 2009 16:50:11 +0000 Message-ID: <71853.1246639811@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 3 Jul 2009 12:10:50 +0300 > From: gson@araneus.fi (Andreas Gustafsson) > > Paul Vixie wrote: > > so a reasonable policy might be that if all nameserver names are > > unreachable then put the delegation in a hold-down state for > > 180+random(90) seconds during which you servfail all queries requiring > > that delegation be followed, and then discard the NS RRset, so that > > subsequent queries will cause re-iteration via the parent, hopefully to > > get reachable nameservers next time? > > When you say "nameserver names are unreachable", do you mean we lack > addresses for them or that we have addresses but fail to get a response > when querying them? To be clear, I'm talking about the former case. i am likewise talking about the former case, although i might expand the definition of unreachable to include "all addresses are returning servfail or refused". > Discarding the cached NS RRset is a resonable way to force the resolution > process to restart at the parent, but I don't see a need to force > SERVFAILs or to wait for a hold-down period. You can immediately restart > the current resolution using the pruned cache, taking care to avoid > infinite loops as always. without the holddown, this approach overwhelms the parent zone's servers. without the servfail, the question becomes, how to answer the downstream. -- to unsubscribe send a message to namedroppers-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 Jul 3 10:47:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D414D3A6B90; Fri, 3 Jul 2009 10:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.104 X-Spam-Level: X-Spam-Status: No, score=-5.104 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ollkc6NnxAQV; Fri, 3 Jul 2009 10:47:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC1373A688D; Fri, 3 Jul 2009 10:47:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMmmN-0008ic-Rq for namedroppers-data0@psg.com; Fri, 03 Jul 2009 17:42:31 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMmmD-0008hN-2V for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 17:42:26 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n63HgJrJ013899; Fri, 3 Jul 2009 10:42:19 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Andrew Sullivan In-Reply-To: <20090703163805.GI8620@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt Date: Fri, 3 Jul 2009 10:42:19 -0700 References: <20090702200001.E18713A6BF1@core3.amsl.com> <20090703163805.GI8620@shinkuro.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 3, 2009, at 9:38 AM, Andrew Sullivan wrote: > On Fri, Jul 03, 2009 at 08:28:45AM -0700, Nicholas Weaver wrote: >> One minor nit: >> >> On fragmentation. (4.4.3) >> >> Method 1 (dropping fragments) must not be used, because it is >> incapable >> of ensuring that 4096B EDNS0 fragments can be passed. > > Do you have a text patch, please? This document went through WGLC > already, and I'd expect that most details are worked out by this WG > now, so if you have something you want "fixed" please state how you > want it fixed. Thanks. Existing text: Therefore (irrespective of which of the methods above is in use) proxies SHOULD be capable of forwarding UDP packets up to a payload size of at least 4096 octets. Suggested change the paragraph: Therefore proxies SHOULD be capable of forwarding UDP packets up to a payload size of at least 4096 octets. Unfortunately, this is significantly greater than the Ethernet MTU of 1500 octets, which has become the de-facto MTU over most networks in use today. Therefore, method 1, dropping fragments, is not an advisable solution, and SHOULD NOT be used. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 11:44:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678DC3A6C33; Fri, 3 Jul 2009 11:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU0K-1WaFPuA; Fri, 3 Jul 2009 11:44:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDA1D3A6E9C; Fri, 3 Jul 2009 11:44:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMnfr-000F4p-D8 for namedroppers-data0@psg.com; Fri, 03 Jul 2009 18:39:51 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMnfg-000F2z-BV for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 18:39:45 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B74FFC2DA3; Fri, 3 Jul 2009 19:39:36 +0100 (BST) Date: Fri, 03 Jul 2009 19:39:30 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver , Andrew Sullivan cc: Nicholas Weaver , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt Message-ID: In-Reply-To: References: <20090702200001.E18713A6BF1@core3.amsl.com> <20090703163805.GI8620@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 3 July 2009 10:42:19 -0700 Nicholas Weaver wrote: > Therefore proxies SHOULD be capable of forwarding UDP packets up to a > payload size of at least 4096 octets. Unfortunately, this is > significantly greater than the Ethernet MTU of 1500 octets, which has > become the de-facto MTU over most networks in use today. Therefore, > method 1, dropping fragments, is not an advisable solution, and SHOULD > NOT be used. This would appear to be a tautology. Ignoring the exception case where the MTU on either side of the NAT is at least 4096 octets, there is no way I can immediately see that a NAT satisfying the first 'SHOULD' could use method 1 anyway. My worry is that this looks like a separate requirement. I thus don't think anything needs changing. If it does, I would simply do this: Therefore (irrespective of which of the methods above is in use) proxies SHOULD be capable of forwarding UDP packets up to a payload size of at least 4096 octets **which almost invariably precludes using method 1 as lower MTUs are commonplace**. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 12:02:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4A73A6F72; Fri, 3 Jul 2009 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.674 X-Spam-Level: X-Spam-Status: No, score=-98.674 tagged_above=-999 required=5 tests=[AWL=4.631, BAYES_00=-2.599, MIME_ASCII0=1.5, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl3H2Pwded-g; Fri, 3 Jul 2009 12:02:25 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 423CA28C337; Fri, 3 Jul 2009 12:01:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMnxY-000H7O-Ex for namedroppers-data0@psg.com; Fri, 03 Jul 2009 18:58:08 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMnxM-000H5J-OK for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 18:58:02 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MMnx8-0005vp-Og; Fri, 03 Jul 2009 19:57:42 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MMnx5-00041D-Ba; Fri, 03 Jul 2009 19:57:39 +0100 Message-ID: <06D25FFC8E08413495D28430DE39018B@localhost> From: "George Barwood" To: "Andreas Gustafsson" , "Florian Weimer" Cc: "Paul Vixie" , References: <6E84C5F60655486683DC6009213B02AA@localhost><6DF152BE76CD4A31BDD9A0F05C82D843@localhost><3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com><19021.6478.381852.351820@guava.gson.org><29210.1246575664@nsa.vix.com><19021.51994.80438.865585@guava.gson.org> <82zlbmnlbn.fsf@mid.bfk.de><19021.60510.581052.428499@guava.gson.org> <82iqianfg3.fsf@mid.bfk.de> Subject: Re: [dnsext] Clarification on RFC 2181 Date: Fri, 3 Jul 2009 19:57:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: VGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIG1pcy1jb25maWd1cmF0aW9ucyB0aGF0IGNhbiBj YXVzZSANCmxvb3BzIHRvIG9jY3VyLCBzbyByZXNvbHZlcnMgbmVlZCBhIGdlbmVyYWwgbWV0aG9k IG9mIGxpbWl0aW5nDQp0aGUgbnVtYmVyIG9mIHF1ZXJpZXMgdGhhdCBjYW4gYmUgZ2VuZXJhdGVk IGluIHJlc3BvbnNlIHRvIGEgDQpxdWVyeS4gVGhpcyBpcyBhZGVxdWF0ZWx5IGNvdmVyZWQgaW4g UkZDIDEwMzUgOg0KDQoiVGhlIGFtb3VudCBvZiB3b3JrIHdoaWNoIGEgcmVzb2x2ZXIgd2lsbCBk byBpbiByZXNwb25zZSB0byBhDQogY2xpZW50IHJlcXVlc3QgbXVzdCBiZSBsaW1pdGVkIHRvIGd1 YXJkIGFnYWluc3QgZXJyb3JzIGluIHRoZSBkYXRhYmFzZS4uLiINCg0KSWYgcmVzb2x2ZXJzIGNh biBkZXRlY3QgbG9vcGluZyBtaXMtY29uZmlndXJhdGlvbnMgYmVmb3JlIHRoaXMgDQpnZW5lcmFs IHNhZmVndWFyZCBpcyB0cmlnZ2VyZWQsIHRoYXQgaXMgZ29vZCwgYnV0IGl0J3Mgbm90IGVzc2Vu dGlhbC4NCg0KSSB0aGluayBpdCdzIHJlYXNvbmFibGUgdG8gaWdub3JlIGNoaWxkIE5TIFJSc2V0 cyB3aGljaCBoYXZlIG1pc3NpbmcgDQpyZXF1aXJlZCBnbHVlLCBidXQgdGhpcyBpcyByZWFsbHkg YW5vdGhlciB0b3BpYy4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJG bG9yaWFuIFdlaW1lciIgPGZ3ZWltZXJAYmZrLmRlPg0KVG86ICJBbmRyZWFzIEd1c3RhZnNzb24i IDxnc29uQGFyYW5ldXMuZmk+DQpDYzogIlBhdWwgVml4aWUiIDx2aXhpZUBpc2Mub3JnPjsgPG5h bWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEp1bHkgMDMsIDIwMDkgMTow MSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIENsYXJpZmljYXRpb24gb24gUkZDIDIxODENCg0K DQoqIEFuZHJlYXMgR3VzdGFmc3NvbjoNCg0KPiBGbG9yaWFuIFdlaW1lciB3cm90ZToNCj4+ID4g RGlzY2FyZGluZyB0aGUgY2FjaGVkIE5TIFJSc2V0IGlzIGEgcmVzb25hYmxlIHdheSB0byBmb3Jj ZSB0aGUNCj4+ID4gcmVzb2x1dGlvbiBwcm9jZXNzIHRvIHJlc3RhcnQgYXQgdGhlIHBhcmVudCwg YnV0IEkgZG9uJ3Qgc2VlIGEgbmVlZA0KPj4gPiB0byBmb3JjZSBTRVJWRkFJTHMgb3IgdG8gd2Fp dCBmb3IgYSBob2xkLWRvd24gcGVyaW9kLiAgWW91IGNhbg0KPj4gPiBpbW1lZGlhdGVseSByZXN0 YXJ0IHRoZSBjdXJyZW50IHJlc29sdXRpb24gdXNpbmcgdGhlIHBydW5lZCBjYWNoZSwNCj4+ID4g dGFraW5nIGNhcmUgdG8gYXZvaWQgaW5maW5pdGUgbG9vcHMgYXMgYWx3YXlzLg0KPj4gDQo+PiBU aGlzIHdpbGwgZXNzZW50aWFsbCB0dXJuIG9mZiBjYWNoaW5nIG9mIGRlbGVnYXRpb25zIHdoZXJl IHRoZSBjaGlsZA0KPj4gem9uZSBpcyBtaXNjb25maWd1cmVkIGluIGEgcGFydGljdWxhciB3YXku DQo+DQo+IFdoaWNoIHBhcnRpY3VsYXIgd2F5IHdvdWxkIHRoYXQgYmU/DQoNCkEgY2hpbGQgem9u ZSB3aGljaCBsb29rcyBsaWtlIHRoaXM6DQoNCkAgSU4gU09BIC4uLg0KQCBJTiBBIDE5Mi4wLjIu MQ0KQCBJTiBOUyBucw0KDQpUaGF0IGlzLCByZWNvcmQgZm9yICJucyIuICBUaGUgZGVsZWdhdGlv biB1c2VzIHNvbWV0aGluZyBlbHNlIG5vdA0KaW52b2x2aW5nICJucyIuDQoNCj4gSSBjYW4gaW1h Z2luZSBzb21ldGhpbmcgbGlrZSB0aGlzIGhhcHBlbmluZyBpbiBhIHJlc29sdmVyIHRoYXQNCj4g cHJlZmVycyBjaGlsZCBkYXRhIG92ZXIgcGFyZW50IGRhdGEgZm9yIHB1cnBvc2VzIG9mIGxvY2F0 aW5nIHRoZQ0KPiBjaGlsZCBzZXJ2ZXJzLCBidXQgdGhlIHBvaW50IEknbSB0cnlpbmcgdG8gbWFr ZSBpcyB0aGF0IHJlc29sdmVycw0KPiBzaG91bGRuJ3QgZG8gdGhhdC4NCg0KSSdtIGdlbmVyYWxs eSBzeW1wYXRoZXRpYyB0byB0aGF0LiAgQnV0IHRoaXMgd2lsbCBtYWtlIGl0IG1vcmUNCmRpZmZp Y3VsdCB0byBwdWxsIEROUyB0cmFmZmljIG92ZXIgdG8gSVB2Ni4gIChJIGd1ZXNzIHRoZSBwcmlt YXJ5DQphcHBsaWNhdGlvbiBvZiBkZWxpYmVyYXRlIGdsdWUgbWlzbWF0Y2ggaXMgdG8gaW50cm9k dWNlIEFBQUEgcmVjb3Jkcy4pDQoNCi0tIA0KRmxvcmlhbiBXZWltZXIgICAgICAgICAgICAgICAg PGZ3ZWltZXJAYmZrLmRlPg0KQkZLIGVkdi1jb25zdWx0aW5nIEdtYkggICAgICAgaHR0cDovL3d3 dy5iZmsuZGUvDQpLcmllZ3NzdHJh32UgMTAwICAgICAgICAgICAgICB0ZWw6ICs0OS03MjEtOTYy MDEtMQ0KRC03NjEzMyBLYXJsc3J1aGUgICAgICAgICAgICAgZmF4OiArNDktNzIxLTk2MjAxLTk5 DQoNCi0tDQp0byB1bnN1YnNjcmliZSBzZW5kIGEgbWVzc2FnZSB0byBuYW1lZHJvcHBlcnMtcmVx dWVzdEBvcHMuaWV0Zi5vcmcgd2l0aA0KdGhlIHdvcmQgJ3Vuc3Vic2NyaWJlJyBpbiBhIHNpbmds ZSBsaW5lIGFzIHRoZSBtZXNzYWdlIHRleHQgYm9keS4NCmFyY2hpdmU6IDxodHRwOi8vb3BzLmll dGYub3JnL2xpc3RzL25hbWVkcm9wcGVycy8+DQo= -- to unsubscribe send a message to namedroppers-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 Jul 3 12:02:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2893A6F79; Fri, 3 Jul 2009 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs59dh5Zjcf7; Fri, 3 Jul 2009 12:02:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79F7928C350; Fri, 3 Jul 2009 12:01:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMnwy-000H1x-KS for namedroppers-data0@psg.com; Fri, 03 Jul 2009 18:57:32 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMnwd-000GyC-0M for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 18:57:26 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=F2i0ZGOVvp9gAnsP6eu4fCGskkhcI5sw88S0TbtqoTW57Q7t5hl8g3Ze aVlzOUZ57kh1w12Er2cOSJ01g2z5qRD8qdzDvRiPRGktsCy0NeJx44wxQ /TEeCfvm4u6N2kB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246647431; x=1278183431; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20I-D=20Action:draft-ietf-dnsext-dnsproxy-06.txt |Date:=20Fri,=203=20Jul=202009=2019:57:03=20+0100 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0|In-Reply-To:=20|References:=20<20090702200001. E18713A6BF1@core3.amsl.com>=20=20=20<2009 0703163805.GI8620@shinkuro.com>=20=20; bh=eyIS/7aaewZOw+7c49EfcvtIme2+HSi7alrGAEC14v8=; b=4tafhy/kWsOoG3Rw2H77zUcSdL5Eg9WZFAlcoPDy5qrBThH9uagI0pHd 9y8hxPOuqmvYaEaeFgohkjE+/H3Bw2ldsSMKbV4kEzo4FZzv8n1BCxvlF MuCBPCP17FDKPFo; X-IronPort-AV: E=Sophos;i="4.42,343,1243810800"; d="scan'208";a="11234007" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Jul 2009 19:57:06 +0100 In-Reply-To: References: <20090702200001.E18713A6BF1@core3.amsl.com> <20090703163805.GI8620@shinkuro.com> To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 3 Jul 2009 19:57:03 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2009 07:57:08 PM, Serialize complete at 03/07/2009 07:57:08 PM Content-Type: multipart/alternative; boundary="=_alternative 006819EA802575E8_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 006819EA802575E8_= Content-Type: text/plain; charset="US-ASCII" > I thus don't think anything needs changing. If it does, I would > simply do this: > Therefore (irrespective of which of the methods above is in use) > proxies SHOULD be capable of forwarding UDP packets up to a payload > size of at least 4096 octets **which almost invariably precludes > using method 1 as lower MTUs are commonplace**. Please note that as of earlier this afternoon the draft has been approved by the IESG for submission to the RFC Editors (although the datatracker doesn't reflect this yet). Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 006819EA802575E8_= Content-Type: text/html; charset="US-ASCII"
> I thus don't think anything needs changing. If it does, I would
> simply do this:
>   Therefore (irrespective of which of the methods above is in use)
>   proxies SHOULD be capable of forwarding UDP packets up to a payload
>   size of at least 4096 octets **which almost invariably precludes
>   using method 1 as lower MTUs are commonplace**.

Please note that as of earlier this afternoon the draft has been approved by the IESG for submission to the RFC Editors (although the datatracker doesn't reflect this yet).

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
--=_alternative 006819EA802575E8_=-- -- to unsubscribe send a message to namedroppers-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 Jul 3 12:06:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6D13A6A71; Fri, 3 Jul 2009 12:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w78g5ZrbkBPg; Fri, 3 Jul 2009 12:06:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EE063A69E0; Fri, 3 Jul 2009 12:06:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMo3r-000HzW-06 for namedroppers-data0@psg.com; Fri, 03 Jul 2009 19:04:39 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMo3f-000Hxr-Ro for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 19:04:33 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id CB6BE7C900; Fri, 3 Jul 2009 19:04:25 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 9F34975F61; Fri, 3 Jul 2009 22:04:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19022.22073.365617.198159@guava.gson.org> Date: Fri, 3 Jul 2009 22:04:25 +0300 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: <71853.1246639811@nsa.vix.com> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> <71853.1246639811@nsa.vix.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > > Discarding the cached NS RRset is a resonable way to force the resolution > > process to restart at the parent, but I don't see a need to force > > SERVFAILs or to wait for a hold-down period. You can immediately restart > > the current resolution using the pruned cache, taking care to avoid > > infinite loops as always. > > without the holddown, this approach overwhelms the parent zone's servers. I beg to differ. All RFC1035-compliant resolvers already do restarts, and I'm not aware of any of them implementing these mythical "hold-down periods" of which you speak. Yet I don't see the net imploding because of restart-related traffic. > without the servfail, the question becomes, how to answer the > downstream. If the restart succeeds at reestablishing glue, then hopefully with a NOERROR response containing the requested data. -- 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 Jul 3 12:32:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CA828C33A; Fri, 3 Jul 2009 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DSL=1.129, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwm04cE4F7R0; Fri, 3 Jul 2009 12:32:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2824F28C330; Fri, 3 Jul 2009 12:32:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMoRz-000Ky0-Mr for namedroppers-data0@psg.com; Fri, 03 Jul 2009 19:29:35 +0000 Received: from [216.194.124.237] (helo=execdsl.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMoRo-000Kwn-Ev for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 19:29:29 +0000 Received: from [66.92.164.104] (HELO dynamic124.shinkuro.com) by execdsl.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 17794571; Fri, 03 Jul 2009 13:26:36 -0600 Message-Id: <381014A0-6A19-48C3-BE46-040766E39CAE@shinkuro.com> From: Steve Crocker To: DNSSEC deployment , DNSEXT WG Content-Type: multipart/alternative; boundary=Apple-Mail-419--93293847 Mime-Version: 1.0 (Apple Message framework v930.3) Subject: [dnsext] RFC5011 interoperabilty testing Date: Fri, 3 Jul 2009 15:29:22 -0400 X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-419--93293847 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Shinkuro is starting a public interoperabilty test of RFC5011 implementations. The main goals of this effort are * to determine if the RFC5011 specification need corrections/additions/ deletions etc. before being advanced along IETF standards track. * Allow implementors to assess if their implementations are compliant and inter operate. To participate in this tests please subscribe to the interoperabilty mailing list rfc5011@shinkuro.com by sending email to rfc5011-feed@shinkuro.com N.B. This is not the usual "-request" format. There are two main parts to this test, * RFC5011 compliant rollover of keys by zones * RFC5011 trust maintenance by trust anchor maintainers. In near term we will start the second part, and add the first part as vendors sign up. Proposed test plan for trust anchor maintainers will be posted to the rfc5011 mailing list early next week. There will also be a web site, but it is not yet set up. Olafur Gudmundsson will be running this effort for us. Steve Crocker --Apple-Mail-419--93293847 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Shinkuro is starting a public = interoperabilty test of RFC5011 implementations.

The main goals = of this effort are
* to determine if the RFC5011 specification = need corrections/additions/deletions etc. before being advanced = along IETF standards track.
* Allow implementors to assess if = their implementations are compliant and inter operate.

To = participate in this tests please subscribe to the interoperabilty = mailing
list rfc5011@shinkuro.com by sending = email to rfc5011-feed@shinkuro.com=

N.B. This is not the = usual "-request" format.

There are two main parts to = this test,
* RFC5011 compliant rollover of keys by = zones
* RFC5011 trust maintenance by trust anchor = maintainers.

In near term we will start the second part, and add = the first part as vendors sign up.

Proposed test plan for = trust anchor maintainers will be posted to the rfc5011 mailing list = early next week.

There will also be a web site, = but it is not yet set up.

Olafur Gudmundsson = will be running this effort for us.

Steve = Crocker




= --Apple-Mail-419--93293847-- -- to unsubscribe send a message to namedroppers-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 Jul 3 15:00:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829DB3A6869; Fri, 3 Jul 2009 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DSL=1.129, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQbSB90AOSoF; Fri, 3 Jul 2009 15:00:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 751CF3A6842; Fri, 3 Jul 2009 15:00:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMqj6-0006LB-GF for namedroppers-data0@psg.com; Fri, 03 Jul 2009 21:55:24 +0000 Received: from [216.194.124.237] (helo=execdsl.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMqit-0006K2-6O for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 21:55:17 +0000 Received: from [66.92.164.104] (HELO dynamic124.shinkuro.com) by execdsl.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 17795052 for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 15:52:23 -0600 Message-Id: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> From: Steve Crocker To: DNSEXT WG Content-Type: multipart/mixed; boundary=Apple-Mail-447--84547569 Mime-Version: 1.0 (Apple Message framework v930.3) Subject: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Date: Fri, 3 Jul 2009 17:55:08 -0400 References: X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-447--84547569 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, Scott Rose and I wrote a proposal for an extension to the DNS query to indicate which algorithms the querier understands. This is intended to facilitate transition to new algorithms by providing information as to how fully a new algorithm is understood. We have submitted this proposal to the IETF DNSEXT Working Group for consideration. To move this forward, there has to be a sufficient set of people willing to read and support the proposal. We are hereby asking for volunteers to review and support this proposal. We have already some feedback suggesting the querier should be able to specify a list of algorithms instead of just he highest numbered one. I think that's an appropriate suggestion and we'll work on that. (Suggestions on how to do this in a way that is most convenient for servers to process would be welcome. On the other hand, if the servers can't really use the information in formulating a reply and the main value will be for information gathering, the choice of format doesn't matter too much.) Thanks, Steve --Apple-Mail-447--84547569 Content-Disposition: attachment; filename=draft-crocker-dnssec-algo-signal-03.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-crocker-dnssec-algo-signal-03.txt" Content-Transfer-Encoding: quoted-printable DNS Extensions Working Group S. Crocker Internet-Draft Shinkuro Inc. Updates: 4035 (if approved) S. Rose Intended status: Standards Track NIST Expires: January 2, 2010 July 1, 2009 Signaling Cryptographic Algorithm Understanding in DNSSEC draft-crocker-dnssec-algo-signal-03 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital Crocker & Rose Expires January 2, 2010 [Page 1] =0C Internet-Draft Algorithm-Signal July 2009 signatures. These digital signatures can be generated using different algorithms. Each digital signature added to a response increases the size of the response, which could result in the response message being truncated. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they prefer in a DNSSEC response by defining an EDNS option to list a client's preferred algorithms. 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling Algorithm Understood (AU) Using EDNS . . . . . . . . 3 3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 4 3.1. Recommendations for Stub Clients . . . . . . . . . . . . . 5 4. Server Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Cache and Forwarder Considerations . . . . . . . . . . . . . . 5 5.1. Intermediate Proxy Resolvers . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Crocker & Rose Expires January 2, 2010 [Page 2] =0C Internet-Draft Algorithm-Signal July 2009 1. Introduction The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures [RFC4033], [RFC4034] and [RFC4035]. Each digital signature RR (RRSIG) contains an algorithm code number. These algorithm codes help validators identify which cryptographic algorithm was used to generate the digital signature. RRSIG RRs can be fairly large, and increase the size of a response. If multiple algorithms are used, then multiple RRSIGs are returned for each RRset in a response. If the response is too large, it may be truncated, and the client forced to resend the query using TCP. It would be in the client and server's interests if there was a way to limit the number of RRSIGs in a response to only those algorithms the client was interested in (if present). This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they prefer in a DNSSEC response. This is done using the EDNS attribute values in the OPT meta-RR [RFC2671]. This option could also be used by servers to advertise which cryptographic algorithms are used in signing a particular zone. An additional reason for having the end-system resolver signal which algorithms it understands is to speed the transition to a new algorithm. A server will be able to determine when to start serving a new algorithm when it sees a sufficient number of its clients are able to accept the new algorithm and it will be able to determine when to stop serving the old algorithm when it sees that all or almost all of its clients are able to accept the new algorithm. Information about clients can also be used to communicate to the operators of those clients and/or the providers of their software that it's time to upgrade. 2. Signaling Algorithm Understood (AU) Using EDNS The ENDS0 specification outlined in [RFC2671] defines a way to include new options using a standardized mechanism. These options are contained in the RDATA of the OPT meta-RR. This document seeks to define a new EDNS0 option for a client to signal which algorithms the client prefers, and the server to advertise which algorithms are used to sign a particular zone. Crocker & Rose Expires January 2, 2010 [Page 3] =0C Internet-Draft Algorithm-Signal July 2009 Below shows how the signaling attribute is defined in the RDATA of the OPT RR as specified in [RFC2671]: 0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-CODE (TBD) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ALG-CODE | ... \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ OPTION-CODE is the code for the Algorithm Understood (AU) option. Its value is fixed at TBD. OPTION-LENGTH is the length of the data of the attribute in octets. DNSSEC algorithm codes are 1 octet long so this value is set at 1. ALG-CODE is the assigned DNSSEC algorithm codes that the client indicates as understood. This value SHOULD be the largest algorithm code value understood by the validator (excluding Reserved codes, and values greater than 252). It is assumed that the validator understands all previously defined (and lower) algorithm codes. For example, if a validating client understands RSA/SHA-1 and RSA/SHA-256 the value of ALG-CODE would be: 8 (RSA/SHA-256), indicating that the validator understand both RSA/SHA-256, RSA/SHA-1 and DSA but not ECC because it is currently reserved and not defined. 3. Client Considerations A validating end-system resolver sets the AU option in the OPT meta-RR when sending a query. The validating end-system resolver SHOULD set the value to be the largest algorithm code that the validator understands (excluding Reserved codes and values greater than 252). A validating end-system resolver SHOULD only list algorithm codes that the client has implemented. Conversely, a validating end-system resolver SHOULD NOT include the algorithm code for cryptographic algorithms for which they have not implemented. The end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response. Crocker & Rose Expires January 2, 2010 [Page 4] =0C Internet-Draft Algorithm-Signal July 2009 3.1. Recommendations for Stub Clients Stub resolvers rely on an upstream recursive server (or cache) to provide a response, any algorithm preference on the stub resolver's side can be overruled by the upstream recursive server. The AU EDNS option is NOT RECOMMENDED for non-validating stub clients. The only exception is for validating stub resolvers, which set the CD bit in queries. In this scenario, the validating stub indicates that it wishes to perform its own validation and may wish to indicate which cryptographic algorithm it prefers. 4. Server Considerations When an authoritative server sees the AU option in the OPT meta-RR in a request the normal algorithm for servicing requests is followed. The only difference is what DNSSEC RRs are included in the final response. If the AU option is present but the DNSSEC-OK bit is not set, then the authoritative server does not include any additional DNSSEC RRs in the response. If the DNSSEC-OK bit is set, the authoritative server looks at the ALG-CODE value in the OPT meta-RR, selects the RRSIGs with the algorithm code equal to or lower (whichever is closest) to be included in the response (as per the rules in [RFC4035]). If the zone containing the QNAME is not signed, the authoritative server sends a traditional non-DNSSEC response. If the zone containing the QNAME is signed with a cryptographic algorithm(s) that are all greater than the ALG-CODE value in the client query the authoritative server SHOULD include any or all RRSIGs in the response regardless of algorithm used to generate them. 5. Cache and Forwarder Considerations Caches MUST NOT set the AU option on any outgoing query from the cache when performing recursion on behalf of a stub client. A cache MUST follow the guidelines in the DNSSEC specification ([RFC4033], [RFC4034], [RFC4035] and any updating documents). If a cache receives a query with the AU option set and the response can be answered by data out of the cache, the cache SHOULD follow the AU option request and only include the RRSIGs generated using the algorithm equal to or less than the value in ALG-CODE. Forwarders that do not do validation or caching MAY copy the AU option seen in received queries as they represent the wishes of the Crocker & Rose Expires January 2, 2010 [Page 5] =0C Internet-Draft Algorithm-Signal July 2009 validating downstream resolver that issued the original query. 5.1. Intermediate Proxy Resolvers Intermediate resolvers SHOULD copy the AU option seen in queries from end- system resolvers. If the intermediate resolver is validating, it SHOULD also check for the presence of the CD bit in the query. If present, the intermediate resolvers SHOULD copy the AU option as seen in the query. If not or if the DNSSEC-OK bit is not set, then the validating intermediate resolver MAY chose to ignore the AU option in the query and MAY include its own preference as the AU option. 6. IANA Considerations The algorithm codes used to identify DNSSEC algorithms has already been established by IANA. This document does not seek to alter that registry in any way. This draft seeks to update the "DNS EDNS0 Options" registry by adding the AU option and referencing this document. The code for the option should be TBD. 7. Security Considerations This document specifies a way for a client to signal its digital signature algorithm preference to a cache or server. It is not meant to be a discussion on algorithm superiority. The signal is an optional code contained in the OPT meta-RR used with EDNS0. The goal of this option is to reduce response size by having the client signal with digital signature algorithms it prefers and that it may not care about other algorithms used to sign zone data. It is possible that an attacker can attempt to conduct a downgrade attack by intercepting the query and altering the AU option code. An attacker could alter the algorithm list to force the client to rely on a weaker digital signature algorithm even though the zone is signed using a stronger algorithm the client prefers. In these cases a client might be able to detect an attack if the target zone has a DS RR in its delegating parent with the desired algorithm. The DS cannot be deleted without making the parent's RRSIG over that RRset invalid. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", Crocker & Rose Expires January 2, 2010 [Page 6] =0C Internet-Draft Algorithm-Signal July 2009 RFC 2671, August 1999. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Authors' Addresses Steve Crocker Shinkuro Inc. 5110 Edgemoor Lane Bethesda, MD 20814 USA EMail: steve@shinkuro.com Scott Rose NIST 100 Bureau Dr. Gaithersburg, MD 20899 USA Phone: +1-301-975-8439 EMail: scott.rose@nist.gov Crocker & Rose Expires January 2, 2010 [Page 7] =0C --Apple-Mail-447--84547569 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-447--84547569-- -- to unsubscribe send a message to namedroppers-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 Jul 3 15:11:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427473A6A37; Fri, 3 Jul 2009 15:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO-+sTiEUJrH; Fri, 3 Jul 2009 15:11:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DF553A683F; Fri, 3 Jul 2009 15:11:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMqvh-0007Et-5b for namedroppers-data0@psg.com; Fri, 03 Jul 2009 22:08:25 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMqvV-0007EC-Rl for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 22:08:19 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 77A6CA7E20 for ; Fri, 3 Jul 2009 22:08:13 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: Your message of "Fri, 03 Jul 2009 22:04:25 +0300." <19022.22073.365617.198159@guava.gson.org> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> <71853.1246639811@nsa.vix.com> <19022.22073.365617.198159@guava.gson.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 03 Jul 2009 22:08:13 +0000 Message-ID: <84573.1246658893@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 3 Jul 2009 22:04:25 +0300 > From: Andreas Gustafsson > > Paul Vixie wrote: > > without the holddown, this approach overwhelms the parent zone's servers. > > I beg to differ. All RFC1035-compliant resolvers already do restarts, > and I'm not aware of any of them implementing these mythical "hold-down > periods" of which you speak. Yet I don't see the net imploding because > of restart-related traffic. i'm not aware of a nameserver that discards an NS RRset from cache when all names are unreachable, in the way that i proposed. if such a nameserver is developed, then i do suggest that it implement the holddown i also proposed. -- to unsubscribe send a message to namedroppers-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 Jul 3 15:49:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A963A6B3F; Fri, 3 Jul 2009 15:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Klw76WeMBBdB; Fri, 3 Jul 2009 15:49:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A78203A6E37; Fri, 3 Jul 2009 15:49:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMrTF-0009mL-Ry for namedroppers-data0@psg.com; Fri, 03 Jul 2009 22:43:05 +0000 Received: from [2001:470:1f00:ffff::af] (helo=mail.hardakers.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMrSw-0009kC-77 for namedroppers@ops.ietf.org; Fri, 03 Jul 2009 22:42:59 +0000 Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 0B73D98095; Fri, 3 Jul 2009 15:42:46 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id F223739A0EB; Fri, 3 Jul 2009 15:42:45 -0700 (PDT) From: Wes Hardaker To: Steve Crocker Cc: DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Organization: Sparta References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> Date: Fri, 03 Jul 2009 15:42:45 -0700 In-Reply-To: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> (Steve Crocker's message of "Fri, 3 Jul 2009 17:55:08 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >>>>> On Fri, 3 Jul 2009 17:55:08 -0400, Steve Crocker said: SC> We are hereby asking for volunteers to review and support this SC> proposal. I think it's a good idea and support it. I already mailed a list of caveats with the text earlier [different list], which I assume you'll take into consideration. I'll also review it if it goes forward as a WG document. -- Wes Hardaker Cobham Analytic Solutions -- to unsubscribe send a message to namedroppers-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 Jul 3 21:14:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7523A6B18; Fri, 3 Jul 2009 21:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.81 X-Spam-Level: **** X-Spam-Status: No, score=4.81 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JurAeW1QSDMo; Fri, 3 Jul 2009 21:14:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CBF53A6847; Fri, 3 Jul 2009 21:14:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMwXX-0006dp-IV for namedroppers-data0@psg.com; Sat, 04 Jul 2009 04:07:51 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMwX9-0006cQ-Rh for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 04:07:43 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MMwX7-0002TI-US; Sat, 04 Jul 2009 05:07:26 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MMwX3-0000vH-Ur; Sat, 04 Jul 2009 05:07:22 +0100 Message-ID: <5BA727DA635F4EC98B5E8BD717243C40@localhost> From: "George Barwood" To: "Steve Crocker" , "DNSEXT WG" References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Date: Sat, 4 Jul 2009 05:07:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: V291bGQgaXQgbm90IGJlIGJldHRlciB0byBmaXggdGhlIHNob3J0Y29taW5ncyBvZiBETlMgdHJh bnNwb3J0IG92ZXIgVURQIA0Kb25jZSBhbmQgZm9yIGFsbCwgcmF0aGVyIHRoYW4gY29tcGxpY2F0 aW5nIGhpZ2hlciBsZXZlbHMgb2YgdGhlIHByb3RvY29sLg0KDQpUaGF0J3MgdGhlIGludGVudGlv biBvZiAgdGhlICJFRE5TIFBhZ2UgT3B0aW9uIHRvIGhhbmRsZSBsYXJnZSByZXNwb25zZXMiDQpJ IHByb3Bvc2VkIGF0DQoNCmh0dHA6Ly9vcHMuaWV0Zi5vcmcvbGlzdHMvbmFtZWRyb3BwZXJzL25h bWVkcm9wcGVycy4yMDA5L21zZzAxMjc4Lmh0bWwNCg0KSXMgdGFja2xpbmcgdGhlIHByb2JsZW0g b24gYSBwaWVjZS1tZWFsIGJhc2lzIGEgZ29vZCB3YXkgZm9yd2FyZD8NCg0KR2VvcmdlDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiU3RldmUgQ3JvY2tlciIgPHN0ZXZl QHNoaW5rdXJvLmNvbT4NClRvOiAiRE5TRVhUIFdHIiA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9y Zz4NClNlbnQ6IEZyaWRheSwgSnVseSAwMywgMjAwOSAxMDo1NSBQTQ0KU3ViamVjdDogW2Ruc2V4 dF0gYWxnby1zaWduYWwgLTAzIC0tIEludGVybmV0IERyYWZ0IHRvIGZhY2lsaXRhdGUgYWxnb3Jp dGhtIHRyYW5zaXRpb24NCg0KDQo+IEZvbGtzLA0KPiANCj4gU2NvdHQgUm9zZSBhbmQgSSB3cm90 ZSBhIHByb3Bvc2FsIGZvciBhbiBleHRlbnNpb24gdG8gdGhlIEROUyBxdWVyeSB0byAgDQo+IGlu ZGljYXRlIHdoaWNoIGFsZ29yaXRobXMgdGhlIHF1ZXJpZXIgdW5kZXJzdGFuZHMuICBUaGlzIGlz IGludGVuZGVkICANCj4gdG8gZmFjaWxpdGF0ZSB0cmFuc2l0aW9uIHRvIG5ldyBhbGdvcml0aG1z IGJ5IHByb3ZpZGluZyBpbmZvcm1hdGlvbiBhcyAgDQo+IHRvIGhvdyBmdWxseSBhIG5ldyBhbGdv cml0aG0gaXMgdW5kZXJzdG9vZC4NCj4gDQo+IFdlIGhhdmUgc3VibWl0dGVkIHRoaXMgcHJvcG9z YWwgdG8gdGhlIElFVEYgRE5TRVhUIFdvcmtpbmcgR3JvdXAgZm9yICANCj4gY29uc2lkZXJhdGlv bi4gIFRvIG1vdmUgdGhpcyBmb3J3YXJkLCB0aGVyZSBoYXMgdG8gYmUgYSBzdWZmaWNpZW50IHNl dCAgDQo+IG9mIHBlb3BsZSB3aWxsaW5nIHRvIHJlYWQgYW5kIHN1cHBvcnQgdGhlIHByb3Bvc2Fs Lg0KPiANCj4gV2UgYXJlIGhlcmVieSBhc2tpbmcgZm9yIHZvbHVudGVlcnMgdG8gcmV2aWV3IGFu ZCBzdXBwb3J0IHRoaXMgcHJvcG9zYWwuDQo+IA0KPiBXZSBoYXZlIGFscmVhZHkgc29tZSBmZWVk YmFjayBzdWdnZXN0aW5nIHRoZSBxdWVyaWVyIHNob3VsZCBiZSBhYmxlIHRvICANCj4gc3BlY2lm eSBhIGxpc3Qgb2YgYWxnb3JpdGhtcyBpbnN0ZWFkIG9mIGp1c3QgaGUgaGlnaGVzdCBudW1iZXJl ZCBvbmUuICAgDQo+IEkgdGhpbmsgdGhhdCdzIGFuIGFwcHJvcHJpYXRlIHN1Z2dlc3Rpb24gYW5k IHdlJ2xsIHdvcmsgb24gdGhhdC4gICANCj4gKFN1Z2dlc3Rpb25zIG9uIGhvdyB0byBkbyB0aGlz IGluIGEgd2F5IHRoYXQgaXMgbW9zdCBjb252ZW5pZW50IGZvciAgDQo+IHNlcnZlcnMgdG8gcHJv Y2VzcyB3b3VsZCBiZSB3ZWxjb21lLiAgT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZSAgDQo+IHNl cnZlcnMgY2FuJ3QgcmVhbGx5IHVzZSB0aGUgaW5mb3JtYXRpb24gaW4gZm9ybXVsYXRpbmcgYSBy ZXBseSBhbmQgIA0KPiB0aGUgbWFpbiB2YWx1ZSB3aWxsIGJlIGZvciBpbmZvcm1hdGlvbiBnYXRo ZXJpbmcsIHRoZSBjaG9pY2Ugb2YgZm9ybWF0ICANCj4gZG9lc24ndCBtYXR0ZXIgdG9vIG11Y2gu KQ0KPiANCj4gVGhhbmtzLA0KPiANCj4gU3RldmUNCj4gDQo+IA0KPg0KDQoNCg0KPiANCj4gDQo+ -- to unsubscribe send a message to namedroppers-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 Jul 3 21:33:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9BB3A6B2E; Fri, 3 Jul 2009 21:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyU+sm8SqidU; Fri, 3 Jul 2009 21:33:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9185F3A681C; Fri, 3 Jul 2009 21:33:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMwsn-00084T-RA for namedroppers-data0@psg.com; Sat, 04 Jul 2009 04:29:49 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMwsZ-00080D-LY for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 04:29:42 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 19A51A7E58; Sat, 4 Jul 2009 04:29:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "George Barwood" cc: "Steve Crocker" , "DNSEXT WG" Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-Reply-To: Your message of "Sat, 04 Jul 2009 05:07:16 +0100." <5BA727DA635F4EC98B5E8BD717243C40@localhost> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 04 Jul 2009 04:29:35 +0000 Message-ID: <99789.1246681775@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Sat, 4 Jul 2009 05:07:16 +0100 > > Would it not be better to fix the shortcomings of DNS transport over UDP > once and for all, rather than complicating higher levels of the protocol. no. not even if that were an accurate summation of scrocker's proposal. > Is tackling the problem on a piece-meal basis a good way forward? for low bandwidth (mobile or interplanetary) clients, scrocker's proposal is a godsend, and no fix to the transport to allow for larger messages will solve that same problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 3 22:20:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239D828C1EF; Fri, 3 Jul 2009 22:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu9Pc-od5CBt; Fri, 3 Jul 2009 22:20:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F177528C1A0; Fri, 3 Jul 2009 22:20:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMxcE-000BO4-IR for namedroppers-data0@psg.com; Sat, 04 Jul 2009 05:16:46 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMxc3-000BNM-MA for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 05:16:41 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 60C02A7EBD for ; Sat, 4 Jul 2009 05:16:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "DNSEXT WG" Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-Reply-To: Your message of "Sat, 04 Jul 2009 05:58:14 +0100." References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> <99789.1246681775@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 04 Jul 2009 05:16:35 +0000 Message-ID: <1846.1246684595@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Sat, 4 Jul 2009 05:58:14 +0100 > > > for low bandwidth (mobile or interplanetary) clients, scrocker's > > proposal is a godsend, and no fix to the transport to allow for larger > > messages will solve that same problem. > > In that case the proposal should indicate that this is the goal, rather > than the avoidance of TCP. that would be an overspecification. there are many reasons why avoiding tcp is bad. in fact it may already overspecify since it mentions avoiding tcp rather than describing a way to avoid sending metadata when nonuseful. (there are many reasons why sending nonuseful data is bad, avoiding tcp is only one simple one.) > I suggest that low-bandwidth clients would do better to use a secure > channel to a high-bandwidth cache. do you think mobile (or interplanetary) deployments aren't supposed to use the core internet protocols and participate in end-to-end communications? -- to unsubscribe send a message to namedroppers-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 Jul 3 23:47:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286D43A67F5; Fri, 3 Jul 2009 23:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.516 X-Spam-Level: X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 JajBnfpCBTVG; Fri, 3 Jul 2009 23:47:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 418573A67B4; Fri, 3 Jul 2009 23:47:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMyyM-000H6W-Qz for namedroppers-data0@psg.com; Sat, 04 Jul 2009 06:43:42 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMyy4-000H4z-Tn for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 06:43:37 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n646fAdc020447; Sat, 4 Jul 2009 06:41:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n646f5I1020446; Sat, 4 Jul 2009 06:41:05 GMT Date: Sat, 4 Jul 2009 06:41:05 +0000 From: bmanning@vacation.karoshi.com To: George Barwood Cc: Paul Vixie , Steve Crocker , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090704064105.GA20381@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> <99789.1246681775@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Jul 04, 2009 at 05:58:14AM +0100, George Barwood wrote: > > ----- Original Message ----- > From: "Paul Vixie" > To: "George Barwood" > Cc: "Steve Crocker" ; "DNSEXT WG" > Sent: Saturday, July 04, 2009 5:29 AM > Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition > > > >> From: "George Barwood" > >> Date: Sat, 4 Jul 2009 05:07:16 +0100 > >> > >> Would it not be better to fix the shortcomings of DNS transport over UDP > >> once and for all, rather than complicating higher levels of the protocol. > > > > no. not even if that were an accurate summation of scrocker's proposal. > > This was given as the motivation for the proposal. > > >> Is tackling the problem on a piece-meal basis a good way forward? > > > > for low bandwidth (mobile or interplanetary) clients, scrocker's proposal > > is a godsend, and no fix to the transport to allow for larger messages will > > solve that same problem. > > In that case the proposal should indicate that this is the goal, rather > than the avoidance of TCP. I suggest that low-bandwidth clients would do > better to use a secure channel to a high-bandwidth cache. i think i agree w/ you George, as long as the cache is no more than 2ms away from the client. what you are functionally describing is a client and cache that share a highbandwidth path (shared memory perhaps) and the client only occasionally queries the cache (low bandwidth). the outbound side of the cache may or may not have relative high or low bandwidth - its almost immaterial - as long as better cache mgmt is done. the DNS needs signaling tools - moreso now than before since there are more things the DNS needs to understand. this particular draft is looking at ways to signal supported algorithms. --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 Sat Jul 4 00:15:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2DE3A65A6; Sat, 4 Jul 2009 00:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLEknVDYt53V; Sat, 4 Jul 2009 00:15:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE7AD3A68C0; Sat, 4 Jul 2009 00:15:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMzPT-000J0O-1C for namedroppers-data0@psg.com; Sat, 04 Jul 2009 07:11:43 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMzPG-000Iz5-1s; Sat, 04 Jul 2009 07:11:37 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=iN9trEImHm/S2PHQQF5BNPvT32VCY/ZZbw3qxCqOgi/OPMdrIPMghfGv Dyfcya+HE+3qK4BmATxy+1XzxPcX3XBa+hdeCTnwt3eoKdyCyegtDFMTQ 9kUx1VOwaiNTAbK; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246691490; x=1278227490; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20algo-signal=20-03=20--=20Internet=20Draft=20to=20fa cilitate=20algorithm=0D=0A=20transition|Date:=20Sat,=204 =20Jul=202009=2008:11:08=20+0100|Message-ID:=20|To:=20Steve=20Crocker=20|Cc: =20DNSEXT=20WG=20,=0D=0A=09own er-namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<381D3088-6EBE-455F-A37C-CE562225AE00@shi nkuro.com>|References:=20 =20<381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com>; bh=dUp5DcIogizW7p5TkY64WjoqbOWsIImSkVwApbuxLtE=; b=C9op3k+zOiK9tm5eR0bhH5LozJVXSQN0R9pJfDJCC0kYOKi/0XUtaRrQ OtxwO9uAg8D01h7Dhv+BxhGNgSR/+b5HXXBzKhXJHbnhPERHedQ4F15Em 14Ce/uCJym7hhmv; X-IronPort-AV: E=Sophos;i="4.42,346,1243810800"; d="scan'208";a="11243234" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 04 Jul 2009 08:11:12 +0100 In-Reply-To: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> To: Steve Crocker Cc: DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Sat, 4 Jul 2009 08:11:08 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/07/2009 08:11:15 AM, Serialize complete at 04/07/2009 08:11:15 AM Content-Type: multipart/alternative; boundary="=_alternative 002778E6802575E9_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 002778E6802575E9_= Content-Type: text/plain; charset="US-ASCII" > Scott Rose and I wrote a proposal for an extension to the DNS query to > indicate which algorithms the querier understands. This is intended > to facilitate transition to new algorithms by providing information as > to how fully a new algorithm is understood. > > We have submitted this proposal to the IETF DNSEXT Working Group for > consideration. To move this forward, there has to be a sufficient set > of people willing to read and support the proposal. > > We are hereby asking for volunteers to review and support this proposal. I support this draft, and will review it. > We have already some feedback suggesting the querier should be able to > specify a list of algorithms instead of just he highest numbered one. > I think that's an appropriate suggestion and we'll work on that. > (Suggestions on how to do this in a way that is most convenient for > servers to process would be welcome. On the other hand, if the > servers can't really use the information in formulating a reply and > the main value will be for information gathering, the choice of format > doesn't matter too much.) I also agree that this option should support sending a _list_ of algorithms rather than the highest support algorithm. Seeing as the draft already excludes the algorithms above 252 it would seem that a bit-field would be appropriate, with the option length indicating how many bytes are in the bitfield. Thus a resolver supporting the current documented set (including NSEC3) would send (len = 1, code = 0b11111110). A resolver supporting RSA-2 and not MD5 might send (len = 2, code = 0b01|11111100). Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 002778E6802575E9_= Content-Type: text/html; charset="US-ASCII"
> Scott Rose and I wrote a proposal for an extension to the DNS query to  
> indicate which algorithms the querier understands.  This is intended  
> to facilitate transition to new algorithms by providing information as  
> to how fully a new algorithm is understood.
>
> We have submitted this proposal to the IETF DNSEXT Working Group for  
> consideration.  To move this forward, there has to be a sufficient set  
> of people willing to read and support the proposal.
>
> We are hereby asking for volunteers to review and support this proposal.


I support this draft, and will review it.

> We have already some feedback suggesting the querier should be able to  
> specify a list of algorithms instead of just he highest numbered one.  
> I think that's an appropriate suggestion and we'll work on that.  
> (Suggestions on how to do this in a way that is most convenient for  
> servers to process would be welcome.  On the other hand, if the  
> servers can't really use the information in formulating a reply and  
> the main value will be for information gathering, the choice of format  
> doesn't matter too much.)

I also agree that this option should support sending a _list_ of algorithms rather than the highest support algorithm.

Seeing as the draft already excludes the algorithms above 252 it would seem that a bit-field would be appropriate, with the option length indicating how many bytes are in the bitfield.

Thus a resolver supporting the current documented set (including NSEC3) would send (len = 1, code = 0b11111110).  A resolver supporting RSA-2 and not MD5 might send (len = 2, code = 0b01|11111100).

Ray

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


--=_alternative 002778E6802575E9_=-- -- to unsubscribe send a message to namedroppers-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 Jul 4 02:26:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420323A68CF; Sat, 4 Jul 2009 02:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzJrTOTz7Czh; Sat, 4 Jul 2009 02:26:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A40F23A67CC; Sat, 4 Jul 2009 02:26:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN1R2-00001y-GE for namedroppers-data0@psg.com; Sat, 04 Jul 2009 09:21:28 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN1Qr-000Pcp-8S for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 09:21:22 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id 82CDC7C417; Sat, 4 Jul 2009 09:21:13 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id F2A5875F61; Sat, 4 Jul 2009 12:21:11 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19023.7943.898827.705531@guava.gson.org> Date: Sat, 4 Jul 2009 12:21:11 +0300 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: <84573.1246658893@nsa.vix.com> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> <71853.1246639811@nsa.vix.com> <19022.22073.365617.198159@guava.gson.org> <84573.1246658893@nsa.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: Paul Vixie wrote: > i'm not aware of a nameserver that discards an NS RRset from cache when all > names are unreachable, in the way that i proposed. if such a nameserver is > developed, then i do suggest that it implement the holddown i also proposed. Why should the holddown be needed in a server that implements restarts by discarding the address-deprived NS RRset if it's not required in a server that implements restarts by other means? Those other means effectively come down to keeping the NS RRset cached but ignoring it. If it's not used, it might as well not be there - the end result is the same, and so is the amount of traffic sent to the parent. -- 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 Sat Jul 4 04:53:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B129C3A6836; Sat, 4 Jul 2009 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HszC+1iWh9-2; Sat, 4 Jul 2009 04:53:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A1083A67F5; Sat, 4 Jul 2009 04:53:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN3iq-0009gd-1S for namedroppers-data0@psg.com; Sat, 04 Jul 2009 11:48:00 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN3ie-0009ew-RM for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 11:47:54 +0000 Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp03.uc3m.es (Postfix) with ESMTP id 45F9B72D7B2 for ; Sat, 4 Jul 2009 13:47:44 +0200 (CEST) Message-ID: <4A4F415F.1070804@it.uc3m.es> Date: Sat, 04 Jul 2009 13:47:43 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] [Fwd: I-D Action:draft-ietf-behave-dns64-00.txt] Content-Type: multipart/mixed; boundary="------------080403050308050708090003" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------080403050308050708090003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, We have submitted a new version of the DNS64 draft. comments are welcome Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-ietf-behave-dns64-00.txt Fecha: Sat, 4 Jul 2009 04:45:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org CC: behave@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-00.txt Pages : 26 Date : 2009-07-04 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------080403050308050708090003 Content-Type: Message/External-body; name="draft-ietf-behave-dns64-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-behave-dns64-00.txt" Content-Type: text/plain Content-ID: <2009-07-04043810.I-D@ietf.org> --------------080403050308050708090003 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------080403050308050708090003-- -- to unsubscribe send a message to namedroppers-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 Jul 4 09:31:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379A43A691C; Sat, 4 Jul 2009 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgSAD0psAxrQ; Sat, 4 Jul 2009 09:31:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 484553A6846; Sat, 4 Jul 2009 09:31:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN826-0002nc-Ry for namedroppers-data0@psg.com; Sat, 04 Jul 2009 16:24:10 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN81X-0002k1-SY for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 16:23:41 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0E6FBA7F9C for ; Sat, 4 Jul 2009 16:23:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "DNSEXT WG" Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-Reply-To: Your message of "Sat, 04 Jul 2009 08:07:01 +0100." <08E032BA742241D1A5BC75CC8014CFF4@localhost> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> <99789.1246681775@nsa.vix.com> <1846.1246684595@nsa.vix.com> <08E032BA742241D1A5BC75CC8014CFF4@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 04 Jul 2009 16:23:35 +0000 Message-ID: <27271.1246724615@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Sat, 4 Jul 2009 08:07:01 +0100 > ... > i.e. if we are going to have signalling to save bandwidth, should it aim > to be fairly comprehensive. "saving bandwidth" is not quite the right way to describe the goal. on a satellite (or other space-oriented) path, bandwidth is readily available but latency is absurdly long and therefore round trips are the thing to avoid, which would include many-step negotiation, or TCP 3-way. "fairly comprehensive" sounds good but i think this EDNS OPT subpart ought to focus on DNSSEC and leave out A/AAAA negotiation (since the IAB's position is that eventually AAAA will drive out A and moot any such option) and leave out zone versioning (since RFC 2308 already covers the many uses of an SOA to a recursive server, and since name compression works particularly well there.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 4 09:36:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217E33A691C; Sat, 4 Jul 2009 09:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uphQwn346Mx; Sat, 4 Jul 2009 09:36:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E2183A6846; Sat, 4 Jul 2009 09:36:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN8BL-0003VK-UC for namedroppers-data0@psg.com; Sat, 04 Jul 2009 16:33:43 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN8BA-0003UK-7q for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 16:33:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EDE7DA7F9A for ; Sat, 4 Jul 2009 16:33:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Clarification on RFC 2181 In-Reply-To: Your message of "Sat, 04 Jul 2009 12:21:11 +0300." <19023.7943.898827.705531@guava.gson.org> References: <6E84C5F60655486683DC6009213B02AA@localhost> <6DF152BE76CD4A31BDD9A0F05C82D843@localhost> <3efd34cc0907021134g3940bc15y498884bf4e0b3ba6@mail.gmail.com> <19021.6478.381852.351820@guava.gson.org> <29210.1246575664@nsa.vix.com> <19021.51994.80438.865585@guava.gson.org> <71853.1246639811@nsa.vix.com> <19022.22073.365617.198159@guava.gson.org> <84573.1246658893@nsa.vix.com> <19023.7943.898827.705531@guava.gson.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 04 Jul 2009 16:33:31 +0000 Message-ID: <27684.1246725211@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Sat, 4 Jul 2009 12:21:11 +0300 > From: gson@araneus.fi (Andreas Gustafsson) > > Paul Vixie wrote: > > i'm not aware of a nameserver that discards an NS RRset from cache when > > all names are unreachable, in the way that i proposed. if such a > > nameserver is developed, then i do suggest that it implement the > > holddown i also proposed. > > Why should the holddown be needed in a server that implements restarts by > discarding the address-deprived NS RRset if it's not required in a server > that implements restarts by other means? Those other means effectively > come down to keeping the NS RRset cached but ignoring it. If it's not > used, it might as well not be there - the end result is the same, and so > is the amount of traffic sent to the parent. the goal of a holddown is to prevent restarts from occuring in tight loops. that is, if a stub is asking for www.example.com every stub-to-recursive RTT (a not-uncommon situation due to the way applications are often programmed) and if .com's example.com delegation is correct whereas example.com's apex NS RRset is wrong (another not-uncommon situation) and www.example.com's TTL is zero for load balancing reasons (again, not as uncommon as i'd like), we would see a restart on every second request for www.example.com by a stub. with a lot of stubs doing this on a lot of names, the only protection we have against flooding the authority servers with uselessly repeated questions that all receive the same (correct) delegation response is some kind of holddown in the restart logic in the recursive caching servers. if they have no such restart logic then they do not need a holddown, since the child-apex NS RRset TTL will function as a holddown. (to see a lot (billions of) of useless repeated queries to authority servers for delegation-mostly zones, see the root servers' or the .CNO servers' query logs.) -- to unsubscribe send a message to namedroppers-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 Jul 4 09:55:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865C43A67B7; Sat, 4 Jul 2009 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVfMsNJzKv+4; Sat, 4 Jul 2009 09:55:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B09AE3A67B6; Sat, 4 Jul 2009 09:55:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN8TG-0004jT-NG for namedroppers-data0@psg.com; Sat, 04 Jul 2009 16:52:14 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN8T5-0004ie-Or for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 16:52:09 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n64GpxpE007402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jul 2009 09:52:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5BA727DA635F4EC98B5E8BD717243C40@localhost> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> Date: Sat, 4 Jul 2009 09:51:56 -0700 To: "George Barwood" , "Steve Crocker" , "DNSEXT WG" From: Paul Hoffman Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 5:07 AM +0100 7/4/09, George Barwood wrote: >Would it not be better to fix the shortcomings of DNS transport over UDP >once and for all, rather than complicating higher levels of the protocol. Maybe, that that is only one of the purposes of the draft that this tread is about. The draft lists other reasons as well. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From rationing1@sanao.com Sat Jul 4 10:41:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B051F3A69D7; Sat, 4 Jul 2009 10:41:23 -0700 (PDT) X-Quarantine-ID: <9tq18774YPzo> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: part did not end with expected boundary X-Spam-Flag: NO X-Spam-Score: -71.95 X-Spam-Level: X-Spam-Status: No, score=-71.95 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tq18774YPzo; Sat, 4 Jul 2009 10:41:23 -0700 (PDT) Received: from 122-124-0-94.dynamic.hinet.net (122-124-0-94.dynamic.hinet.net [122.124.0.94]) by core3.amsl.com (Postfix) with ESMTP id 73C103A67B6; Sat, 4 Jul 2009 10:41:22 -0700 (PDT) Message-ID: <000d01c9fcce$b158d020$6400a8c0@rationing1> From: emu-request@ietf.org To: Subject: Cleanse and Detoxify Your Body Date: Sun, 5 Jul 2009 01:41:42 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9FCCE.B158D020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9FCCE.B158D020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Slow down your aging process today by starting your free trial of Acai Slim= From owner-namedroppers@ops.ietf.org Sat Jul 4 11:34:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09943A6A88; Sat, 4 Jul 2009 11:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.95 X-Spam-Level: *** X-Spam-Status: No, score=3.95 tagged_above=-999 required=5 tests=[AWL=1.717, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcAxecvpF7u1; Sat, 4 Jul 2009 11:34:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BDFC3A67F7; Sat, 4 Jul 2009 11:33:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN9yk-000E42-R8 for namedroppers-data0@psg.com; Sat, 04 Jul 2009 18:28:50 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MN9yZ-000E2i-6x for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 18:28:44 +0000 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MN9yR-00053S-MC; Sat, 04 Jul 2009 19:28:31 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MN9yP-0001wp-Nb; Sat, 04 Jul 2009 19:28:29 +0100 Message-ID: From: "George Barwood" To: "Paul Vixie" , "DNSEXT WG" References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> <99789.1246681775@nsa.vix.com> <1846.1246684595@nsa.vix.com> <08E032BA742241D1A5BC75CC8014CFF4@localhost> <27271.1246724615@nsa.vix.com> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Date: Sat, 4 Jul 2009 19:28:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C6_01C9FCDD.9907FFA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_07C6_01C9FCDD.9907FFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: "Paul Vixie" To: "DNSEXT WG" Sent: Saturday, July 04, 2009 5:23 PM Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate = algorithm transition=20 > .. > and leave > out zone versioning (since RFC 2308 already covers the many uses of an = SOA to > a recursive server, and since name compression works particularly well = there.) I guess I was referring to this paragraph from RFC 1034, end of section = 3.4.4=20 "Some experiments have also been proposed which will use this feature. The idea is that if cached data is known to come from a particular zone, and if an authoritative copy of the zone's SOA is obtained, and if the zone's SERIAL has not changed since the data was cached, then the TTL of the cached data can be reset to the zone MINIMUM value if it is smaller. This usage is mentioned for planning purposes only, and is not recommended as yet." I guess the question is whether it can yet be recommended, nearly 22 = years later :) I think BIND sends the child NS and glue with each response. Presumably to maintain the child NS and glue in the cache, reducing traffic to the parent (or is the real aim to allow the NS/glue TTL to be = reduced?).=20 With DNSSEC, since each glue record will have a signature, responses can get large rather easily ( dig ns se +dnssec @a.ns.se =3D = 2706 bytes ). Sending the SOA would seem to be a more efficient way to accomplish the TTL refresh, provided caches interpret this as allowing TTLs for the = zone to be reset=20 to the originally transmitted values ( I don't know why the paragraph = from=20 RFC 1034 mentions the zone MIMIMUM value, that seems illogical ). On the other hand, if zones get re-signed daily, and the NS TTL is of = this order, there is no real saving. ------=_NextPart_000_07C6_01C9FCDD.9907FFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
----- Original Message -----
From: = "Paul Vixie"=20 <vixie@isc.org>
To: "DNSEXT WG"=20 <namedroppers@ops.ietf.org>
Sent: Saturday, July 04, 2009 5:23=20 PM
Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to = facilitate=20 algorithm transition

> ..
>  and leave
> out = zone=20 versioning (since RFC 2308 already covers the many uses of an SOA = to
> a=20 recursive server, and since name compression works particularly well=20 there.)

I guess I was referring to this paragraph from RFC 1034, = end of=20 section 3.4.4 

"Some experiments have also been proposed which will use this=20 feature.
The idea is that if cached data is known to come from a = particular=20 zone,
and if an authoritative copy of the zone's SOA is obtained, and = if=20 the
zone's SERIAL has not changed since the data was cached, then the = TTL=20 of
the cached data can be reset to the zone MINIMUM value if it is=20 smaller.
This usage is mentioned for planning purposes only, and is=20 not
recommended as yet."

I guess the question is whether it = can yet be=20 recommended, nearly 22 years later :)

I think BIND sends the = child=20 NS and glue with each response.
Presumably to maintain the child NS = and glue=20 in the cache, reducing
traffic to the parent (or is the real aim to = allow the=20 NS/glue TTL to be reduced?).
With DNSSEC, since each glue record will have a=20 signature,
responses can get=20 large rather easily ( dig ns se +dnssec @a.ns.se  =3D 2706 bytes=20 ).

Sending the SOA would seem to be a more efficient way to=20 accomplish
the TTL refresh, provided caches interpret this as = allowing TTLs=20 for the zone to be reset
to the originally transmitted values ( = I don't know=20 why the paragraph from
RFC 1034 mentions the zone MIMIMUM = value, that=20 seems illogical ).
 
On the other hand, if zones get = re-signed daily,=20 and the NS TTL is of this
order, there is no real saving.
 
 
------=_NextPart_000_07C6_01C9FCDD.9907FFA0-- -- to unsubscribe send a message to namedroppers-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 Jul 4 11:52:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1843A688C; Sat, 4 Jul 2009 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.846 X-Spam-Level: *** X-Spam-Status: No, score=3.846 tagged_above=-999 required=5 tests=[AWL=1.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrsrwrg2NJUa; Sat, 4 Jul 2009 11:52:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E1043A6874; Sat, 4 Jul 2009 11:52:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNAIp-000FwO-7L for namedroppers-data0@psg.com; Sat, 04 Jul 2009 18:49:35 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNAId-000Fuj-PL; Sat, 04 Jul 2009 18:49:29 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MNAIb-0001Gz-W0; Sat, 04 Jul 2009 19:49:22 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MNAIb-0005Ts-Bk; Sat, 04 Jul 2009 19:49:21 +0100 Message-ID: <691CC4A3BCE04CD7BFF06CC38F9A541B@localhost> From: "George Barwood" To: "Steve Crocker" , Cc: "DNSEXT WG" , References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Date: Sat, 4 Jul 2009 19:49:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07EF_01C9FCE0.83114230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_07EF_01C9FCE0.83114230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Ray.Bellis@nominet.org.uk=20 To: Steve Crocker=20 Cc: DNSEXT WG ; owner-namedroppers@ops.ietf.org=20 Sent: Saturday, July 04, 2009 8:11 AM Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate = algorithm transition > I also agree that this option should support sending a _list_ of = algorithms rather than the highest=20 > support algorithm.=20 + 1 > Seeing as the draft already excludes the algorithms above 252 it would = seem that a bit-field would be=20 > appropriate, with the option length indicating how many bytes are in = the bitfield.=20 Err... AFAICS there are no algorithms above 252, just reserved values = indicating private algorithms (pace 255). I think a list of 1 byte algorithm values is fine, and it's not = necessary to cater for private=20 algorithms at this stage. If you want private algorithm support, = logically an identifier above 252=20 would be followed by the required private algorithm identification, as = defined by RFC 1034 section A.1.1. ------=_NextPart_000_07EF_01C9FCE0.83114230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Ray.Bellis@nominet.org.uk =
Cc: DNSEXT WG ; owner-namedroppers@ops.ie= tf.org=20
Sent: Saturday, July 04, 2009 8:11 AM
Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to=20 facilitate algorithm transition


> I also agree that this = option should=20 support sending a _list_ of algorithms rather than the highest=20
> support algorithm.
 
+ 1

> Seeing as the draft already excludes = the=20 algorithms above 252 it would seem that a bit-field would be =
> appropriate, with the option length = indicating how=20 many bytes are in the bitfield.
 
Err... AFAICS there are no algorithms = above 252,=20 just reserved values indicating private algorithms (pace = 255).
I think a list of 1 byte algorithm = values is fine,=20 and it's not necessary to cater for private
algorithms at this stage. If you want private algorithm support, logically an = identifier above=20 252
would be followed by=20 the required private algorithm = identification, as=20 defined by RFC 1034 section A.1.1.
 
 
 
------=_NextPart_000_07EF_01C9FCE0.83114230-- -- to unsubscribe send a message to namedroppers-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 Jul 4 12:36:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AF93A6A8B; Sat, 4 Jul 2009 12:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruaFU8aVQY4p; Sat, 4 Jul 2009 12:36:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 822433A6960; Sat, 4 Jul 2009 12:36:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNAzR-000Jwi-Mp for namedroppers-data0@psg.com; Sat, 04 Jul 2009 19:33:37 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNAzG-000Jva-Rl for namedroppers@ops.ietf.org; Sat, 04 Jul 2009 19:33:32 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n64JXJHW015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jul 2009 12:33:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <691CC4A3BCE04CD7BFF06CC38F9A541B@localhost> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <691CC4A3BCE04CD7BFF06CC38F9A541B@localhost> Date: Sat, 4 Jul 2009 12:33:18 -0700 To: "George Barwood" , "Steve Crocker" , From: Paul Hoffman Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Cc: "DNSEXT WG" Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 7:49 PM +0100 7/4/09, George Barwood wrote: >I think a list of 1 byte algorithm values is fine, and it's not necessary to cater for private >algorithms at this stage. This is not just for "private algorithms": it is also for fully-defined and interoperable algorithms that could not be on standards track for any reason. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From bedtimesjw0@ristorantedagianni.com Sat Jul 4 13:48:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCDF3A68A1; Sat, 4 Jul 2009 13:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.65 X-Spam-Level: X-Spam-Status: No, score=-15.65 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4s7P88srDAs; Sat, 4 Jul 2009 13:48:33 -0700 (PDT) Received: from c-69-246-188-8.hsd1.al.comcast.net (c-69-246-188-8.hsd1.al.comcast.net [69.246.188.8]) by core3.amsl.com (Postfix) with ESMTP id 4F6913A6821; Sat, 4 Jul 2009 13:48:32 -0700 (PDT) Received: from 69.246.188.8 by mail.ristorantedagianni.com; Sat, 4 Jul 2009 13:48:24 -0800 From: disman-bounces@ietf.org To: disman-bounces@ietf.org Subject: Pierce her deeper with these herbs Date: Sat, 4 Jul 2009 13:48:24 -0800 Message-ID: MIME-version: 1.0 Content-type: text/html; charset="iso-8859-2"
Are you having difficulty viewing our HTML email?
View this email in a browser window.

Your daily reminder

 
Long and hard - can be yours
 
 

(c) 2009 dpnsf Inc.

 

This email was delivered to you by Iwqtuoeyn. If you would like to be removed from this email distribution list, please click here. We will honor your request. To report abuse, please click here.

Like this newsletter? Please forward to a friend!

 
From owner-namedroppers@ops.ietf.org Sat Jul 4 18:53:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA6E3A6884; Sat, 4 Jul 2009 18:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48AS0M-oorNa; Sat, 4 Jul 2009 18:53:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B7DB3A6824; Sat, 4 Jul 2009 18:53:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNGp1-000JLL-Eo for namedroppers-data0@psg.com; Sun, 05 Jul 2009 01:47:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNGoq-000JKi-4S for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 01:47:09 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A3006A800E for ; Sun, 5 Jul 2009 01:47:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Sat, 04 Jul 2009 20:28:16 +0100." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 05 Jul 2009 01:47:03 +0000 Message-ID: <49238.1246758423@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Sat, 4 Jul 2009 20:28:16 +0100 > > Some thoughts on sending child NS RRsets and glue, in a DNSSEC context. > > I suggest sending the child NS RRset with each response, but NOT the glue. the child can only usefully send in-zone or sub-zone glue, not sibling or unrelated glue. for kashpureff resistance, any other glue will be ignored. in the absence of in-zone or sub-zone glue, not all nameservers will have a way to be reached. so i think the situation is already at its local minima. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From overspecializel4@rvpwinona.com Sun Jul 5 01:33:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272D13A69C8; Sun, 5 Jul 2009 01:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.479 X-Spam-Level: X-Spam-Status: No, score=-26.479 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+FB-Zmz3YP3; Sun, 5 Jul 2009 01:33:13 -0700 (PDT) Received: from cm-85-152-241-182.telecable.es (cm-85-152-241-182.telecable.es [85.152.241.182]) by core3.amsl.com (Postfix) with ESMTP id A8EFF3A68E2; Sun, 5 Jul 2009 01:33:12 -0700 (PDT) Date: Sun, 5 Jul 2009 10:33:34 +0100 From: dnsext-archive@lists.ietf.org Subject: look great and speed up your metabolism with Acai berry. To: Message-ID: <000d01c9fd4b$48be10c0$6400a8c0@overspecializel4> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal BurnFat & Lose Wieght, Acai Berry Free Sample Enhance your life with the worlds # 1 Miracle food. Hit the button now http://aibaboso.cn From owner-namedroppers@ops.ietf.org Sun Jul 5 06:41:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675233A6AC2; Sun, 5 Jul 2009 06:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.711 X-Spam-Level: **** X-Spam-Status: No, score=4.711 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsGaqG3osIUZ; Sun, 5 Jul 2009 06:41:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8CC2A3A6B72; Sun, 5 Jul 2009 06:41:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNRuJ-000ELz-P2 for namedroppers-data0@psg.com; Sun, 05 Jul 2009 13:37:27 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNRu8-000EL1-IA for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 13:37:22 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MNRu7-000879-Ed; Sun, 05 Jul 2009 14:37:15 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MNRu3-0008Tt-Q0; Sun, 05 Jul 2009 14:37:11 +0100 Message-ID: <67614A146BC84DCCAAC8FDCBD33D2C84@localhost> From: "George Barwood" To: "Paul Vixie" , References: <49238.1246758423@nsa.vix.com> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Sun, 5 Jul 2009 14:37:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgVml4aWUiIDx2aXhp ZUBpc2Mub3JnPg0KVG86IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogU3VuZGF5 LCBKdWx5IDA1LCAyMDA5IDI6NDcgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBOYW1lIHNlcnZl ciBhZ2lsaXR5IHdpdGggRE5TU0VDIA0KDQoNCj4+IEZyb206ICJHZW9yZ2UgQmFyd29vZCIgPGdl b3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+DQo+PiBEYXRlOiBTYXQsIDQgSnVsIDIwMDkg MjA6Mjg6MTYgKzAxMDANCj4+IA0KPj4gU29tZSB0aG91Z2h0cyBvbiBzZW5kaW5nIGNoaWxkIE5T IFJSc2V0cyBhbmQgZ2x1ZSwgaW4gYSBETlNTRUMgY29udGV4dC4NCj4+IA0KPj4gSSBzdWdnZXN0 IHNlbmRpbmcgdGhlIGNoaWxkIE5TIFJSc2V0IHdpdGggZWFjaCByZXNwb25zZSwgYnV0IE5PVCB0 aGUgZ2x1ZS4NCj4gDQo+IHRoZSBjaGlsZCBjYW4gb25seSB1c2VmdWxseSBzZW5kIGluLXpvbmUg b3Igc3ViLXpvbmUgZ2x1ZSwgbm90IHNpYmxpbmcgb3INCj4gdW5yZWxhdGVkIGdsdWUuICBmb3Ig a2FzaHB1cmVmZiByZXNpc3RhbmNlLCBhbnkgb3RoZXIgZ2x1ZSB3aWxsIGJlIGlnbm9yZWQuDQo+ IA0KPiBpbiB0aGUgYWJzZW5jZSBvZiBpbi16b25lIG9yIHN1Yi16b25lIGdsdWUsIG5vdCBhbGwg bmFtZXNlcnZlcnMgd2lsbCBoYXZlDQo+IGEgd2F5IHRvIGJlIHJlYWNoZWQuDQoNCkFoLCBob2xk IG9uLiBJJ20gdGFsa2luZyBhYm91dCByZXF1ZXN0cyB0byB0aGUgY2hpbGQsIHdoZXJlIHRoZSBj aGlsZCByZXR1cm5zDQp1bnNvbGljaXRlZCBOUyByZWNvcmRzIGFuZCBhc3NvY2lhdGVkIEEvQUFB QS9SUlNJRyByZWNvcmRzLCBmb3INCnJlYXNvbnMgdGhhdCBhcmUgbm90IDEwMCUgY2xlYXIgKCBJ IHRoaW5rIG9ubHkgQklORCBkb2VzIHRoaXMsIGFuZCB0aGVuDQpvbmx5IGZvciBwb3NpdGl2ZSBh dXRob3JpdGF0aXZlIHJlc3BvbnNlcywgaS5lLiBub3QgZm9yIHJlZmVycmFscyBvciBOeERvbWFp bi8NCk5vRGF0YSByZXNwb25zZXMgKS4NCg0KVGhlIHBhcmVudCB3aWxsIGFscmVhZHkgaGF2ZSBw cm92aWRlZCBjb21wbGV0ZSAodW5zaWduZWQpIGdsdWUgd2hlcmUgcmVxdWlyZWQuDQoNCj4gc28g aSB0aGluayB0aGUgc2l0dWF0aW9uIGlzIGFscmVhZHkgYXQgaXRzIGxvY2FsIG1pbmltYS4NCj4g DQo+IC0tDQo+IHRvIHVuc3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdlIHRvIG5hbWVkcm9wcGVycy1y ZXF1ZXN0QG9wcy5pZXRmLm9yZyB3aXRoDQo+IHRoZSB3b3JkICd1bnN1YnNjcmliZScgaW4gYSBz aW5nbGUgbGluZSBhcyB0aGUgbWVzc2FnZSB0ZXh0IGJvZHkuDQo+IGFyY2hpdmU6IDxodHRwOi8v b3BzLmlldGYub3JnL2xpc3RzL25hbWVkcm9wcGVycy8+DQo+ -- to unsubscribe send a message to namedroppers-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 Jul 5 10:26:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1583A69DA; Sun, 5 Jul 2009 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6ohQc9k4VKV; Sun, 5 Jul 2009 10:26:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E6DB3A6B2A; Sun, 5 Jul 2009 10:26:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNVMQ-0003Vs-2q for namedroppers-data0@psg.com; Sun, 05 Jul 2009 17:18:42 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNVME-0003V7-TL for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 17:18:36 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6D8FAA818C for ; Sun, 5 Jul 2009 17:18:29 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Sun, 05 Jul 2009 14:04:38 +0100." <72CE0A0D4D644A599AD7ABB6A169157B@localhost> References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 05 Jul 2009 17:18:29 +0000 Message-ID: <86172.1246814309@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Sun, 5 Jul 2009 14:04:38 +0100 > > I'm looking at queries like > > dig txt se @a.ns.se +dnssec > > which gives a 2,941 byte response, because it has 15 RRSIG records. > > One for the requested TXT, one for the NS, and 13 for the A and AAAA records. > I'm suggesting it is not appropriate to send the A and AAAA records and > their signatures. > > Especially if this causes truncation, or causes the response to be > 1500 > bytes. i tend to agree that sending the NS RRsets on authoritative responses is mostly a waste of resources. i believe the current thinking is, apex NS RRsets can change, and so every authoritative response should have the power to overwrite them. also, delegation NS RRsets are not signed in the parent, whereas the apex NS RRsets are. so we're stuck with the NS RRsets. so what you could ponder is whether the additional data rules could be relaxed to include an "unless it would cause truncation" exception, as in: > Instead they can be given very high TTLs, so that caches need fetch them > only once. since the A/AAAA names in your example are all in-zone and are all ref'd by the NS RRset, there's presumptive nonfetchability of those A/AAAA RRsets and therefore presumptive nonreachability of the zone itself, if they are not included whenever the NS RRset appears in an authority section. this gets back to yesterday's topic here -- a new and protocol-defined kind of iteration restart whenever a zone goes unreachable. if we knew that all caching servers were going to perform iteration restart (with holddown) then we could leave out A/AAAA RRsets from the additional section when sending NS RRsets in the authority section, unless it's a referral. if we can't assume iteration restart, then we have to keep sending these A/AAAA's. --- > From: "George Barwood" > Date: Sun, 5 Jul 2009 14:37:06 +0100 > > Ah, hold on. I'm talking about requests to the child, where the child > returns unsolicited NS records and associated A/AAAA/RRSIG records, for > reasons that are not 100% clear ( I think only BIND does this, and then > only for positive authoritative responses, i.e. not for referrals or > NxDomain/ NoData responses ). it's not just BIND. a close re-reading of RFC 2308 seems indicated here. > The parent will already have provided complete (unsigned) glue where > required. yes, and the fact that it's unsigned in the parent, is one of the reasons it has to be sent by the child. -- to unsubscribe send a message to namedroppers-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 Jul 5 11:22:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A63C3A6C0E; Sun, 5 Jul 2009 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[AWL=-0.551, 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 n120tDQ+tdLT; Sun, 5 Jul 2009 11:22:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7AF83A6BB6; Sun, 5 Jul 2009 11:22:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNWIZ-00083y-MU for namedroppers-data0@psg.com; Sun, 05 Jul 2009 18:18:47 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNWIO-00083B-CZ for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 18:18:41 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MNWIL-0002bh-S2; Sun, 05 Jul 2009 20:18:33 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MNWIL-0004uQ-F5; Sun, 05 Jul 2009 20:18:33 +0200 From: Florian Weimer To: Steve Crocker Cc: DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> Date: Sun, 05 Jul 2009 20:18:33 +0200 In-Reply-To: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> (Steve Crocker's message of "Fri, 3 Jul 2009 17:55:08 -0400") Message-ID: <87prcfq9hi.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Steve Crocker: > Scott Rose and I wrote a proposal for an extension to the DNS query to > indicate which algorithms the querier understands. This is intended > to facilitate transition to new algorithms by providing information as > to how fully a new algorithm is understood. The proposed protocol uses EDNS0 option codes, so it requires the revised version of RFC 2671 (and will not work that with some BIND versions still under vendor support, IIRC). > The end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to > indicate that it wishes to receive DNSSEC RRs in the response. There is subsequent language in the draft which deals with the DO=0 case, which appears to be unnecessary. > Caches MUST NOT set the AU option on any outgoing query from the > cache when performing recursion on behalf of a stub client. Why? And how does the cache tell a stub client from a non-stub client? I think for a long time to come, most DO=1 queries will come from non-stubs, so the proposed protocol should apply there as well. > 5.1. Intermediate Proxy Resolvers What's this? I think the whole thing makes sense if it can be applied to most non-recursive DNS queries. It might also give DNSSEC signature algorithm agility in practice, and not on paper. On the other hand, the DO story suggests to me that chances of widespread implementations are pretty dim. 8-( -- to unsubscribe send a message to namedroppers-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 Jul 5 12:29:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60D33A69A8; Sun, 5 Jul 2009 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLa0NVNzyRxG; Sun, 5 Jul 2009 12:29:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE1D13A695F; Sun, 5 Jul 2009 12:29:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNXIt-000CrP-LL for namedroppers-data0@psg.com; Sun, 05 Jul 2009 19:23:11 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNXIf-000CqF-JJ for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 19:23:05 +0000 Received: by gxk1 with SMTP id 1so5751145gxk.17 for ; Sun, 05 Jul 2009 12:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.54.6 with SMTP id c6mr3397177aga.108.1246821776382; Sun, 05 Jul 2009 12:22:56 -0700 (PDT) In-Reply-To: References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> Date: Sun, 5 Jul 2009 12:22:56 -0700 Message-ID: Subject: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 5, 2009 at 10:18 AM, Paul Vixie wrote: > i tend to agree that sending the NS RRsets on authoritative responses is > mostly a waste of resources. =A0i believe the current thinking is, apex N= S > RRsets can change, and so every authoritative response should have the > power to overwrite them. It also provides zones a way to lessen their dependence on the root and TLD name servers. =A0E.g., if www.isc.org is resolved by a cache at least once every ~12 hours, the cache only has to contact the root and .org name servers on the first lookup. =A0Every www.isc.org query response includes new NS and A/AAAA records with fresh TTLs that the cache can hold onto for another 12 hours. P.S. This is at least the third time in recent history that I've had to send mail to namedroppers multiple times because it's rejecting mail from Google. -- to unsubscribe send a message to namedroppers-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 Jul 5 12:51:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8677E3A6C0B; Sun, 5 Jul 2009 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 OHD9CWhxW5jN; Sun, 5 Jul 2009 12:51:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B988E3A6BFE; Sun, 5 Jul 2009 12:51:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNXhP-000Euv-3j for namedroppers-data0@psg.com; Sun, 05 Jul 2009 19:48:31 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNXhD-000EtQ-23 for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 19:48:25 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MNXhA-0004p8-2V; Sun, 05 Jul 2009 21:48:16 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MNXh9-0001ok-Mv; Sun, 05 Jul 2009 21:48:15 +0200 From: Florian Weimer To: Matthew Dempsky Cc: IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> Date: Sun, 05 Jul 2009 21:48:15 +0200 In-Reply-To: (Matthew Dempsky's message of "Sun, 5 Jul 2009 12:22:56 -0700") Message-ID: <87ljn2oqrk.fsf@mid.deneb.enyo.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: * Matthew Dempsky: > It also provides zones a way to lessen their dependence on the root > and TLD name servers. =A0E.g., if www.isc.org is resolved by a cache at > least once every ~12 hours, the cache only has to contact the root and > .org name servers on the first lookup. =A0Every www.isc.org query > response includes new NS and A/AAAA records with fresh TTLs that the > cache can hold onto for another 12 hours. Any resolver which does this is buggy in the sense that it requires manual cache flushes from time to time. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 5 13:34:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E6A3A6B4D; Sun, 5 Jul 2009 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6uvEMbVR34q; Sun, 5 Jul 2009 13:34:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7BCB28C0DF; Sun, 5 Jul 2009 13:33:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNYKh-000IO7-H2 for namedroppers-data0@psg.com; Sun, 05 Jul 2009 20:29:07 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNYKW-000INN-Q1 for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 20:29:02 +0000 Received: by gxk1 with SMTP id 1so5788272gxk.17 for ; Sun, 05 Jul 2009 13:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.87.5 with SMTP id k5mr3452586agb.20.1246825735597; Sun, 05 Jul 2009 13:28:55 -0700 (PDT) In-Reply-To: <87ljn2oqrk.fsf@mid.deneb.enyo.de> References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> Date: Sun, 5 Jul 2009 13:28:55 -0700 Message-ID: Subject: Re: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: Florian Weimer Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 5, 2009 at 12:48 PM, Florian Weimer wrote: > Any resolver which does this is buggy in the sense that it requires > manual cache flushes from time to time. Why? If a zone changes name servers, they have to continue maintaining the old name servers for a while anyway, which includes updating the NS and A/AAAA records that the old name servers publish. -- to unsubscribe send a message to namedroppers-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 Jul 5 13:47:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3E53A6C5B; Sun, 5 Jul 2009 13:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[AWL=-0.503, 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 sEMH9AKcTYVh; Sun, 5 Jul 2009 13:47:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5413A3A6C67; Sun, 5 Jul 2009 13:47:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNYYR-000JiW-MQ for namedroppers-data0@psg.com; Sun, 05 Jul 2009 20:43:19 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNYYG-000Jgu-QD for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 20:43:14 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MNYYE-0007g7-OQ; Sun, 05 Jul 2009 22:43:06 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MNYYE-0003Uu-CH; Sun, 05 Jul 2009 22:43:06 +0200 From: Florian Weimer To: Matthew Dempsky Cc: IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> Date: Sun, 05 Jul 2009 22:43:06 +0200 In-Reply-To: (Matthew Dempsky's message of "Sun, 5 Jul 2009 13:28:55 -0700") Message-ID: <87zlbin9np.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Matthew Dempsky: > On Sun, Jul 5, 2009 at 12:48 PM, Florian Weimer wrote: >> Any resolver which does this is buggy in the sense that it requires >> manual cache flushes from time to time. > > Why? If a zone changes name servers, they have to continue > maintaining the old name servers for a while anyway, which includes > updating the NS and A/AAAA records that the old name servers publish. People don't do that when changing name servers. Servers to which the zone isn't delegated anymore keep publishing stale data. -- to unsubscribe send a message to namedroppers-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 Jul 5 14:00:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB1128C161; Sun, 5 Jul 2009 14:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlIPnDyJKzX3; Sun, 5 Jul 2009 14:00:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F27828C170; Sun, 5 Jul 2009 14:00:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNYlW-000LG5-Fr for namedroppers-data0@psg.com; Sun, 05 Jul 2009 20:56:50 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNYlL-000LFE-Ed for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 20:56:44 +0000 Received: by gxk1 with SMTP id 1so5803822gxk.17 for ; Sun, 05 Jul 2009 13:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.83.2 with SMTP id g2mr3462908agb.63.1246827367857; Sun, 05 Jul 2009 13:56:07 -0700 (PDT) In-Reply-To: <87zlbin9np.fsf@mid.deneb.enyo.de> References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> Date: Sun, 5 Jul 2009 13:56:07 -0700 Message-ID: Subject: Re: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: Florian Weimer Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 5, 2009 at 1:43 PM, Florian Weimer wrote: > People don't do that when changing name servers. =A0Servers to which the > zone isn't delegated anymore keep publishing stale data. If we need to support people who won't properly handle how to transition their name servers, then yes, we should follow Paul's suggestion and have name servers stop including NS records in authoritative answers by default. -- to unsubscribe send a message to namedroppers-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 Jul 5 14:48:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D844B3A6B56; Sun, 5 Jul 2009 14:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu-Ej0y+Br4k; Sun, 5 Jul 2009 14:48:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8DD33A6803; Sun, 5 Jul 2009 14:48:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNZVf-000PbR-Og for namedroppers-data0@psg.com; Sun, 05 Jul 2009 21:44:31 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNZVR-000PaP-Cz for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 21:44:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0F7BEA81E3; Sun, 5 Jul 2009 21:44:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Sun\, 05 Jul 2009 12\:22\:56 MST." References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 05 Jul 2009 21:44:17 +0000 Message-ID: <96370.1246830257@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Sun, 5 Jul 2009 12:22:56 -0700 > From: Matthew Dempsky >=20 > ... =A0E.g., if www.isc.org is resolved by a cache at least once every ~12 > hours, the cache only has to contact the root and .org name servers on > the first lookup. =A0Every www.isc.org query response includes new NS and > A/AAAA records with fresh TTLs that the cache can hold onto for another > 12 hours. interestingly, this turns into an optimization opportunity in a caching recursive nameserver. if a replacement ns rrset is the same as what's in cache, it can be cheaper to just update the cache ttl than to replace the rrset in cache. > P.S. This is at least the third time in recent history that I've had to > send mail to namedroppers multiple times because it's rejecting mail from > Google. google's mail service is abuse-prone and highly scalable. any scalable free service will be abuse-prone, and the providers of such services are practicing a form of the "chemical polluter business model". if you want your mail to get through, then send it from a better neighborhood. for a list of same, see . i do not blame the operators of the namedroppers@ mailing list server for periodically rejecting all mail from google. i do it here, it's practical self defense. -- to unsubscribe send a message to namedroppers-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 Jul 5 15:00:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D043A6947; Sun, 5 Jul 2009 15:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdGljOYKjfID; Sun, 5 Jul 2009 15:00:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A36363A6B00; Sun, 5 Jul 2009 15:00:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNZis-0000yO-44 for namedroppers-data0@psg.com; Sun, 05 Jul 2009 21:58:10 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNZie-0000wo-BO for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 21:58:04 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 123A8A81CD for ; Sun, 5 Jul 2009 21:57:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "IETF DNSEXT WG" Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Sun, 05 Jul 2009 22:28:22 +0100." <5F9B1E3E96AC4A2AB953FB95C4D354E0@localhost> References: <49238.1246758423@nsa.vix.com><72CE0A0D4D644A599AD7ABB6A169157B@localhost><86172.1246814309@nsa.vix.com><87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <5F9B1E3E96AC4A2AB953FB95C4D354E0@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 05 Jul 2009 21:57:56 +0000 Message-ID: <97056.1246831076@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Sun, 5 Jul 2009 22:28:22 +0100 > > I strongly suspect (without having done any testing) that most/all > resolvers will just accept the child NS records and not refresh from the > parent. yes. that's correct behaviour. but perhaps not optimal in every situation. > I can see there is an argument that this is incorrect though. Delegation > should be bounded in time, so that where a zone is forcibly transferred > from one owner to another, the new owner has an assurance that after the > parent TTL has expired, only the new zone data will be used by resolvers. in my own private (non-BIND) recursive nameserver, i implemented full-chain TTL checking on every cache reference. so if the delegation of VIX.COM from COM had a TTL of 600 seconds, and the delegation of COM from the root zone had a TTL of 700 seconds, but all data in the VIX.COM zone including the apex NS RRset has a TTL of 800 seconds, then i do a partial iteration restart at VIX.COM every 600 seconds, and a partial iteration restart of COM every 700 seconds, in addition to normal response processing for VIX.COM (updating TTL when an unchanged NS RRset arrives from a VIX.COM server, or replacing it if a changed one arrives; discarding expired data; and restarting iteration if the apex NS RRset expires.) if during a partial iteration restart i find that the parent no longer knows about the child, i purge all cached data at or below that delegation point. if during partial iteration restart i find that the parent is still delegating the child to the same servers, i update the "delegation-chain TTL" and continue. if it's to different servers then i update the delegation-chain TTL and also follow it to one of the child zone servers to update the apex NS RRset. if everybody did this, then we could stamp out a fair bit of misconfiguration of zones, and also stop a any eCrime that depends on high cached TTLs lasting longer than a zone's cancellation by a registrar's abuse desk. as you can see it's easier to code it than to write it up as an RFC. -- to unsubscribe send a message to namedroppers-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 Jul 5 16:47:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE893A6B0F; Sun, 5 Jul 2009 16:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMhtXuOU2tJ3; Sun, 5 Jul 2009 16:47:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 275BB3A6BC7; Sun, 5 Jul 2009 16:47:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNbLu-000ARO-UO for namedroppers-data0@psg.com; Sun, 05 Jul 2009 23:42:34 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNbLj-000AQ6-GH for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 23:42:28 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 964A8E6070; Sun, 5 Jul 2009 23:42:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n65NgHtY092827; Mon, 6 Jul 2009 09:42:19 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907052342.n65NgHtY092827@drugs.dv.isc.org> To: Matthew Dempsky Cc: Florian Weimer , IETF DNSEXT WG From: Mark Andrews References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> Subject: Re: [dnsext] Name server agility with DNSSEC In-reply-to: Your message of "Sun, 05 Jul 2009 13:56:07 MST." Date: Mon, 06 Jul 2009 09:42:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The NS RRset is returned with authoritative answers because you have delegations where the set of authoritative servers for the child zone is a super set of the authoritative servers for the parent zone. With such configurations you never learn the NS RRset for the child zone unless you include them in the responses from the common subset of servers. The additional servers for the child zone almost never get queried. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 5 17:00:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4EB3A6AF2; Sun, 5 Jul 2009 17:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9-NuJWUv1oV; Sun, 5 Jul 2009 17:00:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CF9B3A6A34; Sun, 5 Jul 2009 17:00:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNbas-000Bn4-87 for namedroppers-data0@psg.com; Sun, 05 Jul 2009 23:58:02 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNbah-000Bli-6k for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 23:57:56 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id BD8A5E6071; Sun, 5 Jul 2009 23:57:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n65Nve9i092970; Mon, 6 Jul 2009 09:57:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907052357.n65Nve9i092970@drugs.dv.isc.org> To: Florian Weimer Cc: Matthew Dempsky , IETF DNSEXT WG From: Mark Andrews References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> Subject: Re: [dnsext] Name server agility with DNSSEC In-reply-to: Your message of "Sun, 05 Jul 2009 22:43:06 +0200." <87zlbin9np.fsf@mid.deneb.enyo.de> Date: Mon, 06 Jul 2009 09:57:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <87zlbin9np.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Matthew Dempsky: > > > On Sun, Jul 5, 2009 at 12:48 PM, Florian Weimer wrote: > >> Any resolver which does this is buggy in the sense that it requires > >> manual cache flushes from time to time. > > > > Why? If a zone changes name servers, they have to continue > > maintaining the old name servers for a while anyway, which includes > > updating the NS and A/AAAA records that the old name servers publish. > > People don't do that when changing name servers. Servers to which the > zone isn't delegated anymore keep publishing stale data. And if parent zones administrators did the correct thing and not process changes to NS RRsets until both the old and new servers are serving the NS RRset being requested to be added this stupid practice would just ceases to be a issue. You just need to make the old master be a slave of the new master and the zone contents will just transfer to all the other old slaves. This isn't rocket science. This was how zone transfers were done originally. We need to put operational correctness back into DNS operations. The race to be "fastest" has resulted in a badly managed/unmanaged system. There are no checks and balances anymore. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 5 17:02:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83393A6B62; Sun, 5 Jul 2009 17:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-XMV+rWUIjL; Sun, 5 Jul 2009 17:02:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C75583A6B52; Sun, 5 Jul 2009 17:02:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNbYf-000BXf-Er for namedroppers-data0@psg.com; Sun, 05 Jul 2009 23:55:45 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNbYU-000BUK-MM for namedroppers@ops.ietf.org; Sun, 05 Jul 2009 23:55:40 +0000 Received: by gxk1 with SMTP id 1so5921669gxk.17 for ; Sun, 05 Jul 2009 16:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.100.20 with SMTP id x20mr3618694agb.55.1246838133399; Sun, 05 Jul 2009 16:55:33 -0700 (PDT) In-Reply-To: <200907052342.n65NgHtY092827@drugs.dv.isc.org> References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> Date: Sun, 5 Jul 2009 16:55:33 -0700 Message-ID: Subject: Re: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: Mark Andrews Cc: Florian Weimer , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 5, 2009 at 4:42 PM, Mark Andrews wrote: > =A0 =A0 =A0 =A0The NS RRset is returned with authoritative answers becaus= e > =A0 =A0 =A0 =A0you have delegations where the set of authoritative server= s > =A0 =A0 =A0 =A0for the child zone is a super set of the authoritative > =A0 =A0 =A0 =A0servers for the parent zone. Does this happen in practice? It doesn't seem like a very interesting use case to me, but maybe I'm not thinking creatively enough. -- to unsubscribe send a message to namedroppers-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 Jul 5 17:55:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318493A6996; Sun, 5 Jul 2009 17:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKFSAD-GzNI7; Sun, 5 Jul 2009 17:55:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57CAC3A681F; Sun, 5 Jul 2009 17:55:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNcPF-000G6E-2y for namedroppers-data0@psg.com; Mon, 06 Jul 2009 00:50:05 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNcP4-000G55-7u for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 00:49:59 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C1341A7887; Mon, 6 Jul 2009 00:49:53 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: Mark Andrews , Florian Weimer , IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Sun, 05 Jul 2009 16:55:33 MST." References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 06 Jul 2009 00:49:53 +0000 Message-ID: <3904.1246841393@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Sun, 5 Jul 2009 16:55:33 -0700 > From: Matthew Dempsky > > > The NS RRset is returned with authoritative answers because you have > > delegations where the set of authoritative servers for the child zone > > is a super set of the authoritative servers for the parent zone. > > Does this happen in practice? It doesn't seem like a very interesting > use case to me, but maybe I'm not thinking creatively enough. yes, it used to be fairly common, and still is, on non-vanity zones. -- to unsubscribe send a message to namedroppers-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 Jul 5 18:20:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6835C3A6B59; Sun, 5 Jul 2009 18:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LgOKEEoqUT4; Sun, 5 Jul 2009 18:20:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D4B03A681F; Sun, 5 Jul 2009 18:20:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNcpp-000IJS-L3 for namedroppers-data0@psg.com; Mon, 06 Jul 2009 01:17:33 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNcpd-000IHt-O5 for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 01:17:27 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C646CE601C; Mon, 6 Jul 2009 01:17:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n661HHmC094090; Mon, 6 Jul 2009 11:17:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907060117.n661HHmC094090@drugs.dv.isc.org> To: Florian Weimer Cc: Steve Crocker , DNSEXT WG From: Mark Andrews References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-reply-to: Your message of "Sun, 05 Jul 2009 20:18:33 +0200." <87prcfq9hi.fsf@mid.deneb.enyo.de> Date: Mon, 06 Jul 2009 11:17:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <87prcfq9hi.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Steve Crocker: > > > Scott Rose and I wrote a proposal for an extension to the DNS query to > > indicate which algorithms the querier understands. This is intended > > to facilitate transition to new algorithms by providing information as > > to how fully a new algorithm is understood. > > The proposed protocol uses EDNS0 option codes, so it requires the > revised version of RFC 2671 (and will not work that with some BIND > versions still under vendor support, IIRC). > > > The end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to > > indicate that it wishes to receive DNSSEC RRs in the response. > > There is subsequent language in the draft which deals with the DO=0 > case, which appears to be unnecessary. > > > Caches MUST NOT set the AU option on any outgoing query from the > > cache when performing recursion on behalf of a stub client. > > Why? And how does the cache tell a stub client from a non-stub > client? Caches don't use this option. The only clients that use this option are stub clients. Anything else is asking for future problems. > I think for a long time to come, most DO=1 queries will come from > non-stubs, so the proposed protocol should apply there as well. Cache's cascade. It is impossible to differentiate between a stub and a cascading cache. > > 5.1. Intermediate Proxy Resolvers > > What's this? > > I think the whole thing makes sense if it can be applied to most > non-recursive DNS queries. It might also give DNSSEC signature > algorithm agility in practice, and not on paper. > > On the other hand, the DO story suggests to me that chances of > widespread implementations are pretty dim. 8-( > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 5 18:40:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D1B3A681F; Sun, 5 Jul 2009 18:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uolLlMLpurQx; Sun, 5 Jul 2009 18:40:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2AEFD3A67D4; Sun, 5 Jul 2009 18:40:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNd7w-000JhN-Kc for namedroppers-data0@psg.com; Mon, 06 Jul 2009 01:36:16 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNd7l-000JgO-6s for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 01:36:10 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 22E37E6070; Mon, 6 Jul 2009 01:36:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n661Zxle094349; Mon, 6 Jul 2009 11:36:01 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907060136.n661Zxle094349@drugs.dv.isc.org> To: "George Barwood" Cc: "DNSEXT WG" From: Mark Andrews References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <5BA727DA635F4EC98B5E8BD717243C40@localhost> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-reply-to: Your message of "Sat, 04 Jul 2009 05:07:16 +0100." <5BA727DA635F4EC98B5E8BD717243C40@localhost> Date: Mon, 06 Jul 2009 11:35:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <5BA727DA635F4EC98B5E8BD717243C40@localhost>, "George Barwood" writ es: > Would it not be better to fix the shortcomings of DNS transport over UDP > once and for all, rather than complicating higher levels of the protocol. > > That's the intention of the "EDNS Page Option to handle large responses" > I proposed at > > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html We looked at sending multiple DNS messages 11 years ago. We discarded it then and nothing has really changed since to make it a good idea. You need to send too many "DNS fragments" compared with "IP fragments". Firewalls/proxies/NAT that cause operational problems will get fixed/replaced by ones which don't. In the mean time most of those boxes still let through the vast majority of current responses. The best thing to do is to identify the boxes which cause problems and publish them so they can be avoided or upgraded if possible. We should also go to the vendors of said boxes and complain that there design decision are interfering with legitimate traffic. Mark > Is tackling the problem on a piece-meal basis a good way forward? > > George > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 5 23:53:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B578C3A6C67; Sun, 5 Jul 2009 23:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.319 X-Spam-Level: X-Spam-Status: No, score=0.319 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_73=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UNUk7gjCCJs; Sun, 5 Jul 2009 23:53:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF90B28C17F; Sun, 5 Jul 2009 23:53:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNi1z-000O8P-PP for namedroppers-data0@psg.com; Mon, 06 Jul 2009 06:50:27 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNi1o-000O76-KK for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 06:50:21 +0000 Received: by gxk1 with SMTP id 1so6184751gxk.17 for ; Sun, 05 Jul 2009 23:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.66.10 with SMTP id o10mr3892418aga.8.1246863013106; Sun, 05 Jul 2009 23:50:13 -0700 (PDT) In-Reply-To: <7AA80B7277CF49D6AA8E4513F093C608@localhost> References: <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <7AA80B7277CF49D6AA8E4513F093C608@localhost> Date: Sun, 5 Jul 2009 23:50:12 -0700 Message-ID: Subject: Re: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: George Barwood Cc: Mark Andrews , Florian Weimer , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 5, 2009 at 11:37 PM, George Barwood wrote: > Do we know why anyone would not list all the name servers at the parent? Mark's talking about configurations like: example.dom. NS ns1.example.dom. example.dom. NS ns2.example.dom. sub.example.dom. NS ns1.example.dom. sub.example.dom. NS ns2.example.dom. sub.example.dom. NS ns.sub.example.dom. If a cache wants to resolve www.sub.example.dom, it'll first learn the delegation for example.dom, but then either ns[12].example.dom will answer authoritatively for the sub.example.dom zone. Without the NS records, it would never learn it can also query ns.sub.example.dom. -- to unsubscribe send a message to namedroppers-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 Jul 6 00:04:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0DB3A6897; Mon, 6 Jul 2009 00:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pt2XzooYak7; Mon, 6 Jul 2009 00:04:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E95E03A6880; Mon, 6 Jul 2009 00:04:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNiCU-000PE9-LG for namedroppers-data0@psg.com; Mon, 06 Jul 2009 07:01:18 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNiCJ-000PD9-8O for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 07:01:12 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 2A9DAE601C; Mon, 6 Jul 2009 07:01:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n66713oX097583; Mon, 6 Jul 2009 17:01:03 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907060701.n66713oX097583@drugs.dv.isc.org> To: "George Barwood" Cc: "Matthew Dempsky" , "Mark Andrews" , "Florian Weimer" , "IETF DNSEXT WG" From: Mark Andrews References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <7AA80B7277CF49D6AA8E4513F093C608@localhost> Subject: Re: [dnsext] Name server agility with DNSSEC In-reply-to: Your message of "Mon, 06 Jul 2009 07:37:15 +0100." <7AA80B7277CF49D6AA8E4513F093C608@localhost> Date: Mon, 06 Jul 2009 17:01:03 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <7AA80B7277CF49D6AA8E4513F093C608@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Mark Andrews" > > > The NS RRset is returned with authoritative answers because > > you have delegations where the set of authoritative servers > > for the child zone is a super set of the authoritative > > servers for the parent zone. > > Ah, ok. > > RFC 1034 4.2.1 does say > > "Since the cuts are between nodes, these RRs are NOT part of the > authoritative data of the zone, and should be exactly the same as the > corresponding RRs in the top node of the subzone." > > Do we know why anyone would not list all the name servers at the parent? This has nothing to do with problem > I suppose the parent or registrar may impose limits, but going against > the standard seems a doubtful way to proceed ( instead unreasonable > limits should be increased ). > > I suggest that BIND might at least provide a configuration option > that disables the sending of unsolicited child NS records > ( maybe it already does... I'm not very familiar with BIND ). George please re-read the description of the problem. Say you have example.com and child.example.com delegated to these servers. example.com NS ns1.example.com example.com NS ns2.example.com child.example.com NS ns1.example.com child.example.com NS ns2.example.com child.example.com NS ns1.child.example.com child.example.com NS ns2.child.example.com You then ask for MX child.example.com, then AAAA child.example.com and then A child.example.com. If you don't return the NS RRset then: Which nameservers will be used for the MX query. Which nameservers will be used for the AAAA query. Which nameservers will be used for the A query. If you do return the NS RRset then: Which nameservers will be used for the MX query. Which nameservers will be used for the AAAA query. Which nameservers will be used for the A query. Such configuration are reasonably common. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 00:36:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B532D28C1B8; Mon, 6 Jul 2009 00:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.735 X-Spam-Level: **** X-Spam-Status: No, score=4.735 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4IlLjpJXXJL; Mon, 6 Jul 2009 00:36:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3DFA28C1A4; Mon, 6 Jul 2009 00:36:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNihO-0002Li-6k for namedroppers-data0@psg.com; Mon, 06 Jul 2009 07:33:14 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNihC-0002KI-3F for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 07:33:08 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MNih1-0006mO-Ik; Mon, 06 Jul 2009 08:32:52 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MNih0-0003t9-Uk; Mon, 06 Jul 2009 08:32:50 +0100 Message-ID: <4E6DB3D50C5E40DFBDDA4C5C764A1893@localhost> From: "George Barwood" To: "Mark Andrews" Cc: "Matthew Dempsky" , "Mark Andrews" , "Florian Weimer" , "IETF DNSEXT WG" References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <7AA80B7277CF49D6AA8E4513F093C608@localhost> <200907060701.n66713oX097583@drugs.dv.isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Mon, 6 Jul 2009 08:32:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQoNCj4gU2F5IHlvdSBoYXZlIGV4YW1wbGUuY29tIGFuZCBjaGlsZC5leGFt cGxlLmNvbSBkZWxlZ2F0ZWQNCj4gdG8gdGhlc2Ugc2VydmVycy4NCj4gDQo+IGV4YW1wbGUuY29t IE5TIG5zMS5leGFtcGxlLmNvbSANCj4gZXhhbXBsZS5jb20gTlMgbnMyLmV4YW1wbGUuY29tIA0K PiANCj4gY2hpbGQuZXhhbXBsZS5jb20gTlMgbnMxLmV4YW1wbGUuY29tIA0KPiBjaGlsZC5leGFt cGxlLmNvbSBOUyBuczIuZXhhbXBsZS5jb20gDQo+IGNoaWxkLmV4YW1wbGUuY29tIE5TIG5zMS5j aGlsZC5leGFtcGxlLmNvbSANCj4gY2hpbGQuZXhhbXBsZS5jb20gTlMgbnMyLmNoaWxkLmV4YW1w bGUuY29tIA0KDQpPaywgSSBjb25zaWRlciB0aGlzIHRvIGJlIGEgbWlzLWNvbmZpZ3VyYXRpb24s IHNpbmNlIGl0J3MgYSAicGFydGlhbCIgZGVsZWdhdGlvbi4NCg0KU29tZW9uZSBtb3ZpbmcgdGhp cyB6b25lIHRvIGFub3RoZXIgbmFtZSBzZXJ2ZXIgdmVuZG9yIHdpbGwgZmluZCBhIGNoYW5nZQ0K aW4gYmVoYXZpb3IuDQoNCk1heWJlIEJJTkQgY291bGQgc2VuZCB0aGUgTlMgUlJzZXQgb25seSBp biB0aGVzZSBjYXNlcz8NCg0KSSBzdWdnZXN0IGRlY2xhcmluZyBzdWNoIGNvbmZpZ3VyYXRpb25z IGluY29ycmVjdCAob3IgYXQgbGVhc3QgaW5hZHZpc2FibGUpLCANCndoaWxlIG1haW50YWluaW5n IHN1cHBvcnQgZm9yIHRoZW0gaW4gQklORCwgYW5kIGFkdmlzaW5nIEJJTkQgY3VzdG9tZXJzIA0K dGhhdCB3aXRoIEROU1NFQyBsYXJnZSByZXNwb25zZXMgc3ViamVjdCB0byB0cnVuY2F0aW9uIGNh biBvY2N1ciBmb3Igc3VjaCANCmNvbmZpZ3VyYXRpb25zLg0K -- to unsubscribe send a message to namedroppers-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 Jul 6 01:39:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1547928C188; Mon, 6 Jul 2009 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+byLc6hDs8v; Mon, 6 Jul 2009 01:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB7263A6C3C; Mon, 6 Jul 2009 01:39:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNjec-0008vC-1r for namedroppers-data0@psg.com; Mon, 06 Jul 2009 08:34:26 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNjeQ-0008u9-5e for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 08:34:20 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n668Xmj8025897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 10:33:51 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A51B6EC.9090706@nlnetlabs.nl> Date: Mon, 06 Jul 2009 10:33:48 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Mark Andrews CC: Steve Crocker , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> In-Reply-To: <200907060117.n661HHmC094090@drugs.dv.isc.org> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 06 Jul 2009 10:33:51 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/06/2009 03:17 AM, Mark Andrews wrote: >>> Caches MUST NOT set the AU option on any outgoing query from the >>> cache when performing recursion on behalf of a stub client. >> Why? And how does the cache tell a stub client from a non-stub >> client? > Caches don't use this option. The only clients that use > this option are stub clients. Anything else is asking for > future problems. +1. The algo-signal option is then useful for stub clients. >> I think for a long time to come, most DO=1 queries will come from >> non-stubs, so the proposed protocol should apply there as well. > > Cache's cascade. It is impossible to differentiate between > a stub and a cascading cache. +1. So, using the signaling option would then be some sort of option for caching resolvers. An option that would be turned off by default, since even on localhost there might be further querying validators (even if they are not full resolvers, they may want to perform their own validation). This would limit deployment. Summarizing: I think supporting algorithm rollover is a good thing. But the draft does not help caches. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpRtuwACgkQkDLqNwOhpPi4vACgivHXK6gaZD/GB4GzzkipuAcK hIgAmgN957Kbp0qHcTKubuDPiXKk+VvM =xH6w -----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 Jul 6 02:56:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AA73A6CE8; Mon, 6 Jul 2009 02:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.121 X-Spam-Level: X-Spam-Status: No, score=-106.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZWjamyM0xq; Mon, 6 Jul 2009 02:56:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E0DA3A6CD8; Mon, 6 Jul 2009 02:56:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNkrE-000GOM-V7 for namedroppers-data0@psg.com; Mon, 06 Jul 2009 09:51:32 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNkr3-000GMQ-UY for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 09:51:27 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 1F3061C00F2; Mon, 6 Jul 2009 11:51:21 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 1A2281C002D; Mon, 6 Jul 2009 11:51:21 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 177837B0039; Mon, 6 Jul 2009 11:51:21 +0200 (CEST) Date: Mon, 6 Jul 2009 11:51:44 +0200 From: Stephane Bortzmeyer To: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt Message-ID: <20090706095144.GB25939@nic.fr> References: <20090706081501.530263A6B0A@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090706081501.530263A6B0A@core3.amsl.com> X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 06, 2009 at 01:15:01AM -0700, Internet-Drafts@ietf.org wrote a message of 53 lines which said: > There are two kinds of TYPE for host IP address: one is A, the other > is AAAA, which records IPv4 and IPv6 addresses respectively. This > document defines a new TYPE, which is mainly used in queries in > order to get both IPv4 and IPv6 addresses. Certainly a good idea and I applaud the effort. But I vaguely remember there was a long time ago a project to have a query type ADDR and that it failed, so you may research history of this project to see what was the problem. There are many more details to address, your document is just a start. For instance, you write "A BOTH query for a specified domain name in the Internet class returns _all_ associated A and AAAA resource records..." but this raises response size issues (see draft-ietf-dnsop-respsize) so you may soften your requirment. -- to unsubscribe send a message to namedroppers-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 Jul 6 03:07:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA8028C107; Mon, 6 Jul 2009 03:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOAUfa91MVro; Mon, 6 Jul 2009 03:07:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C65813A6840; Mon, 6 Jul 2009 03:07:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNl3u-000HcQ-VO for namedroppers-data0@psg.com; Mon, 06 Jul 2009 10:04:38 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNl3j-000Had-3F for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 10:04:33 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6019A1C00E1; Mon, 6 Jul 2009 12:04:26 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5BBB81C002D; Mon, 6 Jul 2009 12:04:26 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 58DDB7B0039; Mon, 6 Jul 2009 12:04:26 +0200 (CEST) Date: Mon, 6 Jul 2009 12:04:49 +0200 From: Stephane Bortzmeyer To: Mark Andrews Cc: Florian Weimer , Matthew Dempsky , IETF DNSEXT WG Subject: [dnsext] Re: Name server agility with DNSSEC Message-ID: <20090706100449.GA27766@nic.fr> References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052357.n65Nve9i092970@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907052357.n65Nve9i092970@drugs.dv.isc.org> X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 06, 2009 at 09:57:40AM +1000, Mark Andrews wrote a message of 39 lines which said: > And if parent zones administrators did the correct thing and not > process changes to NS RRsets until both the old and new servers are > serving the NS RRset being requested to be added this stupid > practice would just ceases to be a issue. We (the .FR managers) are often regarded as specially anal-retentive because a successful technical check is required before any change (not only the creation, any technical change) in the delegation. Nevertheless, we do not perform this test, so I doubt anyone actually does it. > You just need to make the old master be a slave of the new master > and the zone contents will just transfer to all the other old > slaves. This isn't rocket science. But the problem is not entirely technical. It is partly a question of scale (imagine running a DNS hoster with 100,000 zones, all from your database, how many changes of your ACL - for ingoing transfers - and of your authoritative configuration - for outgoing transfers?). But it is mostly a matter of business. If you mandate such a rule, any DNS hoster will be able to delay the departure of a customer at will. A transfer from one hoster to another MUST NOT depend on the good will of the "loser". (We will have simlilar problems with DNSSEC, with DNS hosters refusing to give the private key to a leaving customer.) -- to unsubscribe send a message to namedroppers-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 Jul 6 03:48:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED173A6A1A; Mon, 6 Jul 2009 03:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.362 X-Spam-Level: * X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, MIME_ASCII0=1.5, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcqCZJ-uu0GB; Mon, 6 Jul 2009 03:48:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A76963A6A6B; Mon, 6 Jul 2009 03:48:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNlgs-000LaX-E1 for namedroppers-data0@psg.com; Mon, 06 Jul 2009 10:44:54 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNlgg-000LZB-6g for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 10:44:48 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n66Aidnu027846 for ; Mon, 6 Jul 2009 12:44:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] Name server agility with DNSSEC Date: Mon, 6 Jul 2009 12:46:44 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949F02AFD@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Name server agility with DNSSEC Thread-Index: Acn9zvMcuqKe9Ee1Rz6XQQ1xsafRiQAVLsWQ References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052357.n65Nve9i092970@drugs.dv.isc.org> From: "Antoin Verschuren" To: "IETF DNSEXT WG" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItbmFtZWRyb3BwZXJzQG9wcy5p ZXRmLm9yZyBbbWFpbHRvOm93bmVyLQ0KPiBuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWFyayBBbmRyZXdzDQo+IFN1YmplY3Q6IFJlOiBbZG5zZXh0XSBOYW1lIHNlcnZl ciBhZ2lsaXR5IHdpdGggRE5TU0VDDQo+IA0KPiBBbmQgaWYgcGFyZW50IHpvbmVzIGFkbWluaXN0 cmF0b3JzIGRpZCB0aGUgY29ycmVjdCB0aGluZyBhbmQgbm90DQo+IHByb2Nlc3MgY2hhbmdlcyB0 byBOUyBSUnNldHMgdW50aWwgYm90aCB0aGUgb2xkIGFuZCBuZXcgc2VydmVycyBhcmUNCj4gc2Vy dmluZyB0aGUgTlMgUlJzZXQgYmVpbmcgcmVxdWVzdGVkIHRvIGJlIGFkZGVkIHRoaXMgc3R1cGlk IHByYWN0aWNlDQo+IHdvdWxkIGp1c3QgY2Vhc2VzIHRvIGJlIGEgaXNzdWUuDQoNClRoaXMgd291 bGQgd29yayB3ZWxsIGlmIGFsbCBkcml2ZXJzIHdvdWxkIGJlIGNhci1tZWNoYW5pY3MgYXMgd2Vs bC4NCkJ1dCBsZXQncyBmYWNlIGl0LCBub3QgYWxsIGRucy1vcGVyYXRvcnMgYXJlIGRucyBleHBl cnRzIGFueW1vcmUuDQpJZiB0aGlzIGlzbid0IGF1dG9tYXRlZCBpbiBkZXBsb3llZCBzb2Z0d2Fy ZSwgd2l0aCBhIHNpbXBsZSBlbm91Z2ggYnV0dG9uIGZvciB0aGUgb3BlcmF0b3IgdG8gcHVzaCBv biwgaGUncyBub3QgY2FwYWJsZSBvZiBkb2luZyB0aGlzLg0KTW90aGVyLWluLWxhd3MgaGF2ZSBi ZWNvbWUgZG9tYWluIG93bmVycy4NCldlIG5lZWQgdG8gZ2l2ZSB0aGVtIHRoZSB0b29scyB0byBv cGVyYXRlIHRoZWlyIHpvbmVzIHNhZmVseS4NCg0KV2Ugc3RpbGwgaGF2ZSB0aGUgcnVsZSBpbiBv dXIgcG9saWN5IHRoYXQgbG9zaW5nIEROUy1vcGVyYXRvcnMgc2hvdWxkIHJ1biBzZWNvbmRhcnkg Zm9yIGEgd2hpbGUgYWZ0ZXIgYSB0cmFuc2Zlci4gQnV0IGluIHByYWN0aWNlLCBzaW5jZSAic2Vj dXJpdHkgcnVsZXMiIGRvbid0IGFsbG93IEFYRlIgdHJhbnNmZXJzIGFueW1vcmUsIG5vYm9keSBp cyBhYmxlIHRvIGNvbmZvcm0gdG8gdGhlc2UgYmVzdCBwcmFjdGljZXMgYW55bW9yZS4gSXQncyBz aW1wbHkgbm90IHNjYWxhYmxlIGFueW1vcmUgdG8gaGF2ZSBhIG1hbnkgdG8gbWFueSByZWxhdGlv bnNoaXAgYmV0d2VlbiBETlMtb3BlcmF0b3JzIHRvIGFsbG93IGZvciBhIHNtb290aCB0cmFuc2l0 aW9uLg0KDQpBbmQgYXMgSSd2ZSBkZW1vbnN0cmF0ZWQsIHdpdGggRE5TU0VDLCB3ZSBvbmx5IGhh dmUgYSBjaG9pY2UgYmV0d2VlbiBjaGFuZ2luZyByZXNvbHZlciBiZWhhdmlvciwgb3IgY2xlYXJs eSBkb2N1bWVudCBhbmQgZGVwbG95IGEgY29tcGxleCB0cmFuc2l0aW9uIHByb2Nlc3MgdGhhdCBj b25mbGljdHMgd2l0aCBidXNpbmVzcyBpbnRlcmVzdHMuIEkgZG8gaGF2ZSBzb21lIGZhaXRoIGlu IGRvY3VtZW50aW5nLCBidXQgZ2V0dGluZyB0aGlzIGRlcGxveWVkIGluIGFsbCB0aGUgY29tbWVy Y2lhbGx5IGRyaXZlbiBub24tdGVjaG5pY2FsIGRvbWFpbiBwb3J0Zm9saW8gbWFuYWdlbWVudCBw YWNrYWdlcyBpcyBhIGJhdHRsZSBJJ20gYWZyYWlkIHdlJ3JlIGdvaW5nIHRvIGxvc2UuDQpNYW5k YXRpbmcgdGhpcyBpbiBwb2xpY3kgYnkgYSBwYXJlbnQgd2l0aG91dCB0aGUgcHJvcGVyIHRvb2xz IG9yIGV4cGVydGlzZSBpbiB0aGUgY3VycmVudCBkZXBsb3llZCBiYXNlIG9mIGRucy1vcGVyYXRv cnMgd291bGQgbWVhbiBzdWljaWRlIGZvciBhIHJlZ2lzdHJ5LCBzbyB0aGV5IGNob3NlIG5vdCB0 byBkbyB0aGlzLg0KDQpTbyBpbnN0ZWFkIG9mIHN0aWNraW5nIG91ciBoZWFkcyBpbnRvIHRoZSBz YW5kLCBsZXQncyBjb21lIHVwIHdpdGggYSBzb2x1dGlvbiB0aGF0IGRvZXMgd29yayBpbiB0aGUg cmVhbCB3b3JsZC4NCg0KQW50b2luIFZlcnNjaHVyZW4NCg0KVGVjaG5pY2FsIFBvbGljeSBBZHZp c29yIFNJRE4NClV0cmVjaHRzZXdlZyAzMTAsIFBPIEJveCA1MDIyLCA2ODAyIEVBIEFybmhlbSwg VGhlIE5ldGhlcmxhbmRzDQoNClA6ICszMSAyNiAzNTI1NTAwICBGOiArMzEgMjYgMzUyNTUwNSAg TTogKzMxIDYgMjMzNjg5NzANCm1haWx0bzphbnRvaW4udmVyc2NodXJlbkBzaWRuLm5sICB4bXBw OmFudG9pbkBqYWJiZXIuc2lkbi5ubCAgaHR0cDovL3d3dy5zaWRuLm5sLw0KLS0tLS1CRUdJTiBQ R1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IDkuNi4zIChCdWlsZCAzMDE3KQ0KDQp3c0JWQXdV QlNsSFdGRHFIck04ODNBZ25BUWdvdlFnQTNsQ3oyaU9scmlqc052dEp1UnloNnZPY29Xa0JCRmZy DQphVEdyZWcwZUJsNkp2WVVmQm8zR1FTMHZzTVdkbGIvODF2ZXg5K2xqU3QxRGlxejJwRXp0N3Z3 czRyT2FZL2w0DQpzc3dET3d5cXBUZjV6OWFYV2FzdmZoRWJQWko2dkJqaWVtZXdMUEFRZEwwTE1V bnFET0NqemV6ck9VdmRtTTBQDQoyVGRlUytkSFYrd21RWm4zei8zR1hzWjRrY0tHWGpmTUk1S3Nm UlNWK3RGcnNWMVVlUzVEZksraDNDcDU1UmlKDQpTcSt4UXZlRElrTDlKUnJodzBxUHBva3NRZCtj SndaQlZnVDVKdXhabEZXSUZuNEtQY25NakZoNXpSOUdka2JkDQpFUUREMWt2Vll1MTNhT0piUzlM TFRReFJnUndrZUUvS2VhSktKTkNjSFR6ZGdQc1N1UmhsTVE9PQ0KPXRNcEUNCi0tLS0tRU5EIFBH UCBTSUdOQVRVUkUtLS0tLQ0KDQo= -- to unsubscribe send a message to namedroppers-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 Jul 6 05:34:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD143A69F1; Mon, 6 Jul 2009 05:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3+bjGp465Ry; Mon, 6 Jul 2009 05:34:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D03D93A6B95; Mon, 6 Jul 2009 05:34:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNnK4-0004Ql-HS for namedroppers-data0@psg.com; Mon, 06 Jul 2009 12:29:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNnJs-0004Pg-PT for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 12:29:22 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 73CEFE606E; Mon, 6 Jul 2009 12:29:14 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt From: Shane Kerr To: Stephane Bortzmeyer Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org In-Reply-To: <20090706095144.GB25939@nic.fr> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> Content-Type: text/plain Organization: ISC Date: Mon, 06 Jul 2009 14:29:11 +0200 Message-Id: <1246883351.3922.10697.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: All, On Mon, 2009-07-06 at 11:51 +0200, Stephane Bortzmeyer wrote: > On Mon, Jul 06, 2009 at 01:15:01AM -0700, > Internet-Drafts@ietf.org wrote > a message of 53 lines which said: > > > There are two kinds of TYPE for host IP address: one is A, the other > > is AAAA, which records IPv4 and IPv6 addresses respectively. This > > document defines a new TYPE, which is mainly used in queries in > > order to get both IPv4 and IPv6 addresses. > > Certainly a good idea and I applaud the effort. But I vaguely remember > there was a long time ago a project to have a query type ADDR and that > it failed, so you may research history of this project to see what was > the problem. > > There are many more details to address, your document is just a > start. For instance, you write "A BOTH query for a specified domain > name in the Internet class returns _all_ associated A and AAAA > resource records..." but this raises response size issues (see > draft-ietf-dnsop-respsize) so you may soften your requirment. The main problem I see with this approach is that this will turn the two queries that most applications do into three queries. If you sent a query for the BOTH type to any server on the Internet today, it would fail. Then the client would go back to doing things the way it works today (separate AAAA and A queries). This means 50% more load for years and years to come, not 50% less load as we actually want. I do agree that something like this would be very helpful. Apparently multiple queries in a single packet are not allowed (not sure what the reasons are, as 9 years ago I was not on namedroppers). Perhaps an EDNS0 flag or some other special-case hackery is the best way forward? -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 05:41:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24DCE3A6C09; Mon, 6 Jul 2009 05:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 755ZUXq1xoaW; Mon, 6 Jul 2009 05:41:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C49D73A6909; Mon, 6 Jul 2009 05:41:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNnSB-00055O-Oz for namedroppers-data0@psg.com; Mon, 06 Jul 2009 12:37:51 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNnRz-00054W-6K for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 12:37:46 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7D94A1C00F2; Mon, 6 Jul 2009 14:37:38 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 78B3F1C007E; Mon, 6 Jul 2009 14:37:38 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 6C52FA1D961; Mon, 6 Jul 2009 14:37:38 +0200 (CEST) Date: Mon, 6 Jul 2009 14:38:02 +0200 From: Stephane Bortzmeyer To: Shane Kerr Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt Message-ID: <20090706123802.GA16577@nic.fr> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <1246883351.3922.10697.camel@shane-asus-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1246883351.3922.10697.camel@shane-asus-laptop> X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 06, 2009 at 02:29:11PM +0200, Shane Kerr wrote a message of 37 lines which said: > Apparently multiple queries in a single packet are not allowed (not > sure what the reasons are, as 9 years ago I was not on > namedroppers). My guess: because fields like Answer Count or Response Code are global, not per-query. So, what to do if one query succeeds and the other nxdomains? -- to unsubscribe send a message to namedroppers-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 Jul 6 06:31:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB8328C28F; Mon, 6 Jul 2009 06:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPGIXoT5CFWF; Mon, 6 Jul 2009 06:31:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F094A28C2CF; Mon, 6 Jul 2009 06:31:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNoE6-0009bP-EF for namedroppers-data0@psg.com; Mon, 06 Jul 2009 13:27:22 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNoDv-0009aW-6V for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 13:27:16 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id CC65BE606E; Mon, 6 Jul 2009 13:27:08 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt From: Shane Kerr To: Stephane Bortzmeyer Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org In-Reply-To: <20090706123802.GA16577@nic.fr> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <1246883351.3922.10697.camel@shane-asus-laptop> <20090706123802.GA16577@nic.fr> Content-Type: text/plain Organization: ISC Date: Mon, 06 Jul 2009 15:27:06 +0200 Message-Id: <1246886826.3922.10881.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stephane, On Mon, 2009-07-06 at 14:38 +0200, Stephane Bortzmeyer wrote: > On Mon, Jul 06, 2009 at 02:29:11PM +0200, > Shane Kerr wrote > a message of 37 lines which said: > > > Apparently multiple queries in a single packet are not allowed (not > > sure what the reasons are, as 9 years ago I was not on > > namedroppers). > > My guess: because fields like Answer Count or Response Code are > global, not per-query. So, what to do if one query succeeds and the > other nxdomains? If that is the concern then we have no worries, because we can restrict the query to a single ownername, right? At least, we only care about A and AAAA records for a single ownername in a single query (*). But we still have the same problem of lack of support causing extra queries. I wonder what different servers do if they see QCOUNT more than 1 today... -- Shane (*) And possibly HIP or other new address styles that show up. -- to unsubscribe send a message to namedroppers-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 Jul 6 08:22:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23EB3A6CF8; Mon, 6 Jul 2009 08:22:04 -0700 (PDT) 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 b0ZXUGUD-Oil; Mon, 6 Jul 2009 08:22:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C88C3A6C96; Mon, 6 Jul 2009 08:22:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNpvl-000Jz1-0E for namedroppers-data0@psg.com; Mon, 06 Jul 2009 15:16:33 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNpvX-000JxB-Ib for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 15:16:26 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3C13CA833D for ; Mon, 6 Jul 2009 15:16:18 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "IETF DNSEXT WG" Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Mon, 06 Jul 2009 07:37:15 +0100." <7AA80B7277CF49D6AA8E4513F093C608@localhost> References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <7AA80B7277CF49D6AA8E4513F093C608@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 06 Jul 2009 15:16:18 +0000 Message-ID: <42303.1246893378@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Mon, 6 Jul 2009 07:37:15 +0100 > > Do we know why anyone would not list all the name servers at the parent? registrars and registries are more painful to deal with, for creating and maintaining nameserver names and then updating parent-zone delegations to use or not use those names, compared to just putting the data into one's own zone file and reloading the primary master server. in other words, human nature is the reason for most deviations between the parent's delegation and the child's apex. and as we have all discovered by now, bugs in human nature can't be patched, they have to be worked around. > I suppose the parent or registrar may impose limits, but going against > the standard seems a doubtful way to proceed ( instead unreasonable > limits should be increased ). the standard says "should" not "must". and i agree with the "should" but since it's not a "must", correct operation must ensue even when the advice isn't followed. > I suggest that BIND might at least provide a configuration option that > disables the sending of unsolicited child NS records ( maybe it already > does... I'm not very familiar with BIND ). as i said earlier in this thread, this isn't BIND-specific. -- to unsubscribe send a message to namedroppers-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 Jul 6 08:26:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94AA23A6B16; Mon, 6 Jul 2009 08:26:11 -0700 (PDT) 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 k4QMGf3MpO5O; Mon, 6 Jul 2009 08:26:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41A2E3A6992; Mon, 6 Jul 2009 08:26:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNq2A-000Kdt-11 for namedroppers-data0@psg.com; Mon, 06 Jul 2009 15:23:10 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNq1y-000KcH-HE for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 15:23:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2365FA833A; Mon, 6 Jul 2009 15:22:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt In-Reply-To: Your message of "Mon, 06 Jul 2009 11:51:44 +0200." <20090706095144.GB25939@nic.fr> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 06 Jul 2009 15:22:58 +0000 Message-ID: <42645.1246893778@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Mon, 6 Jul 2009 11:51:44 +0200 > From: Stephane Bortzmeyer > > On Mon, Jul 06, 2009 at 01:15:01AM -0700, > Internet-Drafts@ietf.org wrote > a message of 53 lines which said: > > > There are two kinds of TYPE for host IP address: one is A, the other > > is AAAA, which records IPv4 and IPv6 addresses respectively. This > > document defines a new TYPE, which is mainly used in queries in > > order to get both IPv4 and IPv6 addresses. > > Certainly a good idea and I applaud the effort. But I vaguely remember > there was a long time ago a project to have a query type ADDR and that > it failed, so you may research history of this project to see what was > the problem. i think the best we can do at this late date is to define additional data rules for queries type A as including AAAA, and rules for queries of type AAAA as including A. so a query for either type would cause responses to include that type in the answer section and include the other type in the additional data section. > There are many more details to address, your document is just a > start. For instance, you write "A BOTH query for a specified domain name > in the Internet class returns _all_ associated A and AAAA resource > records..." but this raises response size issues (see > draft-ietf-dnsop-respsize) so you may soften your requirment. the purpose of such additional data would be to forestall a second query by prepopulating a cache with the the other kind of address record. the normal rules of "if additional data won't fit, don't add it" would apply, so truncation wouldn't be an issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 09:10:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0065428C30F; Mon, 6 Jul 2009 09:10:32 -0700 (PDT) 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 bdUJJ2Rp-rST; Mon, 6 Jul 2009 09:10:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E1C728C290; Mon, 6 Jul 2009 09:10:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNqiS-000P7a-Kl for namedroppers-data0@psg.com; Mon, 06 Jul 2009 16:06:52 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNqiF-000P69-7t for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 16:06:46 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E7D6AA8344 for ; Mon, 6 Jul 2009 16:06:38 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt In-Reply-To: Your message of "Mon, 06 Jul 2009 15:27:06 +0200." <1246886826.3922.10881.camel@shane-asus-laptop> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <1246883351.3922.10697.camel@shane-asus-laptop> <20090706123802.GA16577@nic.fr> <1246886826.3922.10881.camel@shane-asus-laptop> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 06 Jul 2009 16:06:38 +0000 Message-ID: <44469.1246896398@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Shane Kerr > Date: Mon, 06 Jul 2009 15:27:06 +0200 > > On Mon, 2009-07-06 at 14:38 +0200, Stephane Bortzmeyer wrote: > > On Mon, Jul 06, 2009 at 02:29:11PM +0200, > > > > My guess: because fields like Answer Count or Response Code are > > global, not per-query. So, what to do if one query succeeds and the > > other nxdomains? > > If that is the concern then we have no worries, because we can restrict > the query to a single ownername, right? At least, we only care about A > and AAAA records for a single ownername in a single query (*). > > But we still have the same problem of lack of support causing extra > queries. I wonder what different servers do if they see QCOUNT more than > 1 today... a long, long time ago in a code base far away (BIND 4.9), i had to decide this issue. if all QNAMEs were identical, then the RCODE and the AA flag would be unambiguous. i actually considered responding with FORMERR if QDCOUNT>1 and not all QNAMEs matched, but i had not yet been to an IETF meeting nor written an RFC and i felt that conservatism would be better. it's too late now, unless we wanted to link this behaviour to an EDNS version number change, or unless we wanted to try QDCOUNT>1 first and then fall back to multiple queries under the no-doubt-bizarre set of ways that remote servers and their middleboxes and our middleboxes can muddy things. -- to unsubscribe send a message to namedroppers-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 Jul 6 11:06:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D3E3A6D35; Mon, 6 Jul 2009 11:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6bvctdZy-Kv; Mon, 6 Jul 2009 11:06:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D91F3A69D5; Mon, 6 Jul 2009 11:06:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNsRu-0008rU-IJ for namedroppers-data0@psg.com; Mon, 06 Jul 2009 17:57:54 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNsRj-0008qw-G2 for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 17:57:48 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 1D2A828C3D2; Mon, 6 Jul 2009 10:57:15 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair Subject: [dnsext] Protocol Action: 'DNS Proxy Implementation Guidelines' to BCP Message-Id: <20090706175716.1D2A828C3D2@core3.amsl.com> Date: Mon, 6 Jul 2009 10:57:16 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'DNS Proxy Implementation Guidelines ' as a BCP This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-06.txt Technical Summary This document is aimed at a target audience that is outside the IETF but implement DNS protocol elements, frequently without much understanding of the DNS protocol. This document gives simple guidance to such people to avoid common mistakes, seen in the field, that cause major interoperabilty issues. Working Group Summary The consensus for this document is real strong. Document Quality This is a high quality draft, that is addressing an important aspect for the interoperabilty of the DNS protocol. Number of vendors that purchase/test DNS gateways have stated that compliance with this document is going to be a purchasing requirement. Personnel Document Shepherd is: Olafur Gudmundsson AD: Ralph Droms -- to unsubscribe send a message to namedroppers-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 Jul 6 11:19:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E103A6D5A; Mon, 6 Jul 2009 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKz3gnMt3wVA; Mon, 6 Jul 2009 11:19:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6A5F3A67DF; Mon, 6 Jul 2009 11:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNsii-000AKG-At for namedroppers-data0@psg.com; Mon, 06 Jul 2009 18:15:16 +0000 Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNsiW-000AIv-3J for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 18:15:10 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1MNsiU-0004tt-J6 for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 18:15:02 +0000 Received: from nobelnet.dk ([130.225.243.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jul 2009 18:15:02 +0000 Received: from chaz by nobelnet.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jul 2009 18:15:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Chris Hills Subject: Re: [dnsext] Name server agility with DNSSEC Date: Mon, 06 Jul 2009 20:11:49 +0200 Lines: 24 Message-ID: References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: nobelnet.dk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1pre) Gecko/20090705 Shredder/3.0b3pre In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 06/07/09 01:55, Matthew Dempsky wrote: > On Sun, Jul 5, 2009 at 4:42 PM, Mark Andrews wrote: >> The NS RRset is returned with authoritative answers because >> you have delegations where the set of authoritative servers >> for the child zone is a super set of the authoritative >> servers for the parent zone. > > Does this happen in practice? It doesn't seem like a very interesting > use case to me, but maybe I'm not thinking creatively enough. To give an example. There may be an operational limit on the number of glue records that may be added to the parent zone, however the end-user has more servers available, with a diverse range of addresses. A recursor may find one of the addresses to be more preferable than the others. For a couple of my zones there are glue records for only three (using three different TLDs), wheras the zone is available on 9 servers in total. Example in point: 2.2.d.d.8.d.6.1.1.0.0.2.ip6.arpa. (Pretend for now that it is reachable using an ipv6-only resolver. In practice, at least ipv4 connectivity is required.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 12:07:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2C428C40F; Mon, 6 Jul 2009 12:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.113, 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 JwST3IeBsrwD; Mon, 6 Jul 2009 12:07:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB24828C43A; Mon, 6 Jul 2009 12:07:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNtPG-000Dr7-Sx for namedroppers-data0@psg.com; Mon, 06 Jul 2009 18:59:14 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNtP5-000DqK-H7 for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 18:59:09 +0000 Received: from [10.31.200.146] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n66Iwe4X031284; Mon, 6 Jul 2009 14:58:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> Date: Mon, 6 Jul 2009 14:56:35 -0400 To: Matthew Dempsky From: Edward Lewis Subject: Re: [dnsext] Name server agility with DNSSEC Cc: Mark Andrews , Florian Weimer , IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 16:55 -0700 7/5/09, Matthew Dempsky wrote: >On Sun, Jul 5, 2009 at 4:42 PM, Mark Andrews wrote: >> The NS RRset is returned with authoritative answers because >> you have delegations where the set of authoritative servers >> for the child zone is a super set of the authoritative >> servers for the parent zone. > >Does this happen in practice? It doesn't seem like a very interesting >use case to me, but maybe I'm not thinking creatively enough. Yes. Add a name server. Watch the traffic rate grow, gain confidence. Tell the parent you added it. Parent adds name server to it's DNS. If this weren't "allowed" you would have to get parent and child to do a simultaneous change. Fat chance of that. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 12:47:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6D53A6D3F; Mon, 6 Jul 2009 12:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QOuQbvvmpjv; Mon, 6 Jul 2009 12:47:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 797963A6983; Mon, 6 Jul 2009 12:47:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNu5e-000Hvc-63 for namedroppers-data0@psg.com; Mon, 06 Jul 2009 19:43:02 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNu5T-000Huc-2B for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 19:42:56 +0000 Received: by gxk1 with SMTP id 1so6884810gxk.17 for ; Mon, 06 Jul 2009 12:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.54.6 with SMTP id c6mr4464419aga.29.1246909368951; Mon, 06 Jul 2009 12:42:48 -0700 (PDT) In-Reply-To: References: <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> Date: Mon, 6 Jul 2009 12:42:48 -0700 Message-ID: Subject: Re: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: Edward Lewis Cc: Mark Andrews , Florian Weimer , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 6, 2009 at 11:56 AM, Edward Lewis wrote: > Add a name server. =A0Watch the traffic rate grow, gain confidence. Tell = the > parent you added it. Parent adds name server to it's DNS. If this weren't > "allowed" you would have to get parent and child to do a simultaneous > change. This isn't the scenario I understood we were discussing. -- to unsubscribe send a message to namedroppers-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 Jul 6 13:55:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787CA3A6DC1; Mon, 6 Jul 2009 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=0.567, 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 zly3qYBpv1Om; Mon, 6 Jul 2009 13:55:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E2E53A6983; Mon, 6 Jul 2009 13:55:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNvBI-000P3k-RD for namedroppers-data0@psg.com; Mon, 06 Jul 2009 20:52:56 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNvB2-000P1f-2X for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 20:52:51 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id E62C4327A7C; Mon, 6 Jul 2009 20:52:38 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id AD754327A72; Mon, 6 Jul 2009 20:52:37 +0000 (UTC) Message-ID: <4A526415.1050701@isc.org> Date: Mon, 06 Jul 2009 15:52:37 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: George Barwood CC: Matthew Dempsky , Edward Lewis , Mark Andrews , Florian Weimer , IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > (4) I still think a protocol extension to allow large responses to be sent using > short UDP packets may be advisable. I'm concerned about relying on TCP. Every time I see someone propose implementing TCP using UDP, I worry. TCP has a long history, and includes features like flow-control, and is well understood by filtering engines, etc. Anything we do to re-write parts of it will eventually run into the same issues, and we'll end up with TCP as it was 15 years ago. And we'll have firewalls which try to be overly-clever and change the contents of the DNS packets returned, or just drop them as strange and broken. Or decide to re-assemble them to analyze them after. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSZBQACgkQ+NNi0s9NRJ2TAACeOo9cG1rcXe183JI7P+WgO5R2 oHwAniTdtzYn96rEreJ9dBWu5bA70QW8 =MPHy -----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 Jul 6 14:31:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4613A6819; Mon, 6 Jul 2009 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgYLso9vJKLK; Mon, 6 Jul 2009 14:31:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6432C3A67F1; Mon, 6 Jul 2009 14:31:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNvhe-0002VC-2j for namedroppers-data0@psg.com; Mon, 06 Jul 2009 21:26:22 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNvhS-0002UQ-N0 for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 21:26:16 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4DC15A83B2 for ; Mon, 6 Jul 2009 21:26:10 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC In-Reply-To: Your message of "Mon, 06 Jul 2009 12:42:48 MST." References: <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 06 Jul 2009 21:26:10 +0000 Message-ID: <57858.1246915570@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Mon, 6 Jul 2009 12:42:48 -0700 > From: Matthew Dempsky > > > Add a name server. Watch the traffic rate grow, gain confidence. Tell > > the parent you added it. Parent adds name server to it's DNS. If this > > weren't "allowed" you would have to get parent and child to do a > > simultaneous change. > > This isn't the scenario I understood we were discussing. it's an in-scope and compatible variation on the theme we were discussing. -- to unsubscribe send a message to namedroppers-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 Jul 6 14:44:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD4C28C35E; Mon, 6 Jul 2009 14:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1qddjHOLiyc; Mon, 6 Jul 2009 14:44:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D15F28C357; Mon, 6 Jul 2009 14:44:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNvvy-0003pT-4u for namedroppers-data0@psg.com; Mon, 06 Jul 2009 21:41:10 +0000 Received: from [209.85.217.205] (helo=mail-gx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNvvn-0003o7-CY for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 21:41:04 +0000 Received: by gxk1 with SMTP id 1so7007836gxk.17 for ; Mon, 06 Jul 2009 14:40:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.50.5 with SMTP id x5mr4500585agx.95.1246916457274; Mon, 06 Jul 2009 14:40:57 -0700 (PDT) In-Reply-To: <57858.1246915570@nsa.vix.com> References: <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <57858.1246915570@nsa.vix.com> Date: Mon, 6 Jul 2009 14:40:57 -0700 Message-ID: Subject: Re: [dnsext] Name server agility with DNSSEC From: Matthew Dempsky To: Paul Vixie Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 6, 2009 at 2:26 PM, Paul Vixie wrote: > it's an in-scope and compatible variation on the theme we were discussing. I asked "does X actually happen?" and I was given the answer "yes, Y happens all the time." I don't mind discussing Y too, but it doesn't answer my question. -- to unsubscribe send a message to namedroppers-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 Jul 6 15:41:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8918D3A6DA8; Mon, 6 Jul 2009 15:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.829 X-Spam-Level: *** X-Spam-Status: No, score=3.829 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+-yBp-hm6Le; Mon, 6 Jul 2009 15:41:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC3D23A6B3D; Mon, 6 Jul 2009 15:41:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNwnP-0007uI-Nf for namedroppers-data0@psg.com; Mon, 06 Jul 2009 22:36:23 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNwnE-0007tT-R5 for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 22:36:18 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MNwn7-0004To-Pd; Mon, 06 Jul 2009 23:36:05 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MNwn7-0005UB-5x; Mon, 06 Jul 2009 23:36:05 +0100 Message-ID: From: "George Barwood" To: "Michael Graff" Cc: "Matthew Dempsky" , "Edward Lewis" , "Mark Andrews" , "Florian Weimer" , "IETF DNSEXT WG" References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Mon, 6 Jul 2009 23:36:03 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Michael Graff" > George Barwood wrote: >> (4) I still think a protocol extension to allow large responses to be >> sent using >> short UDP packets may be advisable. I'm concerned about relying on TCP. > > Every time I see someone propose implementing TCP using UDP, I worry. Well I don't think that is what is proposed. What I think best is to mimic the current UDP traffic characteristics, with a modest increase in the number of packets, and a moderate increase in packet size, below the ethernet MTU ( and with the option to stay below 512 bytes ). I don't think that is worrisome, given that the UDP capability of the infrastructure is hugely in excess of that needed for legitimate traffic. I don't have a deep understanding of TCP, but the little I do know worries me. Isn't it very vulnerable to denial of service attacks? Will it not be almost trivial to take down the TLD's TCP service? -- to unsubscribe send a message to namedroppers-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 Jul 6 17:20:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9A328C134; Mon, 6 Jul 2009 17:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlcqqOFe-J8z; Mon, 6 Jul 2009 17:20:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E82CC3A68AA; Mon, 6 Jul 2009 17:20:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNyKa-000Egf-6G for namedroppers-data0@psg.com; Tue, 07 Jul 2009 00:14:44 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNyKN-000Efk-P9 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 00:14:37 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7F9E8E606E; Tue, 7 Jul 2009 00:14:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n670EQQC010198; Tue, 7 Jul 2009 10:14:27 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907070014.n670EQQC010198@drugs.dv.isc.org> To: "W.C.A. Wijngaards" Cc: Mark Andrews , Steve Crocker , DNSEXT WG From: Mark Andrews References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-reply-to: Your message of "Mon, 06 Jul 2009 10:33:48 +0200." <4A51B6EC.9090706@nlnetlabs.nl> Date: Tue, 07 Jul 2009 10:14:26 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <4A51B6EC.9090706@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/06/2009 03:17 AM, Mark Andrews wrote: > >>> Caches MUST NOT set the AU option on any outgoing query from the > >>> cache when performing recursion on behalf of a stub client. > >> Why? And how does the cache tell a stub client from a non-stub > >> client? > > Caches don't use this option. The only clients that use > > this option are stub clients. Anything else is asking for > > future problems. > > +1. The algo-signal option is then useful for stub clients. > > >> I think for a long time to come, most DO=1 queries will come from > >> non-stubs, so the proposed protocol should apply there as well. > > > > Cache's cascade. It is impossible to differentiate between > > a stub and a cascading cache. > > +1. So, using the signaling option would then be some sort of option > for caching resolvers. An option that would be turned off by default, > since even on localhost there might be further querying validators > (even if they are not full resolvers, they may want to perform their > own validation). This would limit deployment. No. A cache should only ever respond to this option. It should never set this option. This option is only useful over the last link. Mark > Summarizing: I think supporting algorithm rollover is a good thing. > But the draft does not help caches. > > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpRtuwACgkQkDLqNwOhpPi4vACgivHXK6gaZD/GB4GzzkipuAcK > hIgAmgN957Kbp0qHcTKubuDPiXKk+VvM > =xH6w > -----END PGP SIGNATURE----- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 17:22:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A09828C134; Mon, 6 Jul 2009 17:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.227 X-Spam-Level: X-Spam-Status: No, score=-105.227 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbiFBgtvjeQJ; Mon, 6 Jul 2009 17:22:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED2033A68AA; Mon, 6 Jul 2009 17:22:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNyOc-000Ewt-HN for namedroppers-data0@psg.com; Tue, 07 Jul 2009 00:18:54 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNyOL-000Evx-2T for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 00:18:48 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 9F43568B53A0 for ; Mon, 6 Jul 2009 17:18:36 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Brightmail Gateway) with ESMTP id 894442808A for ; Mon, 6 Jul 2009 17:18:36 -0700 (PDT) X-AuditID: 11807134-a7481bb0000021f3-33-4a52945ca311 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with ESMTP id 6CAAE2802B for ; Mon, 6 Jul 2009 17:18:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [192.168.1.27] ([64.142.82.158]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KMD00NJRY6Y0D10@elliott.apple.com> for namedroppers@ops.ietf.org; Mon, 06 Jul 2009 17:18:36 -0700 (PDT) Message-id: <4CD4D259-3AED-4093-9371-10A21DDC83B7@apple.com> To: namedroppers@ops.ietf.org From: Stuart Cheshire Subject: [dnsext] EDNS0 OWNER Option Date: Mon, 06 Jul 2009 17:18:35 -0700 X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Last year I sent the email below outlining the proposed EDNS0 OWNER Option: > From: Stuart Cheshire > Date: 16 November 2008 9:29:42 PM PST > To: namedroppers@ops.ietf.org > Subject: EDNS0 Option Code > > I'm planning to request a new EDNS0 Option Code from IANA, and I > thought it would make sense to run the idea by this group first. > I'll be in the dnsext meeting on Tuesday to answer any questions in > person. > > The new option code is for something I'm calling a sleep proxy. > > The idea of "Wake On LAN Magic Packet" has been around for more > than ten years, but so far it's had limited use. > > The idea of my sleep proxy is that when a host (that supports DNS- > SD/mDNS) goes to sleep, it uses DNS Update to transfer its DNS-SD > records to a sleep proxy on the same link (which it discovers using > DNS-SD/mDNS). At the end of the DNS Update packet it adds an EDNS0 > OPT record in the additional section, containing an EDNS0 "owner" > sub-option. > > ... Today I submitted an Internet-Draft describing the option in more detail: Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.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 Jul 6 17:44:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F183A6DD1; Mon, 6 Jul 2009 17:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6WeVZQ8Insq; Mon, 6 Jul 2009 17:44:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CC4D3A6919; Mon, 6 Jul 2009 17:43:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNyit-000GJE-7k for namedroppers-data0@psg.com; Tue, 07 Jul 2009 00:39:51 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNyih-000GIP-Py for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 00:39:45 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id BD354E6070; Tue, 7 Jul 2009 00:39:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n670dBS4010629; Tue, 7 Jul 2009 10:39:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907070039.n670dBS4010629@drugs.dv.isc.org> To: Stephane Bortzmeyer Cc: Mark Andrews , Florian Weimer , Matthew Dempsky , IETF DNSEXT WG From: Mark Andrews References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052357.n65Nve9i092970@drugs.dv.isc.org> <20090706100449.GA27766@nic.fr> Subject: [dnsext] Re: Name server agility with DNSSEC In-reply-to: Your message of "Mon, 06 Jul 2009 12:04:49 +0200." <20090706100449.GA27766@nic.fr> Date: Tue, 07 Jul 2009 10:39:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090706100449.GA27766@nic.fr>, Stephane Bortzmeyer writes: > On Mon, Jul 06, 2009 at 09:57:40AM +1000, > Mark Andrews wrote > a message of 39 lines which said: > > > And if parent zones administrators did the correct thing and not > > process changes to NS RRsets until both the old and new servers are > > serving the NS RRset being requested to be added this stupid > > practice would just ceases to be a issue. > > We (the .FR managers) are often regarded as specially anal-retentive > because a successful technical check is required before any change > (not only the creation, any technical change) in the delegation. > > Nevertheless, we do not perform this test, so I doubt anyone actually > does it. But the lack of the check is what has got us into this silly position. We should be encouraging best current practice rather than saying it shouldn't be done. > > You just need to make the old master be a slave of the new master > > and the zone contents will just transfer to all the other old > > slaves. This isn't rocket science. > > But the problem is not entirely technical. It is partly a question of > scale (imagine running a DNS hoster with 100,000 zones, all from your > database, how many changes of your ACL - for ingoing transfers - and > of your authoritative configuration - for outgoing transfers?). Which can all be automated. > But it is mostly a matter of business. If you mandate such a rule, any > DNS hoster will be able to delay the departure of a customer at > will. A transfer from one hoster to another MUST NOT depend on the > good will of the "loser". Then have a option that says something like "By proceeding with this transfer you acknowledge that there will be disruptions to the serving of this zone." People need to be made aware that they are not following best current pratice. > (We will have simlilar problems with DNSSEC, with DNS hosters refusing > to give the private key to a leaving customer.) You don't need to give the private key. You just need to the DNSKEY RRset signed with it to enable a smooth transition. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 18:14:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570713A6DF5; Mon, 6 Jul 2009 18:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G91zyxz3dr6G; Mon, 6 Jul 2009 18:14:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3F2F3A6DC1; Mon, 6 Jul 2009 18:14:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNzDO-000Ia6-Bp for namedroppers-data0@psg.com; Tue, 07 Jul 2009 01:11:22 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNzDB-000IZI-T2 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 01:11:16 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0B438E606E; Tue, 7 Jul 2009 01:11:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n671B5Gj011471; Tue, 7 Jul 2009 11:11:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907070111.n671B5Gj011471@drugs.dv.isc.org> To: "Antoin Verschuren" Cc: "IETF DNSEXT WG" From: Mark Andrews References: <49238.1246758423@nsa.vix.com> <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052357.n65Nve9i092970@drugs.dv.isc.org> <850A39016FA57A4887C0AA3C8085F949F02AFD@KAEVS1.SIDN.local> Subject: Re: [dnsext] Name server agility with DNSSEC In-reply-to: Your message of "Mon, 06 Jul 2009 12:46:44 +0200." <850A39016FA57A4887C0AA3C8085F949F02AFD@KAEVS1.SIDN.local> Date: Tue, 07 Jul 2009 11:11:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <850A39016FA57A4887C0AA3C8085F949F02AFD@KAEVS1.SIDN.local>, "Antoin Verschuren" writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org [mailto:owner- > > namedroppers@ops.ietf.org] On Behalf Of Mark Andrews > > Subject: Re: [dnsext] Name server agility with DNSSEC > > > > And if parent zones administrators did the correct thing and not > > process changes to NS RRsets until both the old and new servers are > > serving the NS RRset being requested to be added this stupid practice > > would just ceases to be a issue. > > This would work well if all drivers would be car-mechanics as well. > But let's face it, not all dns-operators are dns experts anymore. > If this isn't automated in deployed software, with a simple enough > button for the operator to push on, he's not capable of doing this. > Mother-in-laws have become domain owners. > We need to give them the tools to operate their zones safely. Most of them out source the operation of the DNS service. For those that don't this really isn't a issue. > We still have the rule in our policy that losing DNS-operators > should run secondary for a while after a transfer. But in practice, > since "security rules" don't allow AXFR transfers anymore, nobody > is able to conform to these best practices anymore. It's simply not > scalable anymore to have a many to many relationship between > DNS-operators to allow for a smooth transition. "security rules" which have no justifiable reason for existing 99.99% of the time (general blanket on AXFR) and which have no reason to exist at all when a zone is being transfered. This is the tail wagging the dog. > And as I've demonstrated, with DNSSEC, we only have a choice > between changing resolver behavior, or clearly document and deploy > a complex transition process that conflicts with business interests. > I do have some faith in documenting, but getting this deployed in > all the commercially driven non-technical domain portfolio management > packages is a battle I'm afraid we're going to lose. > Mandating this in policy by a parent without the proper tools or > expertise in the current deployed base of dns-operators would mean > suicide for a registry, so they chose not to do this. The tools to do this have existed for 20 plus years. Just about every nameserver supports AXFR. Those that don't directly have toolkits that do. > So instead of sticking our heads into the sand, let's come up > with a solution that does work in the real world. The companies that host the DNS services are being paid money to run and manage the DNS operations for their clients. Part of that is managing transfers of domains to and from them. All we are asking them to do is what they have been paid to do. It is a cost of business. Mark > Antoin Verschuren > > Technical Policy Advisor SIDN > Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ > -----BEGIN PGP SIGNATURE----- > Version: 9.6.3 (Build 3017) > > wsBVAwUBSlHWFDqHrM883AgnAQgovQgA3lCz2iOlrijsNvtJuRyh6vOcoWkBBFfr > aTGreg0eBl6JvYUfBo3GQS0vsMWdlb/81vex9+ljSt1Diqz2pEzt7vws4rOaY/l4 > sswDOwyqpTf5z9aXWasvfhEbPZJ6vBjiemewLPAQdL0LMUnqDOCjzezrOUvdmM0P > 2TdeS+dHV+wmQZn3z/3GXsZ4kcKGXjfMI5KsfRSV+tFrsV1UeS5DfK+h3Cp55RiJ > Sq+xQveDIkL9JRrhw0qPpoksQd+cJwZBVgT5JuxZlFWIFn4KPcnMjFh5zR9Gdkbd > EQDD1kvVYu13aOJbS9LLTQxRgRwkeE/KeaJKJNCcHTzdgPsSuRhlMQ== > =tMpE > -----END PGP SIGNATURE----- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 20:44:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C4A28C0F5; Mon, 6 Jul 2009 20:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.516 X-Spam-Level: X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 TQe5dtHeOHqy; Mon, 6 Jul 2009 20:44:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9398628C2ED; Mon, 6 Jul 2009 20:44:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO1W2-00020u-Eb for namedroppers-data0@psg.com; Tue, 07 Jul 2009 03:38:46 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO1Vr-0001yH-0N for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 03:38:40 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n673W0dc023777; Tue, 7 Jul 2009 03:32:01 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n673W0gx023776; Tue, 7 Jul 2009 03:32:00 GMT Date: Tue, 7 Jul 2009 03:32:00 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: "W.C.A. Wijngaards" , Steve Crocker , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090707033200.GC21644@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <200907070014.n670EQQC010198@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907070014.n670EQQC010198@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 10:14:26AM +1000, Mark Andrews wrote: > > In message <4A51B6EC.9090706@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 07/06/2009 03:17 AM, Mark Andrews wrote: > > >>> Caches MUST NOT set the AU option on any outgoing query from the > > >>> cache when performing recursion on behalf of a stub client. > > >> Why? And how does the cache tell a stub client from a non-stub > > >> client? > > > Caches don't use this option. The only clients that use > > > this option are stub clients. Anything else is asking for > > > future problems. > > > > +1. The algo-signal option is then useful for stub clients. > > > > >> I think for a long time to come, most DO=1 queries will come from > > >> non-stubs, so the proposed protocol should apply there as well. > > > > > > Cache's cascade. It is impossible to differentiate between > > > a stub and a cascading cache. > > > > +1. So, using the signaling option would then be some sort of option > > for caching resolvers. An option that would be turned off by default, > > since even on localhost there might be further querying validators > > (even if they are not full resolvers, they may want to perform their > > own validation). This would limit deployment. > > No. A cache should only ever respond to this option. It > should never set this option. This option is only useful > over the last link. > > Mark > i'm a bit confused here Mark. First, you state: "cache's cascade. It is impossible to differentiate between a stub and a cascading cache." and then... "No. A cache should only ever respond to this option. It should never set this option. This option is only useful over the last link." er... just how and the heck are we supposed to know its the "last link" when it is impossible to differentiate btwn a cache and a stub? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 21:07:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3191228C440; Mon, 6 Jul 2009 21:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8GE6AL7miT8; Mon, 6 Jul 2009 21:07:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 213C73A6833; Mon, 6 Jul 2009 21:07:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO1rQ-0004NI-Uj for namedroppers-data0@psg.com; Tue, 07 Jul 2009 04:00:52 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO1rE-0004M0-F8 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 04:00:46 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 80A61E6071; Tue, 7 Jul 2009 04:00:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6740bBx013891; Tue, 7 Jul 2009 14:00:37 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907070400.n6740bBx013891@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Mark Andrews , "W.C.A. Wijngaards" , Steve Crocker , DNSEXT WG From: Mark Andrews References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <200907070014.n670EQQC010198@drugs.dv.isc.org> <20090707033200.GC21644@vacation.karoshi.com.> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-reply-to: Your message of "Tue, 07 Jul 2009 03:32:00 GMT." <20090707033200.GC21644@vacation.karoshi.com.> Date: Tue, 07 Jul 2009 14:00:37 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090707033200.GC21644@vacation.karoshi.com.>, bmanning@vacation.k aroshi.com writes: > On Tue, Jul 07, 2009 at 10:14:26AM +1000, Mark Andrews wrote: > > > > In message <4A51B6EC.9090706@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 07/06/2009 03:17 AM, Mark Andrews wrote: > > > >>> Caches MUST NOT set the AU option on any outgoing query from the > > > >>> cache when performing recursion on behalf of a stub client. > > > >> Why? And how does the cache tell a stub client from a non-stub > > > >> client? > > > > Caches don't use this option. The only clients that use > > > > this option are stub clients. Anything else is asking for > > > > future problems. > > > > > > +1. The algo-signal option is then useful for stub clients. > > > > > > >> I think for a long time to come, most DO=1 queries will come from > > > >> non-stubs, so the proposed protocol should apply there as well. > > > > > > > > Cache's cascade. It is impossible to differentiate between > > > > a stub and a cascading cache. > > > > > > +1. So, using the signaling option would then be some sort of option > > > for caching resolvers. An option that would be turned off by default, > > > since even on localhost there might be further querying validators > > > (even if they are not full resolvers, they may want to perform their > > > own validation). This would limit deployment. > > > > No. A cache should only ever respond to this option. It > > should never set this option. This option is only useful > > over the last link. > > > > Mark > > > > i'm a bit confused here Mark. First, you state: > > "cache's cascade. It is impossible to differentiate between > a stub and a cascading cache." > > and then... > > "No. A cache should only ever respond to this option. It > should never set this option. This option is only useful > over the last link." > > er... just how and the heck are we supposed to know its the > "last link" when it is impossible to differentiate btwn a > cache and a stub? A cache is never the last link even when it is the one making the question. There is always something potentially down stream from it. The cache needs to be able to answer whatever questions are asked of it. This requires that it has the data or has to fetch the data. Assuming you don't want to track that which answers are partial answers a cache will never request a partial answer. Mark > --bill -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 21:23:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC46328C4A8; Mon, 6 Jul 2009 21:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.515 X-Spam-Level: X-Spam-Status: No, score=-4.515 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 kJiwGcTz4Ic2; Mon, 6 Jul 2009 21:23:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5F5928C49D; Mon, 6 Jul 2009 21:23:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO29E-0005cz-LQ for namedroppers-data0@psg.com; Tue, 07 Jul 2009 04:19:16 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO293-0005cR-7i for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 04:19:10 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n674Cudc024454; Tue, 7 Jul 2009 04:12:56 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n674CuO2024453; Tue, 7 Jul 2009 04:12:56 GMT Date: Tue, 7 Jul 2009 04:12:55 +0000 From: bmanning@vacation.karoshi.com To: "W.C.A. Wijngaards" Cc: Mark Andrews , Steve Crocker , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090707041255.GA23904@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A51B6EC.9090706@nlnetlabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 06, 2009 at 10:33:48AM +0200, W.C.A. Wijngaards wrote: > +1. So, using the signaling option would then be some sort of option > for caching resolvers. An option that would be turned off by default, > since even on localhost there might be further querying validators > (even if they are not full resolvers, they may want to perform their > own validation). This would limit deployment. > > Summarizing: I think supporting algorithm rollover is a good thing. > But the draft does not help caches. > > Best regards, > Wouter Wouter, for myself, I would dearly love to disambiguate between a caching resolver and a caching validator. i view these functions as generally orthoginal and would not expect the same caching algorithms to be efficient or even viable between a resolver and a validator. inconsistant signing algorithms on a validation chain will sort of require tracking a signing algorithm per RRset in the chain... and if the validator is going to attempt validation, will there be some nifty signal to indicate a dificency and trigger a signing algorithm "patch" be downloaded from a trusted source and installed so that validation may proceed? Or will there be some equally heinous trick to sift through old TA's to terminate an apparent island of trust when an unknown algorithm is encountered? Inquiring minds want to know -- --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 6 21:45:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CDC3A6A3A; Mon, 6 Jul 2009 21:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3XXSVl4GbbQ; Mon, 6 Jul 2009 21:45:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5368D3A6971; Mon, 6 Jul 2009 21:44:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO2Tm-00075Z-Gc for namedroppers-data0@psg.com; Tue, 07 Jul 2009 04:40:30 +0000 Received: from [209.86.89.64] (helo=elasmtp-curtail.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO2Tb-00074Q-3z for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 04:40:24 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=AYq0+QcxnPXCLn7mo/NwDo8C0vp8nyHaLgsD1pEYjdk22zX2nX50gKK06U3TyH1/; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.201] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MO2TQ-0004fI-SX; Tue, 07 Jul 2009 00:40:09 -0400 Message-ID: <4A52D18C.54E8FD54@ix.netcom.com> Date: Mon, 06 Jul 2009 21:39:40 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: "W.C.A. Wijngaards" , Mark Andrews , Steve Crocker , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606887f0143ba8c62e8b79f0dc515f7971fe7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.201 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill and all, I do not know the answers in fact to your well posed questions. But I suspect given what I have thus read, the answer is your latter question. >;) If so, such would be a mistake that will be paid by many, disliked by many more in the future, and eventually rejected. bmanning@vacation.karoshi.com wrote: > On Mon, Jul 06, 2009 at 10:33:48AM +0200, W.C.A. Wijngaards wrote: > > +1. So, using the signaling option would then be some sort of option > > for caching resolvers. An option that would be turned off by default, > > since even on localhost there might be further querying validators > > (even if they are not full resolvers, they may want to perform their > > own validation). This would limit deployment. > > > > Summarizing: I think supporting algorithm rollover is a good thing. > > But the draft does not help caches. > > > > Best regards, > > Wouter > > Wouter, > > for myself, I would dearly love to disambiguate between > a caching resolver and a caching validator. i view these > functions as generally orthoginal and would not expect > the same caching algorithms to be efficient or even viable > between a resolver and a validator. > > inconsistant signing algorithms on a validation chain will > sort of require tracking a signing algorithm per RRset in > the chain... and if the validator is going to attempt validation, > will there be some nifty signal to indicate a dificency and trigger > a signing algorithm "patch" be downloaded from a trusted source and > installed so that validation may proceed? > > Or will there be some equally heinous trick to sift through old > TA's to terminate an apparent island of trust when an unknown > algorithm is encountered? > > Inquiring minds want to know -- > > --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 01:58:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3853A6E12; Tue, 7 Jul 2009 01:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr5V5kcyDh43; Tue, 7 Jul 2009 01:58:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B60893A6A62; Tue, 7 Jul 2009 01:58:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6On-000NtC-UX for namedroppers-data0@psg.com; Tue, 07 Jul 2009 08:51:37 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6Oc-000Nrv-3C for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 08:51:32 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n678pBqB013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 10:51:19 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A530C7F.8050906@nlnetlabs.nl> Date: Tue, 07 Jul 2009 10:51:11 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> In-Reply-To: <20090707041255.GA23904@vacation.karoshi.com.> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 07 Jul 2009 10:51:20 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2009 06:12 AM, bmanning@vacation.karoshi.com wrote: > inconsistant signing algorithms on a validation chain will > sort of require tracking a signing algorithm per RRset in > the chain... and if the validator is going to attempt validation, > will there be some nifty signal to indicate a dificency and trigger > a signing algorithm "patch" be downloaded from a trusted source and > installed so that validation may proceed? If the device supports software updates, then supposedly the validator is updated too, and supports the latest set of algos. > Or will there be some equally heinous trick to sift through old > TA's to terminate an apparent island of trust when an unknown > algorithm is encountered? This is what DNSSEC does, right? Validators build the chain of trust and terminate to unsigned when only unknown algorithms are available. But you are right, for sifting (a nifty hack :-) ) through history would need to check for unknown algorithms. Fixed that in the next instalment of the trust-history draft. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpTDH8ACgkQkDLqNwOhpPiKZwCgg+AAn/XY5xn4yEO5q3xYNE7G sE4AoKeINO3e7rWEAYHgHyH1f8iTXN34 =2MAc -----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 Jul 7 02:18:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCA33A6B97; Tue, 7 Jul 2009 02:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.515 X-Spam-Level: X-Spam-Status: No, score=-4.515 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 CU+9HyJaaosM; Tue, 7 Jul 2009 02:18:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 256B53A682D; Tue, 7 Jul 2009 02:18:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6lE-000PQR-JY for namedroppers-data0@psg.com; Tue, 07 Jul 2009 09:14:48 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6l3-000PPK-P3 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 09:14:43 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n679BPdc026880; Tue, 7 Jul 2009 09:11:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n679BPM5026879; Tue, 7 Jul 2009 09:11:25 GMT Date: Tue, 7 Jul 2009 09:11:25 +0000 From: bmanning@vacation.karoshi.com To: "W.C.A. Wijngaards" Cc: bmanning@vacation.karoshi.com, DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090707091125.GA26794@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A530C7F.8050906@nlnetlabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 10:51:11AM +0200, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/07/2009 06:12 AM, bmanning@vacation.karoshi.com wrote: > > inconsistant signing algorithms on a validation chain will > > sort of require tracking a signing algorithm per RRset in > > the chain... and if the validator is going to attempt validation, > > will there be some nifty signal to indicate a dificency and trigger > > a signing algorithm "patch" be downloaded from a trusted source and > > installed so that validation may proceed? > > If the device supports software updates, then supposedly the > validator is updated too, and supports the latest set of algos. so you would have no problems w/ a software driven update to your SSL libraries? > > Or will there be some equally heinous trick to sift through old > > TA's to terminate an apparent island of trust when an unknown > > algorithm is encountered? > > This is what DNSSEC does, right? Validators build the chain of trust > and terminate to unsigned when only unknown algorithms are available. well, terminate w/ unknown ... not quite the same as unsigned. > But you are right, for sifting (a nifty hack :-) ) through history > would need to check for unknown algorithms. Fixed that in the > next instalment of the trust-history draft. er - that would be "heinous trick" e.g. local DLV, not nifty haq. now you make me go read "trust-history" ... kind of sounds like the same targeted outcome as a long-ago expired "M of N" draft that was an alternative to what became RFC 5011. > Best regards, > Wouter --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 02:30:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601543A6E3B; Tue, 7 Jul 2009 02:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[AWL=-0.328, 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 Xo9kluCX2q7a; Tue, 7 Jul 2009 02:30:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 233823A68E1; Tue, 7 Jul 2009 02:30:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6wm-0000NZ-4Z for namedroppers-data0@psg.com; Tue, 07 Jul 2009 09:26:44 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6wU-0000Lr-R2 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 09:26:38 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MO6zZ-000085-2j; Tue, 07 Jul 2009 11:29:37 +0200 Received: by bfk.de with local id 1MO6wH-0004Qm-V2; Tue, 07 Jul 2009 09:26:13 +0000 To: "W.C.A. Wijngaards" Cc: bmanning@vacation.karoshi.com, DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> From: Florian Weimer Date: Tue, 07 Jul 2009 09:26:13 +0000 In-Reply-To: <4A530C7F.8050906@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Tue\, 07 Jul 2009 10\:51\:11 +0200") Message-ID: <82fxd8ete2.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: * W. C. A. Wijngaards: > On 07/07/2009 06:12 AM, bmanning@vacation.karoshi.com wrote: >> inconsistant signing algorithms on a validation chain will >> sort of require tracking a signing algorithm per RRset in >> the chain... and if the validator is going to attempt validation, >> will there be some nifty signal to indicate a dificency and trigger >> a signing algorithm "patch" be downloaded from a trusted source and >> installed so that validation may proceed?=20=20 > > If the device supports software updates, then supposedly the > validator is updated too, and supports the latest set of algos. If unrelated protocol changes are tied to algorithm numbers, it's sometimes not advisable to roll out new algorithms through standard software update procedures because the risk/benefit tradeoff is rather poor. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 02:43:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4EC3A6E3D; Tue, 7 Jul 2009 02:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.515 X-Spam-Level: X-Spam-Status: No, score=-4.515 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 Q0NsyKN3mvlK; Tue, 7 Jul 2009 02:43:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F9CC3A6E33; Tue, 7 Jul 2009 02:43:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO78o-0001XN-V7 for namedroppers-data0@psg.com; Tue, 07 Jul 2009 09:39:10 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO78e-0001WM-3Y for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 09:39: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 n679Zidc027099; Tue, 7 Jul 2009 09:35:44 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n679Zhsg027098; Tue, 7 Jul 2009 09:35:43 GMT Date: Tue, 7 Jul 2009 09:35:43 +0000 From: bmanning@vacation.karoshi.com To: Florian Weimer Cc: "W.C.A. Wijngaards" , bmanning@vacation.karoshi.com, DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090707093543.GB26794@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> <82fxd8ete2.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82fxd8ete2.fsf@mid.bfk.de> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 09:26:13AM +0000, Florian Weimer wrote: > * W. C. A. Wijngaards: > > > On 07/07/2009 06:12 AM, bmanning@vacation.karoshi.com wrote: > >> inconsistant signing algorithms on a validation chain will > >> sort of require tracking a signing algorithm per RRset in > >> the chain... and if the validator is going to attempt validation, > >> will there be some nifty signal to indicate a dificency and trigger > >> a signing algorithm "patch" be downloaded from a trusted source and > >> installed so that validation may proceed? > > > > If the device supports software updates, then supposedly the > > validator is updated too, and supports the latest set of algos. > > If unrelated protocol changes are tied to algorithm numbers, it's > sometimes not advisable to roll out new algorithms through standard > software update procedures because the risk/benefit tradeoff is rather > poor. > true, true... so let me walk a short path here and you be the guide. I build a DNSSEC validator using FOSS - which (like all good FOSS) leverages other work, i.e. it depends on the SSL libraries for its crypto base. The library I have built with only has MD5 and SHA-1. (yeah, yeah, I built it last century) anyway... along comes this nifty new signed zone - for example, .MIL ... and being the compliant folks that they are, they are using SHA-256... and using said draft, send me a signal that SHA-256 is the algo of choice. Presuming (a huge "willing suspension of disbelief") that there is a tool that lets me get a SHA-256 module, and that my kernel has module support enabled, and I don't want anyone to jack w/ my installed SSL library .... Where would I put said SHA-256 module and how would my DNSSEC validator know how to include/use it? SWAGs cheerfully considered. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 02:56:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7463A696F; Tue, 7 Jul 2009 02:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=-0.317, 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 TtEpFdm2TId9; Tue, 7 Jul 2009 02:56:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5954D3A6924; Tue, 7 Jul 2009 02:56:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO7LU-0002Zo-Dh for namedroppers-data0@psg.com; Tue, 07 Jul 2009 09:52:16 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO7L3-0002XS-10 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 09:52:06 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MO7OF-00041U-CZ; Tue, 07 Jul 2009 11:55:07 +0200 Received: by bfk.de with local id 1MO7Ky-0005K2-K4; Tue, 07 Jul 2009 09:51:44 +0000 To: bmanning@vacation.karoshi.com Cc: "W.C.A. Wijngaards" , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> <82fxd8ete2.fsf@mid.bfk.de> <20090707093543.GB26794@vacation.karoshi.com.> From: Florian Weimer Importance: high Date: Tue, 07 Jul 2009 09:51:44 +0000 In-Reply-To: <20090707093543.GB26794@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Tue\, 7 Jul 2009 09\:35\:43 +0000") Message-ID: <82vdm4ddn3.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: > true, true... so let me walk a short path here and you be the > guide. > > I build a DNSSEC validator using FOSS - which (like all good FOSS) > leverages other work, i.e. it depends on the SSL libraries for > its crypto base. The library I have built with only has MD5 > and SHA-1. (yeah, yeah, I built it last century) And countless other bugs. (You might not use the SSL part for DNSSEC, but some implementations expose the ASN.1 parser during RSA verification.) > anyway... along comes this nifty new signed zone - for example, > .MIL ... and being the compliant folks that they are, they are > using SHA-256... and using said draft, send me a signal that > SHA-256 is the algo of choice. I don't expect anyone to adopt algorithms for widely used zones which haven't been part of OpenSSL and similar libraries for a while (two to three years, say). Currently, this WG sees to that, but even if the RFC requirement for new algorithms is dropped, it's not going to happen for generally interesting zones. > Presuming (a huge "willing suspension of disbelief") that there is > a tool that lets me get a SHA-256 module, and that my kernel has > module support enabled, and I don't want anyone to jack w/ my > installed SSL library .... I'm not sure what you're talking about. Anyway, at Debian, we added a C implementation of AES counter mode to PowerDNS in a security update, in order to strengthen its transaction ID generator. (We probably did that for other DNS clients, too, but I don't remember the details.) I don't consider such changes particularly risky. The resulting code duplication is slightly annoying, but I don't think it's particularly burdensome right now. Note that with algo-signal, there could be less temptation to tie additional DNSSEC features to particular cryptographic algorithms. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 03:56:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9421628C3F9; Tue, 7 Jul 2009 03:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gypl1NSbm9nR; Tue, 7 Jul 2009 03:56:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9349828C25F; Tue, 7 Jul 2009 03:56:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO8Hh-0006rN-QW for namedroppers-data0@psg.com; Tue, 07 Jul 2009 10:52:25 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO8HV-0006q6-M7 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 10:52:20 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 96FF4E6070; Tue, 7 Jul 2009 10:52:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n67Aq8sE015851; Tue, 7 Jul 2009 20:52:08 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907071052.n67Aq8sE015851@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Florian Weimer , "W.C.A. Wijngaards" , DNSEXT WG From: Mark Andrews References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> <82fxd8ete2.fsf@mid.bfk.de> <20090707093543.GB26794@vacation.karoshi.com.> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition In-reply-to: Your message of "Tue, 07 Jul 2009 09:35:43 GMT." <20090707093543.GB26794@vacation.karoshi.com.> Date: Tue, 07 Jul 2009 20:52:08 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090707093543.GB26794@vacation.karoshi.com.>, bmanning@vacation.karoshi.com writes: > On Tue, Jul 07, 2009 at 09:26:13AM +0000, Florian Weimer wrote: > > * W. C. A. Wijngaards: > > > > > On 07/07/2009 06:12 AM, bmanning@vacation.karoshi.com wrote: > > >> inconsistant signing algorithms on a validation chain will > > >> sort of require tracking a signing algorithm per RRset in > > >> the chain... and if the validator is going to attempt validation, > > >> will there be some nifty signal to indicate a dificency and trigger > > >> a signing algorithm "patch" be downloaded from a trusted source and > > >> installed so that validation may proceed? > > > > > > If the device supports software updates, then supposedly the > > > validator is updated too, and supports the latest set of algos. > > > > If unrelated protocol changes are tied to algorithm numbers, it's > > sometimes not advisable to roll out new algorithms through standard > > software update procedures because the risk/benefit tradeoff is rather > > poor. > > > true, true... so let me walk a short path here and you be the > guide. > > I build a DNSSEC validator using FOSS - which (like all good FOSS) > leverages other work, i.e. it depends on the SSL libraries for > its crypto base. The library I have built with only has MD5 > and SHA-1. (yeah, yeah, I built it last century) > > anyway... along comes this nifty new signed zone - for example, > .MIL ... and being the compliant folks that they are, they are > using SHA-256... and using said draft, send me a signal that > SHA-256 is the algo of choice. > > Presuming (a huge "willing suspension of disbelief") that there is > a tool that lets me get a SHA-256 module, and that my kernel has > module support enabled, and I don't want anyone to jack w/ my > installed SSL library .... > > Where would I put said SHA-256 module and how would my DNSSEC validator > know how to include/use it? Well if you looked at named you would see that we don't actually depend on the crypto library for the hash algorithms. We do depend on the crypto library for RSA, DSA and DH support. We can if we want to use the crypto library for md5, sha* on a per algorithm basis. TSIG doesn't depend on OpenSSL being available. DNSSEC does depend on OpenSSL being available. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 04:29:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EBD28C2F4; Tue, 7 Jul 2009 04:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.177 X-Spam-Level: * X-Spam-Status: No, score=1.177 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvOqTZSmKpPM; Tue, 7 Jul 2009 04:29:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88A1928C349; Tue, 7 Jul 2009 04:28:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO8mn-00093q-Nq for namedroppers-data0@psg.com; Tue, 07 Jul 2009 11:24:33 +0000 Received: from [209.85.220.205] (helo=mail-fx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO8mX-00092Y-Jw for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 11:24:28 +0000 Received: by fxm1 with SMTP id 1so3321915fxm.41 for ; Tue, 07 Jul 2009 04:24:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.19 with SMTP id z19mr2710315fao.27.1246965855135; Tue, 07 Jul 2009 04:24:15 -0700 (PDT) From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Tue, 7 Jul 2009 13:23:55 +0200 Message-ID: Subject: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) To: Shane Kerr , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5abccd7a90d046e1bdcad Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --001636c5abccd7a90d046e1bdcad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi everybody, this little draft is an outcome of our little discussion with Shane about allowing slave server to refuse fallback to AXFR or maybe better: to allow more fine-grained control whether AXFR is provided/asked and accepted/refused. F.e. you can try IXFR-ONLY on all masters and only after it fails on all of them, you will do AXFR. There is little benefit for small zone, but great benefit for large zones (with DNSSEC). Shane did a great work on I-D and most information is said in the introduction. Feel free to ask us about details and comments (and nitpicks :)), I or Shane will be happy to explain it or fix the I-D. Ondrej. On Tue, Jul 7, 2009 at 12:24 PM, IETF I-D Submission Tool < idsubmission@ietf.org> wrote: > > A new version of I-D, draft-kerr-ixfr-only-00.txt has been successfuly > submitted by Shane Kerr and posted to the IETF repository. > > Filename: draft-kerr-ixfr-only > Revision: 00 > Title: IXFR-ONLY to Prevent IXFR Fallback to AXFR > Creation_date: 2009-07-07 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master > from falling back from IXFR to AXFR. > > > > The IETF Secretariat. > > > -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- --001636c5abccd7a90d046e1bdcad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everybody,

this little draft is an outcome of our lit= tle discussion with Shane about allowing slave server to refuse fallback to= AXFR or maybe better: to allow more fine-grained control whether AXFR is p= rovided/asked and accepted/refused. F.e. you can try IXFR-ONLY on all maste= rs and only after it fails on all of them, you will do AXFR. There is littl= e benefit for small zone, but great benefit for large zones (with DNSSEC).<= /div>

Shane did a great work on I-D and most information is s= aid in the introduction.

Feel free to ask us about= details and comments (and nitpicks :)), I or Shane will be happy to explai= n it or fix the I-D.

Ondrej.

On Tue= , Jul 7, 2009 at 12:24 PM, IETF I-D Submission Tool <<= a href=3D"mailto:idsubmission@ietf.org">idsubmission@ietf.org> wrote:

A new version of I-D, draft-kerr-ixfr-only-00.txt has been successfuly subm= itted by Shane Kerr and posted to the IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kerr-ixfr-only
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IXFR-ONLY to Prevent IXFR Fallbac= k to AXFR
Creation_date: =C2=A0 2009-07-07
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission
Number_of_pages: 6

Abstract:
Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master
from falling back from IXFR to AXFR.



The IETF Secretariat.





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


--001636c5abccd7a90d046e1bdcad-- -- to unsubscribe send a message to namedroppers-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 Jul 7 04:47:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866163A6D44; Tue, 7 Jul 2009 04:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.514 X-Spam-Level: X-Spam-Status: No, score=-4.514 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 y6wKhnXGxait; Tue, 7 Jul 2009 04:47:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 716AF3A6899; Tue, 7 Jul 2009 04:47:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO95n-000ApP-BO for namedroppers-data0@psg.com; Tue, 07 Jul 2009 11:44:11 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO95S-000An8-3s for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 11:43:57 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n67BdZdc028072; Tue, 7 Jul 2009 11:39:35 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n67BdZMq028071; Tue, 7 Jul 2009 11:39:35 GMT Date: Tue, 7 Jul 2009 11:39:35 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: bmanning@vacation.karoshi.com, Florian Weimer , "W.C.A. Wijngaards" , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090707113935.GA28062@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> <82fxd8ete2.fsf@mid.bfk.de> <20090707093543.GB26794@vacation.karoshi.com.> <200907071052.n67Aq8sE015851@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907071052.n67Aq8sE015851@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 08:52:08PM +1000, Mark Andrews wrote: > > In message <20090707093543.GB26794@vacation.karoshi.com.>, bmanning@vacation.karoshi.com writes: > > On Tue, Jul 07, 2009 at 09:26:13AM +0000, Florian Weimer wrote: > > > * W. C. A. Wijngaards: > > > > > > > On 07/07/2009 06:12 AM, bmanning@vacation.karoshi.com wrote: > > > >> inconsistant signing algorithms on a validation chain will > > > >> sort of require tracking a signing algorithm per RRset in > > > >> the chain... and if the validator is going to attempt validation, > > > >> will there be some nifty signal to indicate a dificency and trigger > > > >> a signing algorithm "patch" be downloaded from a trusted source and > > > >> installed so that validation may proceed? > > > > > > > > If the device supports software updates, then supposedly the > > > > validator is updated too, and supports the latest set of algos. > > > > > > If unrelated protocol changes are tied to algorithm numbers, it's > > > sometimes not advisable to roll out new algorithms through standard > > > software update procedures because the risk/benefit tradeoff is rather > > > poor. > > > > > > true, true... so let me walk a short path here and you be the > > guide. > > > > I build a DNSSEC validator using FOSS - which (like all good FOSS) > > leverages other work, i.e. it depends on the SSL libraries for > > its crypto base. The library I have built with only has MD5 > > and SHA-1. (yeah, yeah, I built it last century) > > > > anyway... along comes this nifty new signed zone - for example, > > .MIL ... and being the compliant folks that they are, they are > > using SHA-256... and using said draft, send me a signal that > > SHA-256 is the algo of choice. > > > > Presuming (a huge "willing suspension of disbelief") that there is > > a tool that lets me get a SHA-256 module, and that my kernel has > > module support enabled, and I don't want anyone to jack w/ my > > installed SSL library .... > > > > Where would I put said SHA-256 module and how would my DNSSEC validator > > know how to include/use it? > > Well if you looked at named you would see that we don't > actually depend on the crypto library for the hash algorithms. why would I look at named? > > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 05:34:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2A33A6A99; Tue, 7 Jul 2009 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs6NoLtJnize; Tue, 7 Jul 2009 05:34:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A173B3A690E; Tue, 7 Jul 2009 05:33:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO9mm-000Edx-IP for namedroppers-data0@psg.com; Tue, 07 Jul 2009 12:28:36 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO9mY-000Ecu-JR for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 12:28:31 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n67CSC1d091268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 14:28:12 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A533F5C.5010501@nlnetlabs.nl> Date: Tue, 07 Jul 2009 14:28:12 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) References: In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 07 Jul 2009 14:28:13 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2009 01:23 PM, Ondřej Surý wrote: > Shane did a great work on I-D and most information is said in the > introduction. > > Feel free to ask us about details and comments (and nitpicks :)), I or > Shane will be happy to explain it or fix the I-D. Hi, Interesting draft, other TLDs may find the feature useful too. One comment, it is a little heavy on the mandatory configuration options. I would like it to be backwards compatible, and "just work". Do you foresee that much trouble in deployment ahead that all these mandatory configuration knobs help the operator? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpTP1wACgkQkDLqNwOhpPhTYwCfQrS8qifB9iqyrZnZ9hKlcddT eYcAnj79AsW7v/u0wPxUq//DtaMx13c5 =0cJ4 -----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 Jul 7 05:41:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B77E3A6D44; Tue, 7 Jul 2009 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.514 X-Spam-Level: X-Spam-Status: No, score=-4.514 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 KSts6OZVzZmH; Tue, 7 Jul 2009 05:41:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CCBF28C458; Tue, 7 Jul 2009 05:41:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO9wF-000FJo-FL for namedroppers-data0@psg.com; Tue, 07 Jul 2009 12:38:23 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO9w4-000FJF-F9 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 12:38:17 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n67CZ2dc028421; Tue, 7 Jul 2009 12:35:02 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n67CZ1O3028420; Tue, 7 Jul 2009 12:35:01 GMT Date: Tue, 7 Jul 2009 12:35:01 +0000 From: bmanning@vacation.karoshi.com To: Florian Weimer Cc: bmanning@vacation.karoshi.com, "W.C.A. Wijngaards" , DNSEXT WG Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition Message-ID: <20090707123501.GA28284@vacation.karoshi.com.> References: <381D3088-6EBE-455F-A37C-CE562225AE00@shinkuro.com> <87prcfq9hi.fsf@mid.deneb.enyo.de> <200907060117.n661HHmC094090@drugs.dv.isc.org> <4A51B6EC.9090706@nlnetlabs.nl> <20090707041255.GA23904@vacation.karoshi.com.> <4A530C7F.8050906@nlnetlabs.nl> <82fxd8ete2.fsf@mid.bfk.de> <20090707093543.GB26794@vacation.karoshi.com.> <82vdm4ddn3.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82vdm4ddn3.fsf@mid.bfk.de> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 09:51:44AM +0000, Florian Weimer wrote: > > true, true... so let me walk a short path here and you be the > > guide. > > > > I build a DNSSEC validator using FOSS - which (like all good FOSS) > > leverages other work, i.e. it depends on the SSL libraries for > > its crypto base. The library I have built with only has MD5 > > and SHA-1. (yeah, yeah, I built it last century) > > And countless other bugs. (You might not use the SSL part for DNSSEC, > but some implementations expose the ASN.1 parser during RSA > verification.) > > > anyway... along comes this nifty new signed zone - for example, > > .MIL ... and being the compliant folks that they are, they are > > using SHA-256... and using said draft, send me a signal that > > SHA-256 is the algo of choice. > > I don't expect anyone to adopt algorithms for widely used zones which > haven't been part of OpenSSL and similar libraries for a while (two to > three years, say). ah - but the last time i touched my libraries was 10 years ago... > Currently, this WG sees to that, but even if the RFC requirement for > new algorithms is dropped, it's not going to happen for generally > interesting zones. may be true. > > > Presuming (a huge "willing suspension of disbelief") that there is > > a tool that lets me get a SHA-256 module, and that my kernel has > > module support enabled, and I don't want anyone to jack w/ my > > installed SSL library .... > > I'm not sure what you're talking about. > > Anyway, at Debian, we added a C implementation of AES counter mode to > PowerDNS in a security update, in order to strengthen its transaction > ID generator. (We probably did that for other DNS clients, too, but I > don't remember the details.) I don't consider such changes > particularly risky. The resulting code duplication is slightly > annoying, but I don't think it's particularly burdensome right now. > > Note that with algo-signal, there could be less temptation to tie > additional DNSSEC features to particular cryptographic algorithms. > > Florian Weimer let me try again. i have a compiled validator, with static links to the then known crypto modules. those crypto modules may be stored in various places in the local filesystem. a signal arrives that indicates a new, not locally known crypto alogrithm is needed and there is a secured channel from a trusted source to get the new crypto algorithm to the site where i have my compiled validator. is there an expectation that such a new crypto algorithm is usable without recompilation of the validator? for me, this harkens back to some early work done by Hotz and Mockapetris on moving RR type definitions to an externally maintained file - so one could add new RR types w/o recompilation of the nameserver code. but such requires a good API... and if this path is followed for crypto algorithms, then we will need a very rigourous API ... anyway - we now return you to your regular namedroppers chatter. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 06:25:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608253A6E6D; Tue, 7 Jul 2009 06:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.103, 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 XK3vpXAWuXgb; Tue, 7 Jul 2009 06:25:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56AC23A67CC; Tue, 7 Jul 2009 06:25:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOAZ7-000Igx-DI for namedroppers-data0@psg.com; Tue, 07 Jul 2009 13:18:33 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOAYl-000If0-3O for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 13:18:16 +0000 Received: from [192.168.1.109] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n67DHwoo043233; Tue, 7 Jul 2009 09:17:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> Date: Tue, 7 Jul 2009 09:17:52 -0400 To: "George Barwood" From: Edward Lewis Subject: Re: [dnsext] Name server agility with DNSSEC Cc: "IETF DNSEXT WG" , "Michael Graff" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 23:36 +0100 7/6/09, George Barwood wrote: >----- Original Message ----- >From: "Michael Graff" >> Every time I see someone propose implementing TCP using UDP, I worry. > >Well I don't think that is what is proposed. Pretty much (replacing UDP with TCP) is what you proposed, once you get through all of the error cases it'll be much like TCP. I've seen this suggestion over 20 years of time, it's a fool's errand. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 06:46:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6FE28C13F; Tue, 7 Jul 2009 06:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeXRfQbaQPf1; Tue, 7 Jul 2009 06:46:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 008A03A6A8A; Tue, 7 Jul 2009 06:46:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOAvk-000KSp-ND for namedroppers-data0@psg.com; Tue, 07 Jul 2009 13:41:56 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOAvZ-000KRl-7e for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 13:41:51 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id E8B6EE606E; Tue, 7 Jul 2009 13:41:43 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) From: Shane Kerr To: "W.C.A. Wijngaards" Cc: namedroppers@ops.ietf.org In-Reply-To: <4A533F5C.5010501@nlnetlabs.nl> References: <4A533F5C.5010501@nlnetlabs.nl> Content-Type: text/plain Organization: ISC Date: Tue, 07 Jul 2009 15:41:40 +0200 Message-Id: <1246974100.3922.15644.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Wouter, On Tue, 2009-07-07 at 14:28 +0200, W.C.A. Wijngaards wrote: > One comment, it is a little heavy on the mandatory configuration > options. I would like it to be backwards compatible, and "just work". > Do you foresee that much trouble in deployment ahead that all these > mandatory configuration knobs help the operator? The only mandatory configuration option is: Implementations MUST allow slaves to disable IXFR-ONLY completely. I guess we can change this to SHOULD. If IXFR-ONLY breaks things then implementors will either add such an option, or people will stop using their software. If it doesn't break things (or cause extra delays, packets, and so on), then such a knob is not necessary after all. :) The other configuration options are: Implementations SHOULD allow slaves to disable IXFR-ONLY for a given master, if this is known in advance. These masters are treated as if they replied with an RCODE other than CannotIXFR or NoError, although no query with IXFR-ONLY is actually sent. Implementations SHOULD allow slaves to disable IXFR-ONLY for a specific zone. This may be useful for small zones, where fallback to AXFR is cheap, or in other cases where IXFR-ONLY is causing problems. I guess either of these could be changed to a MAY. Neither of these is required, because they are merely optimizations. -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 07:03:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C56628C104; Tue, 7 Jul 2009 07:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp4q1SC7BPEj; Tue, 7 Jul 2009 07:03:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6CE03A67CC; Tue, 7 Jul 2009 07:03:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBDC-000M0U-RR for namedroppers-data0@psg.com; Tue, 07 Jul 2009 13:59:58 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBD0-000LzE-9z for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 13:59:52 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n67DxbRS098164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 15:59:38 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A5354C9.7010107@nlnetlabs.nl> Date: Tue, 07 Jul 2009 15:59:37 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Shane Kerr CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) References: <4A533F5C.5010501@nlnetlabs.nl> <1246974100.3922.15644.camel@shane-asus-laptop> In-Reply-To: <1246974100.3922.15644.camel@shane-asus-laptop> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 07 Jul 2009 15:59:38 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shane, On 07/07/2009 03:41 PM, Shane Kerr wrote: > I guess we can change this to SHOULD. If IXFR-ONLY breaks things then > implementors will either add such an option, or people will stop using > their software. If it doesn't break things (or cause extra delays, > packets, and so on), then such a knob is not necessary after all. :) I think you missed yet-another option where the master could disable IXFR-ONLY support for a particular zone. But agreed with you above. > I guess either of these could be changed to a MAY. Neither of these is > required, because they are merely optimizations. So, all of them are not necessary. They are not needed to make IXFR-ONLY work. Therefore I propose to delete the text about the options entirely. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpTVMkACgkQkDLqNwOhpPiIuQCePx7riDGY9u+rvE4QsncVX7vD I/4An2265P+lMxlhoDGIxANCkoU9w12G =isTh -----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 Jul 7 07:09:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DD73A6E5A; Tue, 7 Jul 2009 07:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQY-HmIHlWHY; Tue, 7 Jul 2009 07:09:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 521C93A6C5F; Tue, 7 Jul 2009 07:09:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBJC-000MvZ-Mm for namedroppers-data0@psg.com; Tue, 07 Jul 2009 14:06:10 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBJ1-000Mtw-CF for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 14:06:05 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:fecd:6a66]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n67E5mTC002935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 16:05:48 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A53558C.5030702@NLnetLabs.nl> Date: Tue, 07 Jul 2009 16:02:52 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 07 Jul 2009 16:05:48 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ondřej Surý wrote: > Hi everybody, > > this little draft is an outcome of our little discussion with Shane > about allowing slave server to refuse fallback to AXFR or maybe better: > to allow more fine-grained control whether AXFR is provided/asked and > accepted/refused. F.e. you can try IXFR-ONLY on all masters and only > after it fails on all of them, you will do AXFR. There is little benefit > for small zone, but great benefit for large zones (with DNSSEC). > > Shane did a great work on I-D and most information is said in the > introduction. > > Feel free to ask us about details and comments (and nitpicks :)), I or > Shane will be happy to explain it or fix the I-D. > looks nice. I only gave it a cursory read, but one thing that came to mind was that a master could also respond with AXFR because that is simply smaller than the IXFR it would have made. In that specific case sending the axfr would be more in the spirit of the draft than returning cannotIXFR. It could be in between the lines ("..for the serial requested") but in that case i'd make it quite a bit more explicit. Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 07:48:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D793B3A6E9B; Tue, 7 Jul 2009 07:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyx8UcRaf8sB; Tue, 7 Jul 2009 07:48:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE3D93A6E96; Tue, 7 Jul 2009 07:48:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBtB-000Pmf-KJ for namedroppers-data0@psg.com; Tue, 07 Jul 2009 14:43:21 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBsu-000PlW-0R for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 14:43:15 +0000 Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n67Eh6W2003997 for ; Tue, 7 Jul 2009 10:43:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 7 Jul 2009 10:42:56 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Tue, 7 Jul 2009 10:42:54 -0400 Subject: [dnsext] -03 version of algo-signal posted Thread-Topic: -03 version of algo-signal posted Thread-Index: Acn/ETXdD8ntutXvpUOqSjRm6W82aA== Message-ID: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: "Official" -03 version of algo-signal posted: http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.txt This is different that the working version Steve sent to the list recently. It goes back to the original (-00) version in that the algorithms are a lis= t in the OPT RR, not a single value with assumptions. Please refer to this version for future discussions. Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 08:09:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9653C3A6E61; Tue, 7 Jul 2009 08:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClpGKGq8lSoq; Tue, 7 Jul 2009 08:09:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53B7F3A6B5D; Tue, 7 Jul 2009 08:09:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOCEo-0001zy-SG for namedroppers-data0@psg.com; Tue, 07 Jul 2009 15:05:42 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOCEd-0001yo-En; Tue, 07 Jul 2009 15:05:37 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=dbtOefMkRJJdXjYn2Xpc8wh+9Zhp2d5wWyIW6P0rkVEt9cYuXR1lF62q 4RW/kGVW7ZiRCJjqA3sFmQajf3Xtd5kWnRkdwziOiAFMXzxCq6+jPjI4+ FssqNWjgqM3IkPI; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246979131; x=1278515131; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20-03=20version=20of=20algo-signal=20posted|Date:=20T ue,=207=20Jul=202009=2016:05:22=20+0100|Message-ID:=20|To:=20"Rose,=20Scott=20W."=20|Cc:=20"namedroppers@ops.ietf.org"=20,=0D=0A=09owner-namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20|References:=20; bh=LjZ+2YSq9za9O5qw7rxETNvVNOXSKSsVD+VWezaMcSI=; b=BLLvHZY2FiCe2zKVlllmYMeoaKjxcyF1HAtUGlkhLxi+Vi/0QAD3VHCn nhgzXTdNNTFkL2XS/AFPXLy26IcYOtdwgYbgE0awIGfUuB0t17H/rTj9Q DQxkGXxDYQ0uBmR; X-IronPort-AV: E=Sophos;i="4.42,363,1243810800"; d="scan'208";a="11317557" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 07 Jul 2009 16:05:24 +0100 In-Reply-To: References: To: "Rose, Scott W." Cc: "namedroppers@ops.ietf.org" , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] -03 version of algo-signal posted MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 7 Jul 2009 16:05:22 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/07/2009 04:05:28 PM, Serialize complete at 07/07/2009 04:05:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0052E2CD802575EC_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0052E2CD802575EC_= Content-Type: text/plain; charset="US-ASCII" > > "Official" -03 version of algo-signal posted: > http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.txt > > This is different that the working version Steve sent to the list recently. > It goes back to the original (-00) version in that the algorithms are a list > in the OPT RR, not a single value with assumptions. > > Please refer to this version for future discussions. I don't see any mention of whether this attribute is suitable for use in responses (perhaps to indicate the list of algorithms that are potentially available from the server?) If the intent is that this option should _not_ be returned to the client, IMHO it would make sense for the draft to explicitly say so. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0052E2CD802575EC_= Content-Type: text/html; charset="US-ASCII" >
> "Official" -03 version of algo-signal posted:
>
http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.txt
>
> This is different that the working version Steve sent to the list recently.
> It goes back to the original (-00) version in that the algorithms are a list
> in the OPT RR, not a single value with assumptions.
>
> Please refer to this version for future discussions.

I don't see any mention of whether this attribute is suitable for use in responses (perhaps to indicate the list of algorithms that are potentially available from the server?)

If the intent is that this option should _not_ be returned to the client, IMHO it would make sense for the draft to explicitly say so.

Ray

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


--=_alternative 0052E2CD802575EC_=-- -- to unsubscribe send a message to namedroppers-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 Jul 7 08:24:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8277A3A6BC5; Tue, 7 Jul 2009 08:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bseI2dZ07rJ; Tue, 7 Jul 2009 08:24:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B28673A6977; Tue, 7 Jul 2009 08:24:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOCRU-0002zy-6F for namedroppers-data0@psg.com; Tue, 07 Jul 2009 15:18:48 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOCQv-0002vz-Dm for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 15:18:18 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id A8088C2DA3; Tue, 7 Jul 2009 16:18:10 +0100 (BST) Date: Tue, 07 Jul 2009 16:17:53 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Rose, Scott W." , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] -03 version of algo-signal posted Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 7 July 2009 10:42:54 -0400 "Rose, Scott W." wrote: > It goes back to the original (-00) version in that the algorithms are a > list in the OPT RR, not a single value with assumptions. Why have ALG codes as a list of octets in descending order, rather than (as Ray Bellis suggested) a length field plus a bitfield of up to 252 bits (with bits beyond the supplied bitfield to be treated as zero)? It would appear to me that this will in general be shorter. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 08:37:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AFF3A6BC5; Tue, 7 Jul 2009 08:37:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char D3 hex): To: \323lafur Gu\251\243munds[...] X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXQN7SAekhK9; Tue, 7 Jul 2009 08:37:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74D9F3A699D; Tue, 7 Jul 2009 08:37:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOCen-0004Oe-12 for namedroppers-data0@psg.com; Tue, 07 Jul 2009 15:32:33 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOCea-0004Mz-OI for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 15:32:27 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n67FWHen053637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 08:32:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200905271833.n4RIXK3C005019@stora.ogud.com> References: <200905271833.n4RIXK3C005019@stora.ogud.com> Date: Tue, 7 Jul 2009 08:32:14 -0700 To: Ólafur Gu©£mundsson /DNSEXT chair , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] DNSEXT to meet at IETF-75/Stockholm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:33 PM -0400 5/27/09, Ólafur Gu©£mundsson /DNSEXT chair wrote: >Send in agenda items, so far we have > GOST Algorithm document > Forgery Resilience work (or not) > New charter > ENDS0 Option hurdle, go to template like for RR types > ? Greetings. I have posted two drafts for new signature algorithms, draft-hoffman-dnssec-dsa-sha2-00.txt and draft-hoffman-dnssec-ecdsa-00.txt (see below). These should be considered at the same time as the GOST algorithm document and the related discussion of standards level for getting an IANA assignment. --Paul Hoffman A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DSA with SHA-2 for DNSSEC Author(s) : P. Hoffman Filename : draft-hoffman-dnssec-dsa-sha2-00.txt Pages : 7 Date : 2009-07-06 This document describes how to specify DSA keys and signatures based on SHA-256 with a specific set of parameters in DNSSEC. The keys used are 2048 bits, and have an equivalent security level of 112 bits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-dsa-sha2-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Elliptic Curve DSA for DNSSEC Author(s) : P. Hoffman Filename : draft-hoffman-dnssec-ecdsa-00.txt Pages : 6 Date : 2009-07-06 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-ecdsa-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 aggravationjfh5@itayamamedico.com Tue Jul 7 10:19:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D7B28C4D3; Tue, 7 Jul 2009 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.171 X-Spam-Level: X-Spam-Status: No, score=-56.171 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR=2.426, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, SUBJECT_DIET=1.466, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M6xf0xh+zeR; Tue, 7 Jul 2009 10:19:28 -0700 (PDT) Received: from c-69-142-60-24.hsd1.nj.comcast.net (c-69-142-60-24.hsd1.nj.comcast.net [69.142.60.24]) by core3.amsl.com (Postfix) with ESMTP id 5C6F828C1A0; Tue, 7 Jul 2009 10:19:27 -0700 (PDT) Date: Tue, 7 Jul 2009 13:19:33 -0500 From: action@ietf.org Subject: Lose weight fast with the world's #1 acai berry Free Trial To: Message-ID: <000d01c9ff27$18351830$6400a8c0@aggravationjfh5> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Get this miracle berry working for you today . Start your free trial now ! Click promptly http://aihbkabo.cn best regards Rogers Dickens From owner-namedroppers@ops.ietf.org Tue Jul 7 10:49:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C5D3A6A55; Tue, 7 Jul 2009 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.798 X-Spam-Level: *** X-Spam-Status: No, score=3.798 tagged_above=-999 required=5 tests=[AWL=1.697, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGLhVLgquFKU; Tue, 7 Jul 2009 10:49:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FE2D28C4C0; Tue, 7 Jul 2009 10:49:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOEhv-000E6B-TT for namedroppers-data0@psg.com; Tue, 07 Jul 2009 17:43:55 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOEhk-000E4z-A2 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 17:43:50 +0000 Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MOEhY-0007mY-Ru; Tue, 07 Jul 2009 18:43:32 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOEhT-00031L-Ri; Tue, 07 Jul 2009 18:43:27 +0100 Message-ID: <81CBF748AE054E5A84E13D23F2D25ECE@localhost> From: "George Barwood" To: "Edward Lewis" Cc: "IETF DNSEXT WG" , "Michael Graff" References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Tue, 7 Jul 2009 18:43:22 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Edward Lewis" To: "George Barwood" Cc: "IETF DNSEXT WG" ; "Michael Graff" Sent: Tuesday, July 07, 2009 2:17 PM Subject: Re: [dnsext] Name server agility with DNSSEC > At 23:36 +0100 7/6/09, George Barwood wrote: >>----- Original Message ----- >>From: "Michael Graff" > >>> Every time I see someone propose implementing TCP using UDP, I worry. >> >>Well I don't think that is what is proposed. > > Pretty much (replacing UDP with TCP) is what you proposed, once you get > through all of the error cases it'll be much like TCP. I've seen this > suggestion over 20 years of time, it's a fool's errand. Err.. did you read the proposal? ( EDNS Page Option to handle large responses, http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html ) It's nothing like TCP, the server has no state ( that's important, it makes it simple and cannot consume server resources ). There is the complication that the server is required to maintain a zone or more specific RRset version. But that's the only complication, and it solves many problems at one go: (1) TCP fallback is never required. (2) IP fragmentation ( which often doesn't work and has security and performance problems ) is avoided. (3) Middleboxes that stop DNS packets > 512 bytes are catered for. TCP fallback will I think make DNSSEC horribly insecure/unreliable when people start fetching DNSKEY RRsets in earnest. What's especially nasty is the modal behavior during KSK rollover, as the ethernet MTU is exceeded. Is no-one else concerned about this? I think Paul Vixie is looking at an alternative to TCP, but if it has server state, I'm doubtful whether it is a good way forward. If experts think it's not a problem, and can explain why, then I will accept that... But there seems to be a spirit of resignation, "it's not going to work and no one cares". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 11:59:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B698228C4CE; Tue, 7 Jul 2009 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.769 X-Spam-Level: *** X-Spam-Status: No, score=3.769 tagged_above=-999 required=5 tests=[AWL=1.668, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrQztKrd6BHr; Tue, 7 Jul 2009 11:59:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6973E28C4F9; Tue, 7 Jul 2009 11:59:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOFmh-000KrH-H2 for namedroppers-data0@psg.com; Tue, 07 Jul 2009 18:52:55 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOFmJ-000Koq-0y for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 18:52:46 +0000 Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MOFm7-0003s9-Ec; Tue, 07 Jul 2009 19:52:19 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOFm5-0006fR-57; Tue, 07 Jul 2009 19:52:17 +0100 Message-ID: <0DD5469CCC3A42EDB331D494A177AA51@localhost> From: "George Barwood" To: "Rose, Scott W." , References: Subject: Re: [dnsext] -03 version of algo-signal posted Date: Tue, 7 Jul 2009 19:52:16 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: You don't discuss whether DNSKEY RRsets should be pruned to match the client preference. Are servers allowed to do this? It would mean that the server would need to have signatures for different variations of the DNSKEY RRset, but that's not an obvious problem ( except that unusual queries for ANY or RRSIG could yield very long responses ). In section 3.1, "The only exception is for validating stub resolvers..." doesn't make sense, because it's not an exception to the previously stated rule, which concerns non-validating resolvers. "Caches MUST NOT set the AU option on any outgoing query from the cache when performing recursion on behalf of a stub client." Does this not depend on local policy, and the service offered by the cache? For example the cache may know that there are no validating stubs to be served. Also, the cache could track the algorithms that an RRset has been queried for, and send a further request to if another client requests a different algorithm. Why exclude this possibility? "In these cases a client might be able to detect an attack if the target zone has a DS RR in its delegating parent with the desired algorithm." Well now, does this work or doesn't it? I think the natural RRset to look at is the DNSKEY RRset, not the DS, which is merely the means of authenticating the DNSKEY RRset ( the parent zone may support a different set of algorithms ). I don't know whether the standard already requires that all algorithms in the DNSKEY RRset must be supported ( in the sense that RRSIGs must be issued ). I think that must be the case, but if not, that should be an extra condition on servers that support algo-signal, and clients must check that the expected RRSIGs are sent, and presumably fail if they are not sent. George ----- Original Message ----- From: "Rose, Scott W." To: Sent: Tuesday, July 07, 2009 3:42 PM Subject: [dnsext] -03 version of algo-signal posted "Official" -03 version of algo-signal posted: http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.txt This is different that the working version Steve sent to the list recently. It goes back to the original (-00) version in that the algorithms are a list in the OPT RR, not a single value with assumptions. Please refer to this version for future discussions. Scott =================================== Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 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: -- to unsubscribe send a message to namedroppers-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 Jul 7 12:10:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC6028C542; Tue, 7 Jul 2009 12:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.74 X-Spam-Level: *** X-Spam-Status: No, score=3.74 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rS4HOpE5U89; Tue, 7 Jul 2009 12:10:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0C1128C558; Tue, 7 Jul 2009 12:09:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOFys-000M7W-CB for namedroppers-data0@psg.com; Tue, 07 Jul 2009 19:05:30 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOFyh-000M6C-9e for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 19:05:24 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MOFyX-0002Rp-G3; Tue, 07 Jul 2009 20:05:09 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOFyW-0003eD-TA; Tue, 07 Jul 2009 20:05:08 +0100 Message-ID: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> From: "George Barwood" To: "Alex Bligh" , "Rose, Scott W." , Cc: "Alex Bligh" References: Subject: Re: [dnsext] -03 version of algo-signal posted Date: Tue, 7 Jul 2009 20:05:07 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Alex Bligh" To: "Rose, Scott W." ; Cc: "Alex Bligh" Sent: Tuesday, July 07, 2009 4:17 PM Subject: Re: [dnsext] -03 version of algo-signal posted > > > --On 7 July 2009 10:42:54 -0400 "Rose, Scott W." > wrote: > >> It goes back to the original (-00) version in that the algorithms are a >> list in the OPT RR, not a single value with assumptions. > > Why have ALG codes as a list of octets in descending order, rather > than (as Ray Bellis suggested) a length field plus a bitfield of up > to 252 bits (with bits beyond the supplied bitfield to be treated > as zero)? It would appear to me that this will in general > be shorter. I think that's because the normal use is a single algorithm. The client ( I think ) knows which algorithms the server supports. When fetching the DNSKEY RRset, it's determined by the parent DS records, otherwise it's determined by the DNSKEY RRset itself. So the client will normally just choose the single algorithm it wants, unless it wants to check multiple algorithms, which is probably overly paranoid. I cannot imagine a client wanting to check more than 2 algorithms. -- to unsubscribe send a message to namedroppers-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 Jul 7 12:14:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DA23A69FC; Tue, 7 Jul 2009 12:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N8U30C0qoBH; Tue, 7 Jul 2009 12:14:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 043833A69B4; Tue, 7 Jul 2009 12:14:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOG54-000MjC-0Q for namedroppers-data0@psg.com; Tue, 07 Jul 2009 19:11:54 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOG4t-000MiR-5y for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 19:11:48 +0000 Received: from [10.47.9.158] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 63F58C2DA3; Tue, 7 Jul 2009 20:11:39 +0100 (BST) Date: Tue, 07 Jul 2009 20:12:05 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , "Rose, Scott W." , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] -03 version of algo-signal posted Message-ID: <70926BEF34A83F26B91B71A7@nimrod.local> In-Reply-To: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> References: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 7 July 2009 20:05:07 +0100 George Barwood wrote: > I think that's because the normal use is a single algorithm. > The client ( I think ) knows which algorithms the server > supports. When fetching the DNSKEY RRset, it's determined > by the parent DS records, otherwise it's determined by the > DNSKEY RRset itself. A single octet for length plus a single octet for one algorithm is the same length as a single octet for length plus a bitfield covering the first 8 (i.e. all currently defined) algorithms. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 12:15:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FE728C53E; Tue, 7 Jul 2009 12:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.914 X-Spam-Level: X-Spam-Status: No, score=-3.914 tagged_above=-999 required=5 tests=[AWL=0.523, 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 rnPMH1IQ46Ek; Tue, 7 Jul 2009 12:15:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D501B28C525; Tue, 7 Jul 2009 12:15:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOG5y-000MnW-CE for namedroppers-data0@psg.com; Tue, 07 Jul 2009 19:12:50 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOG5k-000MmE-Jj for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 19:12:44 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id E89CC327A5A; Tue, 7 Jul 2009 19:12:35 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id DF891327A3F; Tue, 7 Jul 2009 19:12:34 +0000 (UTC) Message-ID: <4A539E22.20404@isc.org> Date: Tue, 07 Jul 2009 14:12:34 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: George Barwood CC: Edward Lewis , IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> In-Reply-To: <81CBF748AE054E5A84E13D23F2D25ECE@localhost> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > It's nothing like TCP, the server has no state ( that's important, it makes > it simple and cannot consume server resources ). There is the complication > that the server is required to maintain a zone or more specific RRset > version. But that's the only complication, and it solves many problems at > one go: > (1) TCP fallback is never required. A common belief is that TCP fallback is a very bad thing. And yet there are web servers which handle multi-thousands of TCP connections/sec and don't fall down flat. The fact that DNS servers today are where web servers were 10 years ago is not really a valid argument against using TCP. > (2) IP fragmentation ( which often doesn't work and has security and > performance problems ) is avoided. I don't buy the argument that fragmentation is broken, only that people choose to break it. Fragmentation is not in and of itself evil, and while there have been many fragmentation attacks, the mitigation methods in place today largely make them ineffective. Fragmentation being blocked is a major problem, but once again, breaking that is a choice. > (3) Middleboxes that stop DNS packets > 512 bytes are catered for. By letting them remain broken. > Is no-one else concerned about this? I think Paul Vixie is looking at an > alternative to TCP, but if it has server state, I'm doubtful whether it is a > good way forward. If a middleware box is capturing UDP port 53, why do we think they will let something not-TCP and not-UDP through at all? Wouldn't running DNS on port 54 as well as 53 "fix" this problem just as effectively, if the goal is to prevent middleware boxes from mangling? After all, both solutions (your UDP-page option and running on a differen port) require both ends of a conversation to change protocols, and the port one is actually easier in most cases: just treat port 54 as another server. That is, 10.1.1.2:53 and 10.1.1.99:53 are treated no differently than 10.1.1.2:53 and 10.1.1.2:54 - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpTniIACgkQ+NNi0s9NRJ30ugCeNmLpGZPG9PMKaBaqJpQw8jcp TRgAnjNbE/FJVPNerq26NhpOEq0XDlMx =HYsP -----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 Jul 7 14:03:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18F83A683B; Tue, 7 Jul 2009 14:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+vFqYv0To95; Tue, 7 Jul 2009 14:03:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A013528C535; Tue, 7 Jul 2009 14:03:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOHkN-0004ze-Bz for namedroppers-data0@psg.com; Tue, 07 Jul 2009 20:58:39 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOHkB-0004yM-JN for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 20:58:33 +0000 Received: (qmail 21293 invoked from network); 7 Jul 2009 22:38:55 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 7 Jul 2009 22:38:55 -0000 Message-ID: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> Date: Wed, 08 Jul 2009 05:57:33 +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: ondrej.sury@nic.cz CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) 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: Ondrej Sury wrote: First of all, I recommend you not to use ISO 8859 specific characters for your name, because they are not internationally available including, but not limited to, Japanese environment. If you want to be internationalized, stick to characters of ISO 646 IRV or ASCII. Or, can I expect you recognize and input formal representation of my name, which is in Chinese characters of JIS X 0201? I have no input method to input non-ASCII ISO8859 characters. So called "internationalized DNS" is NOT international at all and is meaningful only assuming some local characters. > Hi everybody, > this little draft is an outcome of our little discussion with Shane about > allowing slave server to refuse fallback to AXFR or maybe better: to allow > more fine-grained control whether AXFR is provided/asked and > accepted/refused. F.e. you can try IXFR-ONLY on all masters and only after > it fails on all of them, you will do AXFR. There is little benefit for small > zone, but great benefit for large zones (with DNSSEC). > > Shane did a great work on I-D and most information is said in the > introduction. Quite interesting topic and I appreciate that the ID is concise. > For example, master NS1 may have serials 1, 2, and 3 for a zone, and > master NS2 may have serials 1 and 3. A slave that is at serial 2 Can't the problem better solved operationally by configuring masters always request IXFR and never answer to other masters with condensation of RFC1995: An IXFR server may optionally condense multiple difference sequences into a single difference sequence, thus, dropping information on intermediate versions. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 14:12:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC20B3A682B; Tue, 7 Jul 2009 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6TtTYBPY7Hf; Tue, 7 Jul 2009 14:12:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1BD23A67D9; Tue, 7 Jul 2009 14:12:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOHuc-0005uK-RX for namedroppers-data0@psg.com; Tue, 07 Jul 2009 21:09:14 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOHuR-0005tB-H8 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 21:09:08 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 09C0AA859A for ; Tue, 7 Jul 2009 21:09:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: [dnsext] fragmentation considered harmful In-Reply-To: Your message of "Tue, 07 Jul 2009 14:12:34 EST." <4A539E22.20404@isc.org> References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 07 Jul 2009 21:09:03 +0000 Message-ID: <47013.1247000943@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 07 Jul 2009 14:12:34 -0500 > From: Michael Graff > ... > I don't buy the argument that fragmentation is broken, only that people > choose to break it. Fragmentation is not in and of itself evil, and > while there have been many fragmentation attacks, the mitigation methods > in place today largely make them ineffective. Fragmentation being > blocked is a major problem, but once again, breaking that is a choice. > ... first, see . second, the choice to break fragmentation is almost never a conscious one since the ill effects are almost never immediate and almost never local. so, fixing fragmentation is the ultimate "pushing on a rope" exercise. -- to unsubscribe send a message to namedroppers-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 Jul 7 14:20:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386453A694A; Tue, 7 Jul 2009 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDsvh86PsJjA; Tue, 7 Jul 2009 14:20:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AFFA3A6A18; Tue, 7 Jul 2009 14:18:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOI0u-0006SI-P7 for namedroppers-data0@psg.com; Tue, 07 Jul 2009 21:15:44 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOI0f-0006Qs-Vq for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 21:15:38 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2D31E3A68A1; Tue, 7 Jul 2009 14:15:02 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Cc: ogud@ogud.com, ajs@shinkuro.com, namedroppers@ops.ietf.org Subject: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) reply-to: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090707211502.2D31E3A68A1@core3.amsl.com> Date: Tue, 7 Jul 2009 14:15:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A modified charter has been submitted for the DNS Extensions (dnsext) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 14, 2009. DNS Extensions Working group (dnsext) ---------------------------------------- Last Modified: 2009-06-24 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Andrew Sullivan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Examining transport protocols possibly adding new ones. Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Milestones: Jul 2009 TSIG/MD5 Obsoleting to IESG. Jul 2009 RSA/SHA256 to IESG. Aug 2009 AXFR Clarify to IESG. Sep 2009 EDNS0 Ping Option advanced to IESG Oct 2009 Resolver side Forgery Resilience advanced to IESG Oct 2009 DNSSEC Errata document to IESG Nov 2009 GOST DNSKEY and DS support advanced to IESG Dec 2009 EDNS0-bis update advanced to IESG Feb 2010 DNS existing transport protocol recommendations/clarifications to IESG Jun 2010 DNS transport protocol specification -- to unsubscribe send a message to namedroppers-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 Jul 7 14:32:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75EA28C52E; Tue, 7 Jul 2009 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[AWL=0.486, 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 ECuKNOTJTLqC; Tue, 7 Jul 2009 14:32:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AACCA3A68C8; Tue, 7 Jul 2009 14:32:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOIBh-0007Uk-HU for namedroppers-data0@psg.com; Tue, 07 Jul 2009 21:26:53 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOIBS-0007TO-A7 for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 21:26:47 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id B3736327A71; Tue, 7 Jul 2009 21:26:37 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id D64FF327A5C; Tue, 7 Jul 2009 21:26:36 +0000 (UTC) Message-ID: <4A53BD8C.7070004@isc.org> Date: Tue, 07 Jul 2009 16:26:36 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Paul Vixie CC: IETF DNSEXT WG Subject: Re: [dnsext] fragmentation considered harmful References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> In-Reply-To: <47013.1247000943@nsa.vix.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: >> Date: Tue, 07 Jul 2009 14:12:34 -0500 >> From: Michael Graff >> ... >> I don't buy the argument that fragmentation is broken, only that people >> choose to break it. Fragmentation is not in and of itself evil, and >> while there have been many fragmentation attacks, the mitigation methods >> in place today largely make them ineffective. Fragmentation being >> blocked is a major problem, but once again, breaking that is a choice. >> ... > > first, see . Interesting read, even if 14+ years old now. > second, the choice to break fragmentation is almost never a conscious one > since the ill effects are almost never immediate and almost never local. It seems to me that the most common cause of brokenness is either in one of three cases. Please correct me if I'm wrong. (1) It is accidental, in that there is a device that is broken very near to the end user. These will be fixed as support calls increase. A list of things that are broken for DNSSEC and published on a web site where search engines can find will help here greatly. People will see "this device breaks DNSSEC, and this is bad because you'll need to buy another in 5 years if you buy this thing now" and buy something else. If not, they'll buy a new one in 5 years. (2) It is purposeful, in that it is very intentionally broken. This is a captured environment, like inside a hotel. Whatever we do, people who intentionally break DNS to ensure they are the only ones queried will continue to do so, since not doing this means things get, at best, more difficult: people get odd timeouts when they have not clicked "I'll pay $12/day" yet, or the web sites themselves need to be what is captured, which is harder because they saw DNS as a choke-point. It is not an advantage that they can no longer muck with DNS, but it is an advantage to ensure an end user cannot bypass their mucking. (3) A restricted environment, like inside a corporate firewall or in an ISP that demands you use THEIR services. DNSSEC needs adoption for this to change, but it will change. Catch 22, perhaps, but even then, the answer is available to DNSSEC users: allow fragments only to a recursive resolver, not to the whole company. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpTvYwACgkQ+NNi0s9NRJ1xMwCgjs9fEbuUuBOvRL3vL3nPQ4FU 03AAnijsI1gItxYFosOl60B6y++CvQoG =8p4n -----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 Jul 7 15:02:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3166328C512; Tue, 7 Jul 2009 15:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pef3B11W8oy6; Tue, 7 Jul 2009 15:02:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E35C228C4DC; Tue, 7 Jul 2009 15:02:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOIem-0009wT-5p for namedroppers-data0@psg.com; Tue, 07 Jul 2009 21:56:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOIeV-0009ul-5x for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 21:56:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BD2B0A85AC for ; Tue, 7 Jul 2009 21:56:38 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] fragmentation considered harmful In-Reply-To: Your message of "Tue, 07 Jul 2009 16:26:36 EST." <4A53BD8C.7070004@isc.org> References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> <4A53BD8C.7070004@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 07 Jul 2009 21:56:38 +0000 Message-ID: <49207.1247003798@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 07 Jul 2009 16:26:36 -0500 > From: Michael Graff > > > first, see . > > Interesting read, even if 14+ years old now. i was an assistant to the authors and though i did not work on this with them i participated in some lunchtime discussions about it. the result of this work was PMTUD, which as we now know, still does not fix the problem. > > second, the choice to break fragmentation is almost never a conscious one > > since the ill effects are almost never immediate and almost never local. > > It seems to me that the most common cause of brokenness is either in one > of three cases. Please correct me if I'm wrong. > > (1) It is accidental, in that there is a device that is broken very > near to the end user. These will be fixed as support calls increase. ... the support calls will almost never reach the right destination, and in the rare case where they do, the response will be "but it's always worked this way before, you must be trying something new, you should downgrade to a working version of your software." the successful way to add a new app to an internet containing OPN's (other people's networks) is what "bittorrent" did-- leverage the things that aren't blocked and/or can't be blocked. i'm pretty sure DNS will end up as an XML profile carried over HTTPS some day. > (2) It is purposeful, in that it is very intentionally broken. This is > a captured environment, like inside a hotel. ... in this sense, hotels aren't part of "the internet", or if they are, then the internet is no longer a "network of networks" but rather a "network of internet access clouds". there are some hard choices to be made by the IAB and by each of us as to whether we want to try to deliver new applications into such networks, or whether we think that the "real internet" is enough of a playground/marketplace for our ideas/products. > (3) A restricted environment, like inside a corporate firewall or in an > ISP that demands you use THEIR services. DNSSEC needs adoption for this > to change, but it will change. Catch 22, perhaps, but even then, the > answer is available to DNSSEC users: allow fragments only to a recursive > resolver, not to the whole company. even in a small 35-person technology company it's often hard to get changes made to the corporate firewall without a lot of meetings and debates. now i'm trying to imagine doing this in a fortune 500 company, and i just can't. consider this: ipfw2, which is a mature and stable and reliable host based firewall found on freebsd and used extensively, does not have any way to tie fragments together by their so that the non-leading fragments (which lack UDP headers and therefore a UDP port number) can share fate (allow or reject) with the leading fragment. this means every ipfw2 configuration in the universe that has a rule like "add allow udp from any to any 53" or similar, breaks fragmentation. and because DNS didn't generate fragments for its first few decades, these configurations are considered correct by their operators. and ipfw2 is far from the only firewall with those types of limitations. if a firewall allows fate-binding among then it's a matter of convincing the firewall operator to turn this on. hopefully they'll agree and even more hopefully they will test it before declaring victory, but more likely they'll say "not my problem, use TCP/53, that works fine" or if they make a change it'll fsck things up and make that corner of the internet less stable for the period of time it takes to operationalize the new policy. and then some clown will get back from vacation or restore from a backup tape and revert to the previous behaviour. lather, rinse, repeat. if a firewall doesn't allow fate-binding among then the operator will have to either upgrade, or switch to new firewall technology, or just allow all fragments. upgrades or technology switches will require investment in training and testing, which are very difficult to budget when the underlying problem (EDNS doesn't work) is so terribly obscure and only affects potential applications (some of our users would like DNSSEC to work some day when DNSSEC is deployed). allowing all fragments requires either that there be no limit as to what internal hosts can receive/transmit same (which could become a back door for bad guys to use) or that the recursive name server addresses be hardcoded (which leads to trouble when more are added or when existing ones are renumbered.) the systemic inertia of "fragmentation not working" is extraordinarily high compared to any immediate benefit of "EDNS is working". i did the math and found that EDNS's dependence upon fragmentation was one of my great errors in judgement. had we used SCTP instead, we'd be about as far along as we are now, but with shorter to go in order to get finished. -- to unsubscribe send a message to namedroppers-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 Jul 7 15:19:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4123A6EEB; Tue, 7 Jul 2009 15:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[AWL=0.454, 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 v+x5q1ABlL72; Tue, 7 Jul 2009 15:19:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31F593A6EC3; Tue, 7 Jul 2009 15:19:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOIwm-000BLI-Mc for namedroppers-data0@psg.com; Tue, 07 Jul 2009 22:15:32 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOIwa-000BK7-VL for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 22:15:26 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 3AB77327A6D; Tue, 7 Jul 2009 22:15:20 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 524DA327A5D; Tue, 7 Jul 2009 22:15:19 +0000 (UTC) Message-ID: <4A53C8F6.50403@isc.org> Date: Tue, 07 Jul 2009 17:15:18 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Paul Vixie CC: IETF DNSEXT WG Subject: Re: [dnsext] fragmentation considered harmful References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> <4A53BD8C.7070004@isc.org> <49207.1247003798@nsa.vix.com> In-Reply-To: <49207.1247003798@nsa.vix.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I suppose a lot of this is assumptions. I assume that, within a corporate cloud, DNSSEC may never be used by end users, or the uptake will be very, very small. If I am wrong here, fragments will become important to deal with. If they cannot be, internal pressures pushing for DNSSEC will push the fragment issue. I assume that, within a corporate cloud, a corporate resolver may have fragments allowed to it, and from it to end users. However, the world to end users is not likely to change in all but the most enlightened companies. DNSSEC will work, using smart or dumb stub resolvers, in this case. I also assume that since DNSSEC is in the press, fortune 500 companies that never even knew what DNS was other than the lawyers had to once in a while ask for this strange thing called a "domain" to be registered to protect some trademark or other, these same companies are suddenly taking notice that things are different. At least their IT departments are. Of all the companies out there which should be screaming most loudly over DNSSEC and fragmentation, the US Government seems oddly quiet on the issue. I'd think if anyone meets my definition of overly paranoid, they would. How are they adapting to a world where fragments are a matter of course? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpTyPYACgkQ+NNi0s9NRJ1BRACePq3lKkaXZkVtU3N0ngNykubS WOAAnRDVw4xdsudS85qglqQHjKZEjiyw =8XLQ -----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 Jul 7 15:29:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B206228C525; Tue, 7 Jul 2009 15:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.712 X-Spam-Level: *** X-Spam-Status: No, score=3.712 tagged_above=-999 required=5 tests=[AWL=1.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFfuK-DfdNjA; Tue, 7 Jul 2009 15:29:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E6F33A68B4; Tue, 7 Jul 2009 15:29:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOJ7F-000C9C-LD for namedroppers-data0@psg.com; Tue, 07 Jul 2009 22:26:21 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOJ6z-000C7C-Lg for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 22:26:15 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1MOJ6p-0002zn-Gb; Tue, 07 Jul 2009 23:25:55 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOJ6o-0005kJ-SX; Tue, 07 Jul 2009 23:25:54 +0100 Message-ID: From: "George Barwood" To: "Michael Graff" Cc: "Edward Lewis" , "IETF DNSEXT WG" References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Tue, 7 Jul 2009 23:25:53 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Michael, I admit I'm mainly going on instinct here. But isn't the conservative, safe option to rely on existing transport? Which is 512 byte UDP packets, and small amplification factors. Or at least define a standard way of using the existing transport, in case it is needed. I'm not sure which attack concerns me most, but I think it would be a DDoS attack against TCP that requests a large response after establishing the connection and then either stops sending ACKS or fiddles with the congestion protocol, leading to huge buffering requirements on the servers. Well, something roughly like that. The other might be amplification attacks, where large UDP packets get directed towards the victims computer or network. These seem bad enough to me, but there are probably much worse, things are usually worse than you ever imagined. My instinct says that changing the lower level traffic pattern is quite risky, and I'm against taking risks with DNS infrastructure. It's too easy to think we know what we are doing, when really we don't. Maybe I'm just crazy though... but after all hardening DNS is now an active item for the working group, so I don't feel too embarassed bringing it up. George ----- Original Message ----- From: "Michael Graff" To: "George Barwood" Cc: "Edward Lewis" ; "IETF DNSEXT WG" Sent: Tuesday, July 07, 2009 8:12 PM Subject: Re: [dnsext] Name server agility with DNSSEC > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > George Barwood wrote: > >> It's nothing like TCP, the server has no state ( that's important, it >> makes >> it simple and cannot consume server resources ). There is the >> complication >> that the server is required to maintain a zone or more specific RRset >> version. But that's the only complication, and it solves many problems at >> one go: >> (1) TCP fallback is never required. > > A common belief is that TCP fallback is a very bad thing. And yet there > are web servers which handle multi-thousands of TCP connections/sec and > don't fall down flat. > > The fact that DNS servers today are where web servers were 10 years ago > is not really a valid argument against using TCP. > >> (2) IP fragmentation ( which often doesn't work and has security and >> performance problems ) is avoided. > > I don't buy the argument that fragmentation is broken, only that people > choose to break it. Fragmentation is not in and of itself evil, and > while there have been many fragmentation attacks, the mitigation methods > in place today largely make them ineffective. Fragmentation being > blocked is a major problem, but once again, breaking that is a choice. > >> (3) Middleboxes that stop DNS packets > 512 bytes are catered for. > > By letting them remain broken. > >> Is no-one else concerned about this? I think Paul Vixie is looking at an >> alternative to TCP, but if it has server state, I'm doubtful whether it >> is a >> good way forward. > > If a middleware box is capturing UDP port 53, why do we think they will > let something not-TCP and not-UDP through at all? > > Wouldn't running DNS on port 54 as well as 53 "fix" this problem just as > effectively, if the goal is to prevent middleware boxes from mangling? > After all, both solutions (your UDP-page option and running on a > differen port) require both ends of a conversation to change protocols, > and the port one is actually easier in most cases: just treat port 54 > as another server. That is, 10.1.1.2:53 and 10.1.1.99:53 are treated no > differently than 10.1.1.2:53 and 10.1.1.2:54 > > - --Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpTniIACgkQ+NNi0s9NRJ30ugCeNmLpGZPG9PMKaBaqJpQw8jcp > TRgAnjNbE/FJVPNerq26NhpOEq0XDlMx > =HYsP > -----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 Jul 7 15:43:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C972D3A68B4; Tue, 7 Jul 2009 15:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, UNPARSEABLE_RELAY=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 y6lSAsTLmbTx; Tue, 7 Jul 2009 15:43:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF4303A67FC; Tue, 7 Jul 2009 15:43:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOJJd-000D1g-Qe for namedroppers-data0@psg.com; Tue, 07 Jul 2009 22:39:09 +0000 Received: from [66.113.102.10] (helo=diana.db.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOJJL-000D0Y-8m for namedroppers@ops.ietf.org; Tue, 07 Jul 2009 22:39:04 +0000 Received: from diana.db.net ([66.113.102.10] helo=localhost ident=mailnull) by diana.db.net with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOJJK-000Ase-CR; Tue, 07 Jul 2009 16:38:50 -0600 Received: from diana.db.net ([127.0.0.1] helo=localhost) (envelope-from ) id 1MOJJE-0000gi-Rp; Tue, 07 Jul 2009 18:38:45 -0400 Date: Tue, 7 Jul 2009 18:38:42 -0400 From: Diane Bruce To: Michael Graff Cc: Paul Vixie , IETF DNSEXT WG Subject: Re: [dnsext] fragmentation considered harmful Message-ID: <20090707223842.GA2636@night.db.net> References: <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> <4A53BD8C.7070004@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A53BD8C.7070004@isc.org> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 04:26:36PM -0500, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Vixie wrote: > >> Date: Tue, 07 Jul 2009 14:12:34 -0500 > >> From: Michael Graff ... > > first, see . > > Interesting read, even if 14+ years old now. You might also read: http://www.ietf.org/proceedings/06jul/slides/tsvarea-1.pdf 'fragmentation considered very harmful' 2006 Though now way off topic, Fernando Gont is also worth reading. http://www.gont.com.ar/ - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db -- to unsubscribe send a message to namedroppers-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 Jul 7 18:59:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D4E3A68FA; Tue, 7 Jul 2009 18:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSe2Fcyl3yOS; Tue, 7 Jul 2009 18:59:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 654D53A69AD; Tue, 7 Jul 2009 18:59:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOMMS-0000cK-Ub for namedroppers-data0@psg.com; Wed, 08 Jul 2009 01:54:16 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOMMH-0000b7-J2 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 01:54:11 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 6E352E6071; Wed, 8 Jul 2009 01:54:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n681rxNQ029157; Wed, 8 Jul 2009 11:54:01 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907080154.n681rxNQ029157@drugs.dv.isc.org> To: "George Barwood" Cc: "Michael Graff" , "Edward Lewis" , "IETF DNSEXT WG" From: Mark Andrews References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC In-reply-to: Your message of "Tue, 07 Jul 2009 23:25:53 +0100." Date: Wed, 08 Jul 2009 11:53:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "George Barwood" write s: > Michael, > > I admit I'm mainly going on instinct here. > > But isn't the conservative, safe option to rely on existing transport? > > Which is 512 byte UDP packets, and small amplification factors. > > Or at least define a standard way of using the existing transport, in case > it is needed. We did define a standard way (EDNS) to use the existing transport (UDP). > I'm not sure which attack concerns me most, but I think it would be a DDoS > attack against TCP that requests a large response after establishing the > connection and then either stops sending ACKS or fiddles with the congestion > protocol, leading to huge buffering requirements on the servers. Well, > something roughly like that. Breaking up UDP responses at the application layer doesn't address that. A DoS attack is a DoS attack and will happen regardless of what we do at the UDP layer. > The other might be amplification attacks, where large UDP packets get > directed towards the victims computer or network. Breaking up the UDP response at the application layer doesn't make this better. It makes this worse as you have additional overhead. > These seem bad enough to me, but there are probably much worse, things are > usually worse than you ever imagined. > > My instinct says that changing the lower level traffic pattern is quite > risky, and I'm against taking risks with DNS infrastructure. It's too easy > to think we know what we are doing, when really we don't. The low level traffic pattern has constantly been changing since the DNS was created. Response sizes have slowly been increasing. We saw that over 10 years ago and EDNS was the response to that. EDNS actually works very well. It will continue to work well as long as we educate vendors when we see that they have a defective product. > Maybe I'm just crazy though... but after all hardening DNS is now an active > item for the working group, so I don't feel too embarassed bringing it up. Breaking up the UDP response at the application layer doesn't doesn't harden the DNS. > George Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 23:10:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A253A6B62; Tue, 7 Jul 2009 23:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK+gyu530wIw; Tue, 7 Jul 2009 23:10:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8DE13A69B9; Tue, 7 Jul 2009 23:10:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOQH5-000HXb-GI for namedroppers-data0@psg.com; Wed, 08 Jul 2009 06:04:59 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOQGu-000HWK-0p for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 06:04:53 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F0C6BE601C; Wed, 8 Jul 2009 06:04:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6864evQ032580; Wed, 8 Jul 2009 16:04:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907080604.n6864evQ032580@drugs.dv.isc.org> To: Paul Vixie Cc: IETF DNSEXT WG From: Mark Andrews References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> <4A53BD8C.7070004@isc.org> <49207.1247003798@nsa.vix.com> Subject: Re: [dnsext] fragmentation considered harmful In-reply-to: Your message of "Tue, 07 Jul 2009 21:56:38 GMT." <49207.1247003798@nsa.vix.com> Date: Wed, 08 Jul 2009 16:04:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <49207.1247003798@nsa.vix.com>, Paul Vixie writes: > consider this: > > ipfw2, which is a mature and stable and reliable host based firewall found > on freebsd and used extensively, does not have any way to tie fragments > together by their so that the non-leading fragments (which > lack UDP headers and therefore a UDP port number) can share fate (allow or > reject) with the leading fragment. Which is easy enough to do if the firewall re-assembles the packet or at least holds the other fragments until the first fragment is processed. The NAT code does half of this already by tracking + outstanding fragment windows. It just doesn't look in the re-assembly queue for out of order fragments. If you want multiple paths to work you don't re-assemble and let all fragments through. > this means every ipfw2 configuration in > the universe that has a rule like "add allow udp from any to any 53" or > similar, breaks fragmentation. and because DNS didn't generate fragments > for its first few decades, these configurations are considered correct by > their operators. and ipfw2 is far from the only firewall with those types > of limitations. The alternative is to introduce a firewall friendly fragmentation method. Add a IP option which says you understand the new method. This option get added to the reply packet along with a indication to use the new method. When you fragment you wrap the resulting fragments inside another packet which holds the original upper layer headers as well as the fragment itself. This allows NATs and firewalls to make decisions w/o reassembling. When the packet reaches its final destination it is de-encapsulated and is added to the re-assembly queue. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 23:28:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FCB3A6981; Tue, 7 Jul 2009 23:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.685 X-Spam-Level: *** X-Spam-Status: No, score=3.685 tagged_above=-999 required=5 tests=[AWL=1.584, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHTqFKNAP+uy; Tue, 7 Jul 2009 23:28:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14C113A6835; Tue, 7 Jul 2009 23:28:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOQYi-000JEK-9L for namedroppers-data0@psg.com; Wed, 08 Jul 2009 06:23:12 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOQYW-000JD0-Sj for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 06:23:06 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MOQYT-0005EZ-1z; Wed, 08 Jul 2009 07:22:57 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOQYS-0005HG-GL; Wed, 08 Jul 2009 07:22:56 +0100 Message-ID: From: "George Barwood" To: "Mark Andrews" Cc: "Michael Graff" , "Edward Lewis" , "IETF DNSEXT WG" References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Wed, 8 Jul 2009 07:22:55 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Mark Andrews" To: "George Barwood" Cc: "Michael Graff" ; "Edward Lewis" ; "IETF DNSEXT WG" Sent: Wednesday, July 08, 2009 2:53 AM Subject: Re: [dnsext] Name server agility with DNSSEC > > In message , "George Barwood" > write > s: >> Michael, >> >> I admit I'm mainly going on instinct here. >> >> But isn't the conservative, safe option to rely on existing transport? >> >> Which is 512 byte UDP packets, and small amplification factors. >> >> Or at least define a standard way of using the existing transport, in >> case >> it is needed. > > We did define a standard way (EDNS) to use the existing transport > (UDP). > >> I'm not sure which attack concerns me most, but I think it would be a >> DDoS >> attack against TCP that requests a large response after establishing the >> connection and then either stops sending ACKS or fiddles with the >> congestion >> protocol, leading to huge buffering requirements on the servers. Well, >> something roughly like that. > > Breaking up UDP responses at the application layer doesn't > address that. A DoS attack is a DoS attack and will happen > regardless of what we do at the UDP layer. Breaking up the UDP response reduces/stops fragmentation. That's one effect. It also means TCP isn't required where fragmentation fails, which is very common above 1500 bytes (according to netalyzer). TCP is subject to DoS, and this is inherent to the protocol. >> The other might be amplification attacks, where large UDP packets get >> directed towards the victims computer or network. > > Breaking up the UDP response at the application layer doesn't > make this better. It makes this worse as you have additional > overhead. Huh? Currently you can send spoof UDP queries to a.ns.se and generate > 4000 byte UDP responses. With paging (my suggestion) the responses can be limited to 200 bytes, at the discretion of the server, i.e. almost no amplification, so an attacker gains little benefit. >> These seem bad enough to me, but there are probably much worse, things >> are >> usually worse than you ever imagined. >> >> My instinct says that changing the lower level traffic pattern is quite >> risky, and I'm against taking risks with DNS infrastructure. It's too >> easy >> to think we know what we are doing, when really we don't. > > The low level traffic pattern has constantly been changing > since the DNS was created. Response sizes have slowly been > increasing. We saw that over 10 years ago and EDNS was the > response to that. EDNS actually works very well. It will > continue to work well as long as we educate vendors when > we see that they have a defective product. > >> Maybe I'm just crazy though... but after all hardening DNS is now an >> active >> item for the working group, so I don't feel too embarassed bringing it >> up. > > Breaking up the UDP response at the application layer doesn't > doesn't harden the DNS. > >> George > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 7 23:49:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078753A68F1; Tue, 7 Jul 2009 23:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9YhjTxN8LEr; Tue, 7 Jul 2009 23:49:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 152183A6A65; Tue, 7 Jul 2009 23:49:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOQuy-000LBm-JP for namedroppers-data0@psg.com; Wed, 08 Jul 2009 06:46:12 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOQuk-000L9Y-O9 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 06:46:05 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id E015F327A7C for ; Wed, 8 Jul 2009 06:45:57 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 0CC98327A72 for ; Wed, 8 Jul 2009 06:45:56 +0000 (UTC) Message-ID: <4A5440A4.2050203@isc.org> Date: Wed, 08 Jul 2009 01:45:56 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 CC: IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > Breaking up the UDP response reduces/stops fragmentation. > That's one effect. > It also means TCP isn't required where fragmentation fails, which is very > common above 1500 bytes (according to netalyzer). TCP is subject to DoS, and > this is inherent to the protocol. If it doesn't stop fragmentation, then why bother? TCP is subject to DoS, but so is UDP. Servers have to maintain state on TCP, sure, but they have some control over the size of that state and the number of connections. If this were not true, we would not currently have the web. How is it that nearly every protocol which uses DNS also uses TCP, but we are so afraid of using it ourselves? > Huh? Currently you can send spoof UDP queries to a.ns.se and generate > 4000 > byte UDP responses. With paging (my suggestion) the responses can be limited > to 200 bytes, at the discretion of the server, i.e. almost no amplification, > so an attacker gains little benefit. So... if the server can send as little as 200 bytes, then I assume that state is stored on the server for when the client asks for the rest of that 4,000 byte response? Or is the reply regenerated each time? I guess I need to re-read your proposal. I, for one, don't think we need to reinvent protocols here. SCTP is perhaps a good idea since it appears to scale down to something very close to UDP if desired. Paginating a UDP response seems like a hack and is just as likely to be rejected by the very devices you are attempting to bypass, that of a broken filtering gateway. I simply fail to understand here why fallback to TCP has suddenly become so frightening. Note that for .org, even that 700x increase was still so low in the noise. I think it was less than 1000/sec? Something like 380? And that was with a TTL on SOA, negative caching, and the DNSKEY record of 0! - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpUQKQACgkQ+NNi0s9NRJ1D4gCcDq8RIGDl1qUiOoFRsnA//Bxq N8YAn06gWXEtpKE3+yfF8U/8m/bFJEHE =dqdG -----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 Jul 8 00:17:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B6428C3DC; Wed, 8 Jul 2009 00:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h65k7yiNlDiH; Wed, 8 Jul 2009 00:17:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9801728C2C3; Wed, 8 Jul 2009 00:17:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MORKY-000NSp-5k for namedroppers-data0@psg.com; Wed, 08 Jul 2009 07:12:38 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MORKJ-000NS3-IW for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 07:12:28 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 6C8F7E6070 for ; Wed, 8 Jul 2009 07:12:22 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) From: Shane Kerr To: namedroppers In-Reply-To: <20090707211502.2D31E3A68A1@core3.amsl.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> Content-Type: text/plain Organization: ISC Date: Wed, 08 Jul 2009 09:12:19 +0200 Message-Id: <1247037139.3922.19184.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: All, On Tue, 2009-07-07 at 14:15 -0700, IESG Secretary wrote: > The WG will limit itself to review of proposals for new extensions > and clarification to the DNS protocol, including DNSSEC. Adoption of > new work targeted for standards track will require changes to this > charter. Just so I'm clear, this means IXFR-ONLY is out of scope and the work needs to be done outside of DNSEXT? As would any other new DNS work except for the 5 items listed? -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 01:14:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462183A6BD5; Wed, 8 Jul 2009 01:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.659 X-Spam-Level: *** X-Spam-Status: No, score=3.659 tagged_above=-999 required=5 tests=[AWL=1.558, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3FoIXFr+ZDb; Wed, 8 Jul 2009 01:14:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01D0F3A67F4; Wed, 8 Jul 2009 01:13:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSDF-0001v5-90 for namedroppers-data0@psg.com; Wed, 08 Jul 2009 08:09:09 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSD4-0001uI-4J for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 08:09:03 +0000 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MOSCx-0002hs-AP; Wed, 08 Jul 2009 09:08:51 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOSCw-00016N-RN; Wed, 08 Jul 2009 09:08:50 +0100 Message-ID: <3482744445FC4DB9999AC42A2E96714D@localhost> From: "George Barwood" To: "Michael Graff" Cc: "IETF DNSEXT WG" References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> <4A5440A4.2050203@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Wed, 8 Jul 2009 09:08:49 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Michael Graff" > So... if the server can send as little as 200 bytes, then I assume that > state is stored on the server for when the client asks for the rest of > that 4,000 byte response? Or is the reply regenerated each time? I > guess I need to re-read your proposal. No state exists on the server, that is the point, yes. Client says: Send me the first page. Server: Here it is, bye ( end of transaction, server state returns to initial state ). Client says: Ok, send me the second page. Server: Ok, here you are. Bye. The server does have to maintain version information though, so it's not 100% magic. I haven't thought too much about the implementation details, but it's clearly doable. Some kind of clock that increments when the local database is updated, stored at some level ( maybe RRset, maybe domain, maybe zone, or just globally if updates are infrequent ). The server computes the version as it assembles the response, using the largest value in the data it references. > I, for one, don't think we need to reinvent protocols here. SCTP is > perhaps a good idea since it appears to scale down to something very > close to UDP if desired. I haven't studied SCTP closely, but it seems quite similar to TCP, so I suspect it will suffer from the same problem inherent in any connection-oriented protocol, which will always have state. > Paginating a UDP response seems like a hack > and is just as likely to be rejected by the very devices you are > attempting to bypass, that of a broken filtering gateway. I don't think there is any evidence for this, it semes unlikely. The packets are properly formatted, I doubt a gateway would be inspecting EDNS option records. > I simply fail to understand here why fallback to TCP has suddenly become > so frightening. Note that for .org, even that 700x increase was still > so low in the noise. I think it was less than 1000/sec? Something like > 380? And that was with a TTL on SOA, negative caching, and the DNSKEY > record of 0! It's not frightening until someone mounts an attack. Unless you happen to consider this possibility... Servers coping with good faith traffic is not an issue. Best wishes, George > - --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 Jul 8 01:46:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D063A6972; Wed, 8 Jul 2009 01:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.075 X-Spam-Level: X-Spam-Status: No, score=-4.075 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzS18k9j7fPS; Wed, 8 Jul 2009 01:46:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFBB93A6966; Wed, 8 Jul 2009 01:46:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSjO-0004I9-UN for namedroppers-data0@psg.com; Wed, 08 Jul 2009 08:42:22 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSjA-0004Gf-B1 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 08:42:17 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=T/p4fSnbbrwUHw26P1AK5gPEI2CYe+312vFiYCGJK/8vELAuRiFPHoDg tms8VjbWlsWwKz25UIvkF5z3K4F7Mp+HrcFZeFitFg8B1aSHsFmfZk905 QpLqxunanDgPQzB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1247042528; x=1278578528; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20-03=20version=20of=20algo-signal=20posted|Date:=20W ed,=208=20Jul=202009=2009:41:57=20+0100|Message-ID:=20|To:=20Alex=20Bligh=20 |Cc:=20namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<70926BEF34A83F26B91B71A7@nimrod.local> |References:=20=20=20<4B305D7B13A14FC484A43 E8AF55DD04F@localhost>=20<70926BEF34A83F26B91B71A7@nimrod .local>; bh=vtPL/qFJQ8wgUYQcMm++ZTFyPq+8L4X6UZTQdkkMeQs=; b=Hmwa3EsEz0KLnOjgXu1gabL3bgaT6C1PNRc9GHdhoBkHy6OAn81c0VoH ZHytHWYjYcT1gimkr+COnUNd2nbIzWAhzP9e3XoHMFGrwJyNyiMuWqyzE Vt+9i1LgLlhbISz; X-IronPort-AV: E=Sophos;i="4.42,367,1243810800"; d="scan'208";a="15517122" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 08 Jul 2009 09:42:01 +0100 In-Reply-To: <70926BEF34A83F26B91B71A7@nimrod.local> References: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> <70926BEF34A83F26B91B71A7@nimrod.local> To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] -03 version of algo-signal posted MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 8 Jul 2009 09:41:57 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/07/2009 09:42:06 AM, Serialize complete at 08/07/2009 09:42:06 AM Content-Type: multipart/alternative; boundary="=_alternative 002FC991802575ED_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 002FC991802575ED_= Content-Type: text/plain; charset="US-ASCII" > A single octet for length plus a single octet for one algorithm > is the same length as a single octet for length plus a bitfield > covering the first 8 (i.e. all currently defined) algorithms. As it happens the spec for EDNS0 options already includes a *two* byte length field. Your point still holds, though :) FWIW, with the bitmap method a client supporting everything up to and including NSEC3/SHA-1 would need a one byte bitmap, and one supporting SHA-2 would need two bytes. Ray --=_alternative 002FC991802575ED_= Content-Type: text/html; charset="US-ASCII"
> A single octet for length plus a single octet for one algorithm
> is the same length as a single octet for length plus a bitfield
> covering the first 8 (i.e. all currently defined) algorithms.

As it happens the spec for EDNS0 options already includes a *two* byte length field.  Your point still holds, though :)

FWIW, with the bitmap method a client supporting everything up to and including NSEC3/SHA-1 would need a one byte bitmap, and one supporting SHA-2 would need two bytes.

Ray
--=_alternative 002FC991802575ED_=-- -- to unsubscribe send a message to namedroppers-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 Jul 8 02:03:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A693A69C8; Wed, 8 Jul 2009 02:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.443 X-Spam-Level: X-Spam-Status: No, score=0.443 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 IzwklmyrKqT7; Wed, 8 Jul 2009 02:03:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86B393A6849; Wed, 8 Jul 2009 02:03:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSzu-00060h-Vc for namedroppers-data0@psg.com; Wed, 08 Jul 2009 08:59:26 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSzj-0005yk-Qq for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 08:59:21 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MOT30-0005Ca-Ao; Wed, 08 Jul 2009 11:02:38 +0200 Received: by bfk.de with local id 1MOSzf-0006rx-2P; Wed, 08 Jul 2009 08:59:11 +0000 To: Stephane Bortzmeyer Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> From: Florian Weimer Date: Wed, 08 Jul 2009 08:59:11 +0000 In-Reply-To: <20090706095144.GB25939@nic.fr> (Stephane Bortzmeyer's message of "Mon\, 6 Jul 2009 11\:51\:44 +0200") Message-ID: <82ocrv5z4w.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: * Stephane Bortzmeyer: > On Mon, Jul 06, 2009 at 01:15:01AM -0700, > Internet-Drafts@ietf.org wrote=20 > a message of 53 lines which said: > >> There are two kinds of TYPE for host IP address: one is A, the other >> is AAAA, which records IPv4 and IPv6 addresses respectively. This >> document defines a new TYPE, which is mainly used in queries in >> order to get both IPv4 and IPv6 addresses. > > Certainly a good idea and I applaud the effort. But I vaguely remember > there was a long time ago a project to have a query type ADDR and that > it failed, so you may research history of this project to see what was > the problem. Hmm. I don't think I got the original message, and I think I might already have replied to your message. Oh well. Would it help if there was some sort of EDNS0 flag/option which instructed the server to include an NSEC(3) record for the QNAME, to reveal which other RR types exist at that name? Which type to query first could be based on past performance. --=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 Jul 8 02:14:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0484728C441; Wed, 8 Jul 2009 02:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=0.438, 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 Mu3QZPeQU56J; Wed, 8 Jul 2009 02:14:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3666828C224; Wed, 8 Jul 2009 02:14:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTAL-0006wD-5D for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:10:13 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOT9f-0006si-Md for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:09:43 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 1B7A8327A7C; Wed, 8 Jul 2009 09:09:31 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 24AE6327A72; Wed, 8 Jul 2009 09:09:29 +0000 (UTC) Message-ID: <4A546249.5050302@isc.org> Date: Wed, 08 Jul 2009 04:09:29 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: George Barwood CC: IETF DNSEXT WG Subject: Re: [dnsext] Name server agility with DNSSEC References: <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> <4A5440A4.2050203@isc.org> <3482744445FC4DB9999AC42A2E96714D@localhost> In-Reply-To: <3482744445FC4DB9999AC42A2E96714D@localhost> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: You say this... > No state exists on the server, that is the point, yes. And then you say this: > The server does have to maintain version information though, so it's not > 100% magic. That, to me, is state. How long would it maintain version information for? How is this sufficiently different than maintaining TCP state for a short time? >> Paginating a UDP response seems like a hack >> and is just as likely to be rejected by the very devices you are >> attempting to bypass, that of a broken filtering gateway. > > I don't think there is any evidence for this, it semes unlikely. > The packets are properly formatted, I doubt a gateway would be inspecting > EDNS option records. I think EDNS filtering is happening on these boxes. I think that's been discussed here many times. >> I simply fail to understand here why fallback to TCP has suddenly become >> so frightening. Note that for .org, even that 700x increase was still >> ... > > It's not frightening until someone mounts an attack. > Unless you happen to consider this possibility... > Servers coping with good faith traffic is not an issue. Once again, if TCP is so weak that it is trivially attackable, how is it we have web servers, how is it I'm able to send this mail to you at all? Both use TCP, and both services are what I'd consider well-known services. I know attacks are a regular order of business on the net. I know that TCP is more load on a sever than UDP. I also know that my web server has been attacked and the universe did not end. In fact, either did my actual page loads. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpUYkkACgkQ+NNi0s9NRJ3VYgCfbg/t2VZ/WsjuBxYRreDaLnjF K14AnApAB+p5FG1l5YciP4dxaTd1p2NM =noKo -----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 Jul 8 02:18:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E0F28C496; Wed, 8 Jul 2009 02:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wld94kq29VW; Wed, 8 Jul 2009 02:18:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B82CA28C485; Wed, 8 Jul 2009 02:18:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTFo-0007wW-Ox for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:15:52 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTFd-0007vH-RQ for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:15:47 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 849FAE6071; Wed, 8 Jul 2009 09:15:40 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) From: Shane Kerr To: "W.C.A. Wijngaards" Cc: namedroppers@ops.ietf.org In-Reply-To: <4A5354C9.7010107@nlnetlabs.nl> References: <4A533F5C.5010501@nlnetlabs.nl> <1246974100.3922.15644.camel@shane-asus-laptop> <4A5354C9.7010107@nlnetlabs.nl> Content-Type: text/plain Organization: ISC Date: Wed, 08 Jul 2009 11:15:37 +0200 Message-Id: <1247044537.3922.19656.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Wouter, On Tue, 2009-07-07 at 15:59 +0200, W.C.A. Wijngaards wrote: > On 07/07/2009 03:41 PM, Shane Kerr wrote: > > I guess we can change this to SHOULD. If IXFR-ONLY breaks things then > > implementors will either add such an option, or people will stop using > > their software. If it doesn't break things (or cause extra delays, > > packets, and so on), then such a knob is not necessary after all. :) > > I think you missed yet-another option where the master could disable > IXFR-ONLY support for a particular zone. But agreed with you above. > > > I guess either of these could be changed to a MAY. Neither of these is > > required, because they are merely optimizations. > > So, all of them are not necessary. They are not needed to make > IXFR-ONLY work. Therefore I propose to delete the text about the > options entirely. I disagree. I think it is helpful to implementors if an RFC points out some options that they may want to think about, and the reasoning behind adding them. -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 02:25:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625C83A6BD5; Wed, 8 Jul 2009 02:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuUXbfmm7s47; Wed, 8 Jul 2009 02:25:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D0993A688B; Wed, 8 Jul 2009 02:25:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTLH-0008Tr-RA for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:21:31 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTL7-0008Sy-33 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:21:26 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 61977501A6C; Wed, 8 Jul 2009 10:21:19 +0100 (BST) Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Message-Id: <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> From: Jim Reid To: Florian Weimer In-Reply-To: <82ocrv5z4w.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Date: Wed, 8 Jul 2009 10:21:19 +0100 References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8 Jul 2009, at 09:59, Florian Weimer wrote: > Would it help if there was some sort of EDNS0 flag/option which > instructed the server to include an NSEC(3) record for the QNAME, to > reveal which other RR types exist at that name? No. If some client wants to get an NSEC(3) RR in a response, it should explictly ask for one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 02:25:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451AC3A6946; Wed, 8 Jul 2009 02:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.453 X-Spam-Level: X-Spam-Status: No, score=0.453 tagged_above=-999 required=5 tests=[AWL=-0.297, 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 bUr-nXuBV72U; Wed, 8 Jul 2009 02:25:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 706983A6BD5; Wed, 8 Jul 2009 02:25:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTN1-0008cx-8C for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:23:19 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTMk-0008bJ-87 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:23:13 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MOTQ2-0000sf-72; Wed, 08 Jul 2009 11:26:26 +0200 Received: by bfk.de with local id 1MOTMg-0006mf-Sr; Wed, 08 Jul 2009 09:22:58 +0000 To: Jim Reid Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> From: Florian Weimer Date: Wed, 08 Jul 2009 09:22:58 +0000 In-Reply-To: <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> (Jim Reid's message of "Wed\, 8 Jul 2009 10\:21\:19 +0100") Message-ID: <828wiz5y19.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: * Jim Reid: > On 8 Jul 2009, at 09:59, Florian Weimer wrote: > >> Would it help if there was some sort of EDNS0 flag/option which >> instructed the server to include an NSEC(3) record for the QNAME, to >> reveal which other RR types exist at that name? > > No. If some client wants to get an NSEC(3) RR in a response, it should > explictly ask for one. Ahem, and how is AAAA different? --=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 Jul 8 02:29:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23B53A6EC3; Wed, 8 Jul 2009 02:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8J06V-McgIM; Wed, 8 Jul 2009 02:29:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDEB13A688B; Wed, 8 Jul 2009 02:29:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTR5-00091c-Rp for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:27:31 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTQu-00090d-JP for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:27:26 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 8088F501B0C; Wed, 8 Jul 2009 10:27:19 +0100 (BST) Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Message-Id: <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> From: Jim Reid To: Florian Weimer In-Reply-To: <828wiz5y19.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Date: Wed, 8 Jul 2009 10:27:19 +0100 References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <828wiz5y19.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8 Jul 2009, at 10:22, Florian Weimer wrote: >> On 8 Jul 2009, at 09:59, Florian Weimer wrote: >> >>> Would it help if there was some sort of EDNS0 flag/option which >>> instructed the server to include an NSEC(3) record for the QNAME, to >>> reveal which other RR types exist at that name? >> >> No. If some client wants to get an NSEC(3) RR in a response, it >> should >> explictly ask for one. > > Ahem, and how is AAAA different? Please define what you mean by "different" here. Your question makes no sense. -- to unsubscribe send a message to namedroppers-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 Jul 8 02:44:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1783A6E87; Wed, 8 Jul 2009 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.462 X-Spam-Level: X-Spam-Status: No, score=0.462 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 W1N+nGD2sp4o; Wed, 8 Jul 2009 02:44:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C7003A6EE3; Wed, 8 Jul 2009 02:43:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTbm-000ACh-1Q for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:38:34 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTbX-000A9y-Fu for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:38:28 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MOTeo-00037h-PF; Wed, 08 Jul 2009 11:41:42 +0200 Received: by bfk.de with local id 1MOTbT-0000Jk-Fi; Wed, 08 Jul 2009 09:38:15 +0000 To: Jim Reid Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <828wiz5y19.fsf@mid.bfk.de> <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> From: Florian Weimer Date: Wed, 08 Jul 2009 09:38:15 +0000 In-Reply-To: <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> (Jim Reid's message of "Wed\, 8 Jul 2009 10\:27\:19 +0100") Message-ID: <824otn5xbs.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: * Jim Reid: > On 8 Jul 2009, at 10:22, Florian Weimer wrote: > >>> On 8 Jul 2009, at 09:59, Florian Weimer wrote: >>> >>>> Would it help if there was some sort of EDNS0 flag/option which >>>> instructed the server to include an NSEC(3) record for the QNAME, to >>>> reveal which other RR types exist at that name? >>> >>> No. If some client wants to get an NSEC(3) RR in a response, it >>> should >>> explictly ask for one. >> >> Ahem, and how is AAAA different? > > Please define what you mean by "different" here. Your question makes > no sense. The proposed draft attempts to reduce the number of queries during transition to IPv6. You say that you should just send more than one query. This could mean that you think the proposed protocol improvement is unnecessary, or that the situation is somewhat different there. --=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 Jul 8 02:51:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202F33A6BD5; Wed, 8 Jul 2009 02:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT4xU63-TfTp; Wed, 8 Jul 2009 02:51:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 218523A6969; Wed, 8 Jul 2009 02:51:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTlW-000BIL-Fq for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:48:38 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTlL-000BHN-8W for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:48:32 +0000 Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6D1542FE960C for ; Wed, 8 Jul 2009 09:48:23 +0000 (UTC) Date: Wed, 8 Jul 2009 05:48:19 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Message-ID: <20090708094817.GB18180@shinkuro.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1247037139.3922.19184.camel@shane-asus-laptop> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 08, 2009 at 09:12:19AM +0200, Shane Kerr wrote: > > Just so I'm clear, this means IXFR-ONLY is out of scope and the work > needs to be done outside of DNSEXT? As would any other new DNS work > except for the 5 items listed? Well, note that the charter hasn't been adopted yet. But yes, that's the idea. If there were consensus to adopt the work, the WG would need to be rechartered again (unless many people say now, "Yes, adopt that," in which case we could add it to the charter right away). Remember that we put the WG "to sleep" some time ago, on the general principle that continued tinkering with a protocol as mature as DNS was not a great idea. That's not to say there are no refinements to make. But the idea was to have a high bar for additional work, in order to make sure that the additional work was really valuable before undertaking it. As it is, it seems to me we're at least somnambulent: we seem to be pretty busy for someone sleeping. Best, Andrew (for the Chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 02:51:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B3B28C4B5; Wed, 8 Jul 2009 02:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVx3yoYEXSFm; Wed, 8 Jul 2009 02:51:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76B5D3A6969; Wed, 8 Jul 2009 02:51:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTke-000BDH-Uz for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:47:44 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTkT-000BCF-Mw for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:47:39 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 4D233E601C; Wed, 8 Jul 2009 09:47:32 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) From: Shane Kerr To: Jelte Jansen Cc: namedroppers@ops.ietf.org In-Reply-To: <4A53558C.5030702@NLnetLabs.nl> References: <4A53558C.5030702@NLnetLabs.nl> Content-Type: text/plain Organization: ISC Date: Wed, 08 Jul 2009 11:47:29 +0200 Message-Id: <1247046449.3922.19784.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Jelte, On Tue, 2009-07-07 at 16:02 +0200, Jelte Jansen wrote: > looks nice. I only gave it a cursory read, but one thing that came to mind was > that a master could also respond with AXFR because that is simply smaller than > the IXFR it would have made. In that specific case sending the axfr would be > more in the spirit of the draft than returning cannotIXFR. > > It could be in between the lines ("..for the serial requested") but in that case > i'd make it quite a bit more explicit. Interesting. I can't think of a reason not to support such a method, although I have a vague notion that it might be bad in some circumstances. I'll update the draft to allow this behavior. Thanks, -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 03:19:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4013A6821; Wed, 8 Jul 2009 03:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoKBBzfKZrrR; Wed, 8 Jul 2009 03:19:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A7FA3A6926; Wed, 8 Jul 2009 03:19:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUAP-000Dz1-2w for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:14:21 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUAD-000DxO-TT for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:14:15 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 64540E6071; Wed, 8 Jul 2009 10:14:08 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) From: Shane Kerr To: Masataka Ohta Cc: namedroppers@ops.ietf.org In-Reply-To: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="UTF-8" Organization: ISC Date: Wed, 08 Jul 2009 12:14:05 +0200 Message-Id: <1247048045.3922.19886.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ohta-san, On Wed, 2009-07-08 at 05:57 +0900, Masataka Ohta wrote: > First of all, I recommend you not to use ISO 8859 specific characters > for your name, because they are not internationally available including, > but not limited to, Japanese environment. This is my fault, trying to render Ondřej's name as it is, rather than an ASCII-approximation. The XML source actually uses the funky markup codes which should translate into the appropriate encoding (Unicode for example), but I guess xml2rfc isn't smart enough to convert it to plain ASCII when the output is... plain ASCII. I have fixed this for the next version of the draft. > > For example, master NS1 may have serials 1, 2, and 3 for a zone, and > > master NS2 may have serials 1 and 3. A slave that is at serial 2 > > Can't the problem better solved operationally by configuring > masters always request IXFR and never answer to other masters > with condensation of RFC1995: > > An IXFR server may optionally condense multiple difference sequences > into a single difference sequence, thus, dropping information on > intermediate versions. Not necessarily. Masters only keep a limited number of old versions of zones. A slave may still be able to IXFR from some of its masters but not all in this case. IXFR-ONLY also supports best-possible IXFR no matter how the masters got their data, even if it is not via the DNS protocol itself. Thanks for your attention, -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 03:44:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5363A68E3; Wed, 8 Jul 2009 03:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh50rs3bRw2a; Wed, 8 Jul 2009 03:44:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B2F93A6F26; Wed, 8 Jul 2009 03:44:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUZg-000Gjs-Hh for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:40:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUZS-000Ghi-47 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:40:22 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 29802E606E; Wed, 8 Jul 2009 10:40:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n68Ae7Xs034194; Wed, 8 Jul 2009 20:40:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> To: Jim Reid Cc: Florian Weimer , Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org From: Mark Andrews References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> Subject: Re: [dnsext] a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt In-reply-to: Your message of "Wed, 08 Jul 2009 10:21:19 +0100." <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> Date: Wed, 08 Jul 2009 20:40:07 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com>, Jim Reid writes: > On 8 Jul 2009, at 09:59, Florian Weimer wrote: > > > Would it help if there was some sort of EDNS0 flag/option which > > instructed the server to include an NSEC(3) record for the QNAME, to > > reveal which other RR types exist at that name? > > No. If some client wants to get an NSEC(3) RR in a response, it should > explictly ask for one. You can't ask for NSEC3 records. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 03:49:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4785E3A6F27; Wed, 8 Jul 2009 03:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0tInwimFHcf; Wed, 8 Jul 2009 03:49:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AF593A67B2; Wed, 8 Jul 2009 03:48:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUfI-000HJ0-NX for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:46:16 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUez-000HHZ-Oe for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:46:03 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 6716CE6070; Wed, 8 Jul 2009 10:45:56 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) From: Shane Kerr To: Andrew Sullivan Cc: namedroppers@ops.ietf.org In-Reply-To: <20090708094817.GB18180@shinkuro.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> Content-Type: text/plain Organization: ISC Date: Wed, 08 Jul 2009 12:45:53 +0200 Message-Id: <1247049953.3922.20011.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew, On Wed, 2009-07-08 at 05:48 -0400, Andrew Sullivan wrote: > Remember that we put the WG "to sleep" some time ago, on the general > principle that continued tinkering with a protocol as mature as DNS > was not a great idea. That's not to say there are no refinements to > make. But the idea was to have a high bar for additional work, in > order to make sure that the additional work was really valuable before > undertaking it. As it is, it seems to me we're at least somnambulent: > we seem to be pretty busy for someone sleeping. I confess to zoning out during the discussion about going dormant, because it was one of those topics that everyone can immediately understand and form an instant opinion. So there were lots of speeches at the microphones, huge e-mail threads with low signal-to-noise ratios, and so on. Apologies for my lack of attention. It seemed to make sense from a theoretical point of view though. The current style of DNS standards work seems to be that we have a number of people working full-time on DNS stuff, and occasionally they think of something that should be standardized, so when they have a few moments they write something down and present it to the dnsext working group. This seems to work pretty good (except for the huge mass of confusing RFCs, hopefully an effort to fix that will arise again some day). I'm not sure if the IXFR-ONLY stuff is interesting enough for a recharter. (I'm happy to pursue it as an individual submission, although I heard horror stories about that process. Maybe that was only in the past though.) Weird that we have a system designed to make it hard to make small tweaks but easy to make major changes though! Maybe we should collect small DNS work in a separate area and then create a "dnsfix" group every now and then to push them through the standards process? It hardly seems ideal, but... -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 03:49:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5263A67B2; Wed, 8 Jul 2009 03:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPuowoaQpvhb; Wed, 8 Jul 2009 03:49:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D611F28C4B5; Wed, 8 Jul 2009 03:48:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUf9-000HIH-3h for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:46:07 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUeu-000HHM-VD for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:46:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id A7E35501EB7; Wed, 8 Jul 2009 11:45:51 +0100 (BST) Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Message-Id: <1F715216-F51A-431A-A4E7-CB5F2F3A1584@rfc1035.com> From: Jim Reid To: Florian Weimer In-Reply-To: <824otn5xbs.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Date: Wed, 8 Jul 2009 11:45:51 +0100 References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <828wiz5y19.fsf@mid.bfk.de> <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> <824otn5xbs.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8 Jul 2009, at 10:38, Florian Weimer wrote: > The proposed draft attempts to reduce the number of queries during > transition to IPv6. You say that you should just send more than one > query. No. I said in reply to your question about revealing "which other RR types exist at that name" that a client could/should construct a query to which will yield precisely that response. > This could mean that you think the proposed protocol > improvement is unnecessary, or that the situation is somewhat > different there. That's your interpretation. And it's somewhat incorrect. IMO, I don't think there's much to be gained operationally by having some meta QTYPE return both A and AAAA records. An extra query to explicitly retrieve the A (or AAAA) records for some domain name will largely be lost in the noise of the other overheads when resolving that domain name. That said, it's always a nice idea to get as much DNS payload in as few packets as possible, particularly on mobile networks. Saving an extra DNS query/response with a BOTH QTYPE is all very well, but I think it raises much more subtle and possibly more serious operational/protocol concerns. When the ideas in this I-D were floated 7 years ago as the ADDR QTYPE, Rob Austein explained quite clearly why this was a bad idea. In http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01334.html he said: "if there's more than one distinct RRset that can satisfy a particular query, you can't predict which RRset(s) you're going to get back in the response unless you're talking to the authoritative server. Additional section processing doesn't count, since in all but a few (reasonably well-understood) cases the additional section is just an efficiency hack and one can just query explictly for whatever one might have wished to find there." I think the operational benefits from this latest draft are outweighed by other considerations. Section 3 of the I-D says "All existing query types that perform type A and AAAA processing must be redefined to perform type A, type AAAA and BOTH processing.". That's rather scary. What are the protocol and operational impacts of this on (say) glue handling and resolution of NS records? Will resolvers have to make BOTH queries as well as (or instead of) explicit A or AAAA queries? Also, what happens if/when IETF invents another address record or exhumes A6? These questions also apply to your suggestion of an extra EDNS flag. -- to unsubscribe send a message to namedroppers-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 Jul 8 03:53:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBF73A69EE; Wed, 8 Jul 2009 03:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LepEzKXjD22J; Wed, 8 Jul 2009 03:53:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82E373A69D0; Wed, 8 Jul 2009 03:53:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUiA-000HZq-Fv for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:49:14 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUhz-000HZC-Hy for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:49:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id A1C4C501EE6; Wed, 8 Jul 2009 11:49:02 +0100 (BST) Cc: Florian Weimer , Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Message-Id: <335311FE-7E3C-4737-8915-D0C54CDAD537@rfc1035.com> From: Jim Reid To: Mark Andrews In-Reply-To: <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Date: Wed, 8 Jul 2009 11:49:02 +0100 References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8 Jul 2009, at 11:40, Mark Andrews wrote: > You can't ask for NSEC3 records. dig @a0.org.afilias-nst.info org nsec3 +dnssec seems to work reasonably well even though the NSEC3 RR is in the Authority Section. :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 03:59:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194203A6AB3; Wed, 8 Jul 2009 03:59:30 -0700 (PDT) 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=-0.280, 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 EgFyTjs9v+SN; Wed, 8 Jul 2009 03:59:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 396DE28C53B; Wed, 8 Jul 2009 03:59:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUpM-000IPo-TV for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:56:40 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUpB-000IOg-MH for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:56:35 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MOUsS-00065X-GK; Wed, 08 Jul 2009 12:59:52 +0200 Received: by bfk.de with local id 1MOUp6-0002YG-Sy; Wed, 08 Jul 2009 10:56:24 +0000 To: Jim Reid Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <828wiz5y19.fsf@mid.bfk.de> <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> <824otn5xbs.fsf@mid.bfk.de> <1F715216-F51A-431A-A4E7-CB5F2F3A1584@rfc1035.com> From: Florian Weimer Date: Wed, 08 Jul 2009 10:56:24 +0000 In-Reply-To: <1F715216-F51A-431A-A4E7-CB5F2F3A1584@rfc1035.com> (Jim Reid's message of "Wed\, 8 Jul 2009 11\:45\:51 +0100") Message-ID: <82vdm34f53.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: * Jim Reid: > When the ideas in this I-D were floated 7 years ago as the ADDR QTYPE, > Rob Austein explained quite clearly why this was a bad idea. In > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01334.html > he said: > "if there's more than one distinct RRset that can satisfy a particular > query, you can't predict which RRset(s) you're going to get back in > the response unless you're talking to the authoritative server. > Additional section processing doesn't count, since in all but a few > (reasonably well-understood) cases the additional section is just an > efficiency hack and one can just query explictly for whatever one > might have wished to find there." The NSEC(3) hint I mentioned doesn't suffer from that. We already know that it works. We only need to figure out if it is good enough for the task at hand. --=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 Jul 8 04:06:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0217F28C55D; Wed, 8 Jul 2009 04:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 vt7h5tQytcMs; Wed, 8 Jul 2009 04:06:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D4EF28C53E; Wed, 8 Jul 2009 04:06:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUwc-000JCe-6j for namedroppers-data0@psg.com; Wed, 08 Jul 2009 11:04:10 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUwR-000JBd-FS for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 11:04:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 9D38650200D for ; Wed, 8 Jul 2009 12:03:58 +0100 (BST) Message-Id: From: Jim Reid To: Namedroppers Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] draft-li-dnsext-ipv4-ipv6 and compatibility with the installed base Date: Wed, 8 Jul 2009 12:03:58 +0100 X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I'm troubled by Section 3 of this I-D. Suppose a resolving server sends a BOTH QTYPE to an authoritative server which doesn't speak BOTH, say when resolving the name in the RDATA some NS record. The authoritative server *should* return NOERROR. At which point the resolver presumably would make explicit A or AAAA queries. But what if the (legacy) authoritative server barfs on what it considers to be an unknown RRtype and returns SERVFAIL or FORMERR or behaves in some other unexpected way? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 04:56:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068FC3A6F50; Wed, 8 Jul 2009 04:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.634 X-Spam-Level: *** X-Spam-Status: No, score=3.634 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmnAMIHGVCDz; Wed, 8 Jul 2009 04:56:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 361C63A6E2A; Wed, 8 Jul 2009 04:56:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOVh1-000OPU-1h for namedroppers-data0@psg.com; Wed, 08 Jul 2009 11:52:07 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOVgq-000OON-1h for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 11:52:01 +0000 Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MOVgm-0007mc-IB; Wed, 08 Jul 2009 12:51:52 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOVgm-0005MQ-2f; Wed, 08 Jul 2009 12:51:52 +0100 Message-ID: <90B3E3981C064F7F91CDDE7374CED407@localhost> From: "George Barwood" To: "Michael Graff" Cc: "IETF DNSEXT WG" References: <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> <4A5440A4.2050203@isc.org> <3482744445FC4DB9999AC42A2E96714D@localhost> <4A546249.5050302@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Wed, 8 Jul 2009 12:51:50 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Michael Graff" To: "George Barwood" Cc: "IETF DNSEXT WG" Sent: Wednesday, July 08, 2009 10:09 AM Subject: Re: [dnsext] Name server agility with DNSSEC > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > George Barwood wrote: > > You say this... > >> No state exists on the server, that is the point, yes. > > And then you say this: > >> The server does have to maintain version information though, so it's not >> 100% magic. > > That, to me, is state. How long would it maintain version information > for? How is this sufficiently different than maintaining TCP state for > a short time? This is not state on a per client basis, it's global. It's tracking when the DNS data changes ( due to dynamic updates, AXFR/IXFR etc. ) This is needed so that the client knows it has got a consistent set of pages. A single global 32 bit integer is probably adequate if updates are infrequent. -- to unsubscribe send a message to namedroppers-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 Jul 8 05:08:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA14D3A6AA6; Wed, 8 Jul 2009 05:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.61 X-Spam-Level: *** X-Spam-Status: No, score=3.61 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxffYMxcbdUm; Wed, 8 Jul 2009 05:08:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9697B3A6894; Wed, 8 Jul 2009 05:08:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOVuC-00005P-MF for namedroppers-data0@psg.com; Wed, 08 Jul 2009 12:05:44 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOVu1-00003M-48 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 12:05:38 +0000 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MOVty-0003Z6-LL; Wed, 08 Jul 2009 13:05:30 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOVtx-0006Yv-Pc; Wed, 08 Jul 2009 13:05:29 +0100 Message-ID: <66CF149BDB64457693350A5C59122490@localhost> From: "George Barwood" To: "Alex Bligh" , Cc: References: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> <70926BEF34A83F26B91B71A7@nimrod.local> Subject: Re: [dnsext] -03 version of algo-signal posted Date: Wed, 8 Jul 2009 13:05:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C9FFCC.C416A740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C9FFCC.C416A740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The simple list of bytes wins with "private" algorithms ( assuming they = are supported ). A client selecting a single private algorithm uses 15 bytes more with = the bitmap representation. ----- Original Message -----=20 From: Ray.Bellis@nominet.org.uk=20 To: Alex Bligh=20 Cc: namedroppers@ops.ietf.org=20 Sent: Wednesday, July 08, 2009 9:41 AM Subject: Re: [dnsext] -03 version of algo-signal posted > A single octet for length plus a single octet for one algorithm > is the same length as a single octet for length plus a bitfield > covering the first 8 (i.e. all currently defined) algorithms. As it happens the spec for EDNS0 options already includes a *two* byte = length field. Your point still holds, though :)=20 FWIW, with the bitmap method a client supporting everything up to and = including NSEC3/SHA-1 would need a one byte bitmap, and one supporting = SHA-2 would need two bytes.=20 Ray=20 ------=_NextPart_000_0029_01C9FFCC.C416A740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The simple list of bytes wins with = "private"=20 algorithms ( assuming they are supported ).
 
A client selecting a single private=20 algorithm uses 15 bytes more with the bitmap=20 representation.
 
----- Original Message -----
From: Ray.Bellis@nominet.org.uk =
Sent: Wednesday, July 08, 2009 9:41 AM
Subject: Re: [dnsext] -03 version of algo-signal = posted


> A single octet for length = plus a single=20 octet for one algorithm
> is the same length as a single octet for = length=20 plus a bitfield
> covering the first 8 (i.e. all currently = defined)=20 algorithms.

As it happens the spec = for EDNS0=20 options already includes a *two* byte length field.  Your point = still=20 holds, though :)

FWIW, with the = bitmap=20 method a client supporting everything up to and including NSEC3/SHA-1 = would need=20 a one byte bitmap, and one supporting SHA-2 would need two = bytes.=20

Ray
------=_NextPart_000_0029_01C9FFCC.C416A740-- -- to unsubscribe send a message to namedroppers-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 Jul 8 05:40:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230723A6F39; Wed, 8 Jul 2009 05:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c78Inx5AVlLS; Wed, 8 Jul 2009 05:40:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23BAB3A6A94; Wed, 8 Jul 2009 05:40:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOWLW-00037s-I4 for namedroppers-data0@psg.com; Wed, 08 Jul 2009 12:33:58 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOWLL-00036m-CL for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 12:33:52 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id ECC279558E; Wed, 8 Jul 2009 14:33:44 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id A5168157611; Wed, 8 Jul 2009 14:30:46 +0200 (CEST) Date: Wed, 8 Jul 2009 14:30:46 +0200 From: Stephane Bortzmeyer To: Jim Reid Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Message-ID: <20090708123046.GD24439@laperouse.bortzmeyer.org> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> <335311FE-7E3C-4737-8915-D0C54CDAD537@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <335311FE-7E3C-4737-8915-D0C54CDAD537@rfc1035.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 08, 2009 at 11:49:02AM +0100, Jim Reid wrote a message of 7 lines which said: > dig @a0.org.afilias-nst.info org nsec3 +dnssec seems to work > reasonably well even though the NSEC3 RR is in the Authority > Section. :-) It should not :-) RFC 5155, 7.2.8, "Responding to Queries for NSEC3 Owner Names" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 07:20:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB183A6B72; Wed, 8 Jul 2009 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.94 X-Spam-Level: * X-Spam-Status: No, score=1.94 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5if8dIUPpwzH; Wed, 8 Jul 2009 07:20:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E56D3A6AAA; Wed, 8 Jul 2009 07:20:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOXtS-000DrS-Vo for namedroppers-data0@psg.com; Wed, 08 Jul 2009 14:13:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOXtH-000Dq8-VP for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 14:13:01 +0000 Received: (qmail 97688 invoked from network); 8 Jul 2009 15:53:46 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jul 2009 15:53:46 -0000 Message-ID: <4A54A93B.3030508@necom830.hpcl.titech.ac.jp> Date: Wed, 08 Jul 2009 23:12:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Shane Kerr CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> <1247048045.3922.19886.camel@shane-asus-laptop> In-Reply-To: <1247048045.3922.19886.camel@shane-asus-laptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Shane Kerr wrote: > This is my fault, trying to render Ondrej's name as it is, In your mail, you, again, spelled Ondrej's name not in ASCII, which I corrected, because I can't send a ISO8859 mail from my environment. > rather than an ASCII-approximation. Just as I am "Masataka Ohta", it is not an ASCII approximation but an ASCII representation. > The XML source actually uses the funky markup > codes which should translate into the appropriate encoding (Unicode for > example), but I guess xml2rfc isn't smart enough to convert it to plain > ASCII when the output is... plain ASCII. Many applications in Japan on MS windows support Shift JIS only, which is not a super set of ISO8859. > I have fixed this for the next version of the draft. I'm saying you shouldn't use ISO8859 characters for international mails, if you want to communicate not intra EU but internationally. >>Can't the problem better solved operationally by configuring >>masters always request IXFR and never answer to other masters >>with condensation of RFC1995: >> >> An IXFR server may optionally condense multiple difference sequences >> into a single difference sequence, thus, dropping information on >> intermediate versions. > Not necessarily. Masters only keep a limited number of old versions of > zones. A slave may still be able to IXFR from some of its masters but > not all in this case. Operators, not necessarily, operate servers to keep all the old versions, of course. However, I'm saying operators trying to fully utilize IXFR SHOULD keep as many old versions as appropriate on master servers and use them for IXFR reply to queries from other master servers, even if AXFR reply is shorter. Replies from the master servers to other servers MAY still be condensed. To do so, it is required for the operators to configure master servers know IP addresses of other master servers. But, thanks to AXFR fallback, failing to do so will only result in possible inefficiencies, not incorrectness. 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 Wed Jul 8 09:38:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32C93A6B37; Wed, 8 Jul 2009 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.127 X-Spam-Level: * X-Spam-Status: No, score=1.127 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6reB8Oi3lb0J; Wed, 8 Jul 2009 09:38:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B17DA3A6ADF; Wed, 8 Jul 2009 09:38:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOa2I-0002qH-Oj for namedroppers-data0@psg.com; Wed, 08 Jul 2009 16:30:22 +0000 Received: from [209.85.218.226] (helo=mail-bw0-f226.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOa26-0002mh-1H for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 16:30:16 +0000 Received: by bwz26 with SMTP id 26so5770914bwz.41 for ; Wed, 08 Jul 2009 09:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.196 with SMTP id g4mr3582644fap.36.1247070607177; Wed, 08 Jul 2009 09:30:07 -0700 (PDT) In-Reply-To: References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> <1247048045.3922.19886.camel@shane-asus-laptop> <4A54A93B.3030508@necom830.hpcl.titech.ac.jp> From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Wed, 8 Jul 2009 18:29:47 +0200 Message-ID: Subject: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [resent since Trend Micro blocked first try] [could IETF lists stop using fast-flux block list? this is not a first time my email from gmail got blocked :( ] Masataka-san, On Wed, Jul 8, 2009 at 4:12 PM, Masataka Ohta wrote: > Shane Kerr wrote: > > > This is my fault, trying to render Ondrej's name as it is, > > In your mail, you, again, spelled =C2=A0Ondrej's name not in ASCII, which > I corrected, because I can't send a ISO8859 mail from my environment. Sorry, but neither I nor Shane is using ISO8859, but Unicode (namely UTF-8 according to my mail reader). And Unicode 1.0.0 came out in 1991. I generally try to avoid writing correct spelling of my name in email body to avoid base64 encoding of the body. So your complaint is really about From: field. > > rather than an ASCII-approximation. > > Just as I am "Masataka Ohta", it is not an ASCII approximation but > an ASCII representation. That goes for you. Shane is correct that "Ondrej Sury" is just ASCII approximation. > Or, can I expect you recognize and input formal representation of > my name, which is in Chinese characters of ? I am just fine receiving emails in UTF-8 and I receive many of them (f.e. i= n Debian) and I have no problems receiving and sending emails including non-ASCII and non-ISO8859 since some time. > > I have fixed this for the next version of the draft. > > I'm saying you shouldn't use ISO8859 characters for international > mails, if you want to communicate not intra EU but internationally. MIME was standardize in June 1992. How long should we stick to crippling ou= r names? > However, I'm saying operators trying to fully utilize IXFR SHOULD > keep as many old versions as appropriate on master servers and use > them for IXFR reply to queries from other master servers, even if > AXFR reply is shorter. They should, but in case that one master is not able to keep up (for whatever reason, f.e. new server, outdated zone, disk space...), slave should be able to skip it and use next master for IXFR-ONLY. Fallback is just fine if requested. Right now slave has no mean how to refuse AXFR. Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. =C2=A0-- =C2=A0.cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz =C2=A0http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 =C2=A0 =C2=A0 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 10:41:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BC03A6ACF; Wed, 8 Jul 2009 10:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9UFpc491Xq7; Wed, 8 Jul 2009 10:41:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 981D13A6812; Wed, 8 Jul 2009 10:41:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOb5U-000AKk-4r for namedroppers-data0@psg.com; Wed, 08 Jul 2009 17:37:44 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOb5G-000AJV-6N for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 17:37:38 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 24D71C2DA3; Wed, 8 Jul 2009 18:37:26 +0100 (BST) Date: Wed, 08 Jul 2009 18:37:05 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] -03 version of algo-signal posted Message-ID: <897986651EA75B4AA8C785D2@Ximines.local> In-Reply-To: <66CF149BDB64457693350A5C59122490@localhost> References: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> <70926BEF34A83F26B91B71A7@nimrod.local> <66CF149BDB64457693350A5C59122490@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 8 July 2009 13:05:28 +0100 George Barwood wrote: > The simple list of bytes wins with "private" algorithms ( assuming they > are supported ). > > A client selecting a single private algorithm uses 15 bytes more with the > bitmap representation. >From the draft: > 3. Client Considerations > > A validating end-system resolver sets the AU option in the OPT > meta-RR when sending a query. The validating end-system resolver > SHOULD set the value(s) to be the largest algorithm code that the > validator understands (excluding Reserved codes and values greater > than 252). I took it from that that we are only using algorithm codes 1 to 8(ish) today (though in future that may rise), but perhaps I have this wrong. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 11:13:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA12A3A6BCD; Wed, 8 Jul 2009 11:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsKVXpIe50L1; Wed, 8 Jul 2009 11:13:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACA4E3A691B; Wed, 8 Jul 2009 11:13:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MObaO-000E7U-Oc for namedroppers-data0@psg.com; Wed, 08 Jul 2009 18:09:40 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MObaD-000E6M-RQ for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 18:09:35 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 935E52FE9576 for ; Wed, 8 Jul 2009 18:09:28 +0000 (UTC) Date: Wed, 8 Jul 2009 14:09:27 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Message-ID: <20090708180926.GB18387@shinkuro.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1247049953.3922.20011.camel@shane-asus-laptop> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 08, 2009 at 12:45:53PM +0200, Shane Kerr wrote: > The current style of DNS standards work seems to be that we have a > number of people working full-time on DNS stuff, and occasionally they > think of something that should be standardized, so when they have a few > moments they write something down and present it to the dnsext working > group. This seems to work pretty good (except for the huge mass of > confusing RFCs, hopefully an effort to fix that will arise again some > day). Well, the last effort was undertaken as a planned attack on the overall problem. It failed because we didn't get text. It could be, however, that a less centrally-planned effort would work. If someone were to write a "DNS Guide to the Perplexed" as an I-D and just ask for comments, perhaps it would bear fruit. > I'm not sure if the IXFR-ONLY stuff is interesting enough for a > recharter. (I'm happy to pursue it as an individual submission, although > I heard horror stories about that process. Maybe that was only in the > past though.) Weird that we have a system designed to make it hard to > make small tweaks but easy to make major changes though! That might be an important observation about the charter as it is written. Are there others who think this is a potential problem? It would be good to hear that now, while the IESG still hasn't made a decision. > Maybe we should collect small DNS work in a separate area and then > create a "dnsfix" group every now and then to push them through the > standards process? It hardly seems ideal, but... Creating a new group would be even more work than just rechartering DNSEXT to do the work, I note. But perhaps your suggesting includes an implicit step, "Shut down DNSEXT." Since the fondest hope of every working group chair is supposed to be the closing down of the working group on the grounds that there's no more work to do, I plan to be the last voice opposing that suggestion if indeed you are making it. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 11:29:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8AB3A6B5F; Wed, 8 Jul 2009 11:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDq1T5Q+vbl7; Wed, 8 Jul 2009 11:29:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DA783A6B89; Wed, 8 Jul 2009 11:28:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MObp7-000FpI-TF for namedroppers-data0@psg.com; Wed, 08 Jul 2009 18:24:53 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MObov-000FoP-3V for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 18:24:47 +0000 Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n68IOYxK030961 for ; Wed, 8 Jul 2009 14:24:34 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Wed, 8 Jul 2009 14:24:34 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Wed, 8 Jul 2009 14:24:33 -0400 Subject: Re: [dnsext] -03 version of algo-signal posted Thread-Topic: [dnsext] -03 version of algo-signal posted Thread-Index: Acn/NCKA4ZAew5/RTSiYUvk8pXRETAAxTSYd Message-ID: In-Reply-To: <0DD5469CCC3A42EDB331D494A177AA51@localhost> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7/7/09 2:52 PM, "George Barwood" wrote= : > You don't discuss whether DNSKEY RRsets should be pruned to match > the client preference. Are servers allowed to do this? It would > mean that the server would need to have signatures for different > variations of the DNSKEY RRset, but that's not an obvious > problem ( except that unusual queries for ANY or RRSIG could yield > very long responses ). >=20 Probably shouldn't - the entire RRset is needed to validate RRSIGs, but a validator doesn't necessary need every RRSIG to validate the RRset. > In section 3.1, "The only exception is for validating stub resolvers..." > doesn't make sense, because it's not an exception to the previously state= d > rule, which concerns non-validating resolvers. >=20 > "Caches MUST NOT set the AU option on any outgoing query from the > cache when performing recursion on behalf of a stub client." >=20 > Does this not depend on local policy, and the service offered by the cach= e? > For example the cache may know that there are no validating stubs to be > served. > Also, the cache could track the algorithms that an RRset has been queried > for, and > send a further request to if another client requests a different algorith= m. > Why exclude this possibility? >=20 Changing in -04 to state that clients MUST NOT when the stub client is not DNSSEC aware or is DNSSEC-aware and setting the CD bit. > "In these cases a client might be able to detect an attack if the target > zone has a > DS RR in its delegating parent with the desired algorithm." >=20 > Well now, does this work or doesn't it? > I think the natural RRset to look at is the DNSKEY RRset, not the DS, > which is merely the means of authenticating the DNSKEY RRset > ( the parent zone may support a different set of algorithms ). >=20 Changed - yes I believe the attack will be seen, so "In these cases a clien= t will be able to detect an attack if the target zone has a DS RR in its delegating parent and with the desired algorithm." > I don't know whether the standard already requires that all algorithms in > the > DNSKEY RRset must be supported ( in the sense that RRSIGs must be issued = ). > I think that must be the case, but if not, that should be an extra condit= ion > on > servers that support algo-signal, and clients must check that the expecte= d > RRSIGs > are sent, and presumably fail if they are not sent. >=20 Ok - will work on getting that into the -04 version Thanks, Scott > George >=20 > ----- Original Message ----- > From: "Rose, Scott W." > To: > Sent: Tuesday, July 07, 2009 3:42 PM > Subject: [dnsext] -03 version of algo-signal posted >=20 >=20 > "Official" -03 version of algo-signal posted: > http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.t= xt >=20 > This is different that the working version Steve sent to the list recentl= y. > It goes back to the original (-00) version in that the algorithms are a l= ist > in the OPT RR, not a single value with assumptions. >=20 > Please refer to this version for future discussions. > Scott >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scott Rose > NIST > scottr@nist.gov > ph: +1 301-975-8439 > http://www-x.antd.nist.gov/dnssec > http://www.dnsops.gov/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 11:58:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0297028C148; Wed, 8 Jul 2009 11:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.586 X-Spam-Level: *** X-Spam-Status: No, score=3.586 tagged_above=-999 required=5 tests=[AWL=1.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5tOLE0niS4F; Wed, 8 Jul 2009 11:58:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A7DC28C12E; Wed, 8 Jul 2009 11:58:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOcGn-000JQl-Rz for namedroppers-data0@psg.com; Wed, 08 Jul 2009 18:53:29 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOcGc-000JOb-Ej for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 18:53:23 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MOcGZ-0006m0-M5; Wed, 08 Jul 2009 19:53:15 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOcGZ-0003ZO-3k; Wed, 08 Jul 2009 19:53:15 +0100 Message-ID: From: "George Barwood" To: "Alex Bligh" , Cc: , "Alex Bligh" References: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> <70926BEF34A83F26B91B71A7@nimrod.local> <66CF149BDB64457693350A5C59122490@localhost> <897986651EA75B4AA8C785D2@Ximines.local> Subject: Re: [dnsext] -03 version of algo-signal posted Date: Wed, 8 Jul 2009 19:53:13 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Response Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Yes, the current draft clearly excludes private algorithms. I could have been more explicit : "if they are supported in a revised draft". ----- Original Message ----- From: "Alex Bligh" To: "George Barwood" ; Cc: ; "Alex Bligh" Sent: Wednesday, July 08, 2009 6:37 PM Subject: Re: [dnsext] -03 version of algo-signal posted > > > --On 8 July 2009 13:05:28 +0100 George Barwood > wrote: > >> The simple list of bytes wins with "private" algorithms ( assuming they >> are supported ). >> >> A client selecting a single private algorithm uses 15 bytes more with the >> bitmap representation. > >>From the draft: > >> 3. Client Considerations >> >> A validating end-system resolver sets the AU option in the OPT >> meta-RR when sending a query. The validating end-system resolver >> SHOULD set the value(s) to be the largest algorithm code that the >> validator understands (excluding Reserved codes and values greater >> than 252). > > I took it from that that we are only using algorithm codes 1 to 8(ish) > today (though in future that may rise), but perhaps I have this wrong. > > -- > Alex Bligh > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 12:01:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C46F28C561; Wed, 8 Jul 2009 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfIlSsWwzXZk; Wed, 8 Jul 2009 12:01:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB59328C577; Wed, 8 Jul 2009 12:01:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOcLh-000K6e-4g for namedroppers-data0@psg.com; Wed, 08 Jul 2009 18:58:33 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOcLW-000K5I-8n for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 18:58:27 +0000 Received: from [10.47.9.158] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B457CC2DA3; Wed, 8 Jul 2009 19:58:18 +0100 (BST) Date: Wed, 08 Jul 2009 19:58:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] -03 version of algo-signal posted Message-ID: <589754EDB5847D2B740959A0@nimrod.local> In-Reply-To: References: <4B305D7B13A14FC484A43E8AF55DD04F@localhost> <70926BEF34A83F26B91B71A7@nimrod.local> <66CF149BDB64457693350A5C59122490@localhost> <897986651EA75B4AA8C785D2@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 8 July 2009 19:53:13 +0100 George Barwood wrote: > Yes, the current draft clearly excludes private algorithms. > > I could have been more explicit : "if they are supported in a revised > draft". How would either end know they were using the same private algorithm? It's clearly not a huge issue, but given there have been rather a lot of messages on here concerned with DNS packet sizes, I thought it worth mentioning (even though it's the request not the response) -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 12:49:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CEF3A6B34; Wed, 8 Jul 2009 12:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f7WH8PA1rb4; Wed, 8 Jul 2009 12:49:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E773D3A69FF; Wed, 8 Jul 2009 12:49:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOd4w-0001Bp-VY for namedroppers-data0@psg.com; Wed, 08 Jul 2009 19:45:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOd4l-00019C-82 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 19:45:13 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n68Jj56M007177 for ; Wed, 8 Jul 2009 15:45:05 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n68Jj55p007176 for namedroppers@ops.ietf.org; Wed, 8 Jul 2009 15:45:05 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.217] (helo=mail-ew0-f217.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOT1x-0006Fu-26 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:01:38 +0000 Received: by ewy17 with SMTP id 17so379738ewy.41 for ; Wed, 08 Jul 2009 02:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=Zujay4EN52cyYxCL0L4uYsnKc4n2rvYNNoFwAL0gYHQ=; b=Rhc78RFPJV/B/Gzi/HK/FxPcSquCIhyQHwdHJrNXGuDkEH5KTJsJFfMULH/KfXC8g5 MiSLGz/NZrHelAy2mu0q2RDt577NXf6N3sE8uxVuAjqHAKyTKk9GJ+BFlW7WAyBfjnZY vks7PpMDFSgLSuqNB+qFw0or6+9aiXYeorJr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=tnJsHVCoUF3Isg6mPFekxqN6eA6MxPc9z2bv/WsNGy2mUpG9KWIoNSRL8WgdXI4HT0 lre9NtCEcfR/XsW3pqI1E8z5qjQ2jHei7IdwzlntUo2R9W13o1rUcDM289LnlBQScIQf VtgEn+99uTllrDJc8hFHl3RSr9+opdW+HEGKE= MIME-Version: 1.0 Received: by 10.210.27.14 with SMTP id a14mr2382905eba.76.1247043691141; Wed, 08 Jul 2009 02:01:31 -0700 (PDT) In-Reply-To: <47013.1247000943@nsa.vix.com> References: <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> From: bert hubert Date: Wed, 8 Jul 2009 11:01:11 +0200 X-Google-Sender-Auth: f8742e3a0eda5c0f Message-ID: <3efd34cc0907080201y349c9484vdb4015d2cce6c823@mail.gmail.com> Subject: Re: [dnsext] fragmentation considered harmful To: Paul Vixie Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tue, Jul 7, 2009 at 11:09 PM, Paul Vixie wrote: > first, see . Nice how you can see the complete corporate history in one URL! And good of them that they still have this online. For a 1987 document it looks remarkably up to date. But what is the the message to take away from this? That we should not rely on fragmented UDP packets? Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 13:23:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A353A6F3C; Wed, 8 Jul 2009 13:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxIz-sYc89fh; Wed, 8 Jul 2009 13:23:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20E7C3A6B92; Wed, 8 Jul 2009 13:23:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOdbe-0006FP-PK for namedroppers-data0@psg.com; Wed, 08 Jul 2009 20:19:06 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOdbT-0006Dz-4H for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 20:19:00 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n68KIi6f026256; Wed, 8 Jul 2009 13:18:44 -0700 (PDT) Cc: Nicholas Weaver , Paul Vixie , IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: bert hubert In-Reply-To: <3efd34cc0907080201y349c9484vdb4015d2cce6c823@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] fragmentation considered harmful Date: Wed, 8 Jul 2009 13:18:44 -0700 References: <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <47013.1247000943@nsa.vix.com> <3efd34cc0907080201y349c9484vdb4015d2cce6c823@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 8, 2009, at 2:01 AM, bert hubert wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > On Tue, Jul 7, 2009 at 11:09 PM, Paul Vixie wrote: >> first, see > >. > > Nice how you can see the complete corporate history in one URL! And > good of them that they still have this online. For a 1987 document it > looks remarkably up to date. > > But what is the the message to take away from this? That we should not > rely on fragmented UDP packets? Thats my take based on current measurements. At least for DNS, fragmented UDP does not get through a shockingly high percentage of the time, when non-fragmented UDP gets through just fine. To my mind, this suggests that, as an authority, whenever possible, make sure you fit in the Ethernet MTU, unless you are happy with TCP fallback on those queries. -- to unsubscribe send a message to namedroppers-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 Jul 8 14:40:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED4E3A697A; Wed, 8 Jul 2009 14:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.937 X-Spam-Level: * X-Spam-Status: No, score=1.937 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7v48pofci9D; Wed, 8 Jul 2009 14:40:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A44843A6881; Wed, 8 Jul 2009 14:40:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOemy-000ESs-0o for namedroppers-data0@psg.com; Wed, 08 Jul 2009 21:34:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOemn-000ESO-1E for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 21:34:46 +0000 Received: (qmail 37987 invoked from network); 8 Jul 2009 23:15:28 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jul 2009 23:15:28 -0000 Message-ID: <4A5510BD.6070809@necom830.hpcl.titech.ac.jp> Date: Thu, 09 Jul 2009 06:33:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: ondrej.sury@nic.cz CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> <1247048045.3922.19886.camel@shane-asus-laptop> <4A54A93B.3030508@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: Ondrej Sury wrote: > Sorry, but neither I nor Shane is using ISO8859, but Unicode I said ISO8859 characters, which is contained in Unicode. > That goes for you. Shane is correct that "Ondrej Sury" is just ASCII > approximation. Historically, diacritical marks were small ASCII characters used to approximate local pronunciations by ASCII characters that, in that sense, all the representations are approximations. > MIME was standardize in June 1992. How long should we stick to crippling our > names? It is an evidence of failure of MIME and Unicode that local environment of MS in Japan does not really support it, even after so many years, even though MS is a major sponsor of Unicode. MIME, Unicode and (to avoid off topic discussion :-) IDN are fundamentally broken w.r.t. internationalization. People should use small set of internationally supported characters, if they want there messages internationally useful. People may use additional locally supported characters in messages to local people. I and other Japanese has been extensively using Japanese characters in messages to people in Japan over RFC821/822 long before MIME was standardized. >>However, I'm saying operators trying to fully utilize IXFR SHOULD >>keep as many old versions as appropriate on master servers and use >>them for IXFR reply to queries from other master servers, even if >>AXFR reply is shorter. > They should, but in case that one master is not able to keep up (for > whatever reason, f.e. new server, outdated zone, disk space...), That's an operational issue to be resolved operationally. Operators can copy several generations of zone contents by hand and if there is not enough disk space, it is an operational error. > Right now slave has no mean how to refuse AXFR. Slave operators can ask master operators. 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 Wed Jul 8 15:01:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9808A3A6FBA; Wed, 8 Jul 2009 15:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NWVOZMmyJ1R; Wed, 8 Jul 2009 15:01:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3BD13A6FB9; Wed, 8 Jul 2009 15:01:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOfA4-000GEU-BU for namedroppers-data0@psg.com; Wed, 08 Jul 2009 21:58:44 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOf9t-000GDd-57 for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 21:58:38 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 397C295AB2; Wed, 8 Jul 2009 23:58:31 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 759491576A4; Wed, 8 Jul 2009 23:51:51 +0200 (CEST) Date: Wed, 8 Jul 2009 23:51:51 +0200 From: Stephane Bortzmeyer To: Jim Reid Cc: Namedroppers Subject: [dnsext] Re: draft-li-dnsext-ipv4-ipv6 and compatibility with the installed base Message-ID: <20090708215151.GA13785@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 08, 2009 at 12:03:58PM +0100, Jim Reid wrote a message of 14 lines which said: > But what if the (legacy) authoritative server barfs on what it > considers to be an unknown RRtype Despite RFC 3597? Shame on them. > and returns SERVFAIL or FORMERR or behaves in some other unexpected > way? In this case, the broken name server will have problem with other clients as well (see RFC 4074). -- to unsubscribe send a message to namedroppers-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 Jul 8 15:55:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CFF3A6A3B; Wed, 8 Jul 2009 15:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvBNGLVVdm5H; Wed, 8 Jul 2009 15:55:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02ADF3A694C; Wed, 8 Jul 2009 15:55:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOfxv-000JjY-BO for namedroppers-data0@psg.com; Wed, 08 Jul 2009 22:50:15 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOfxj-000JiO-0F for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 22:50:09 +0000 Received: from crankycanuck.ca (unknown [12.176.20.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 790012FE960C for ; Wed, 8 Jul 2009 22:50:01 +0000 (UTC) Date: Wed, 8 Jul 2009 18:49:59 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) Message-ID: <20090708224959.GB19410@shinkuro.com> References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> <1247048045.3922.19886.camel@shane-asus-laptop> <4A54A93B.3030508@necom830.hpcl.titech.ac.jp> <4A5510BD.6070809@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A5510BD.6070809@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [moderator hat on] This is not to pick on one correspondent in this thread, but to try to bring the thread to a close. On Thu, Jul 09, 2009 at 06:33:49AM +0900, Masataka Ohta wrote: > MIME, Unicode and (to avoid off topic discussion :-) IDN are Too late, I fear. If the topic is whether MIME mail parts will be accepted on this list, in any format (even, apparently, broken ones), then the ship has sailed, the horse has left the barn, Elvis has left the building, and $ones_favorite_cliche_here. MIME is standardized, and if anyone thinks we need mime-bis or whatever it would be, consider this a plea to write that draft and take it to the appropriate IETF area (this WG is not it). Until MIME is changed, however, even if one doesn't like non-ASCII in one's INBOX, one is out of luck unless one stops using a MUA that can accept multipart messages. Experimentation with such mailers may reveal limitations that they impose. If the topic is whether UTF-8 works properly for internationalization, this is not the list for that discussion. I understand there to be a consortium whose whole existence is devoted to that very question. I am aware that there are limitations in actual experience of deployment; it is beyond my pay grade to have an opinion on whether that is the right thing, and it is outside the job of this WG to evaluate such arguments. If the topic is whether ASCII generally sucks for capturing non-ASCII spellings of people's names, namedroppers is _also_ not the list for that discussion. I note (in my case, speaking personally, with some chagrin) that there is a thread currently on the IETF general list where all manner of topics may be conflated to include the ASCII-sucks/no-it-doesn't topic. In passing, I will also note that the current rules are quite clear: non-ASCII characters are not allowed in RFCs and therefore, presumably, in Internet Drafts (or at least those destined for the standards track). It is outside the remit of this WG to evaluate arguments about how RFCs ought to be formatted, but it is perfectly reasonable to note as an editorial matter that an I-D to be considered has non-ASCII characters. This need not entail debate, since it is a matter of fact and nothing more. If the topic is the internationalization of domain names for applications, there's a whole working group currently dedicated to trying to fix those issues, and if anyone here has something to say about it, I strongly encourage those people to go over there and talk about that topic. I mean this sincerely: the IDNABIS WG is in urgent need of people with DNS operational and protocol experience to evaluate those drafts (as I think I may have suggested on previous occasions). Please, go forth and review! If the topic is the header portion of emails, then I encourage those interested to take this variously to YAM; or some future BOF where the controversial things about email will be discussed; or to the EAI working group, who are busily moving their existing experimental drafts along to get them into shape for making internationalized email addresses safe for the world. But whatever among the above strategies you pick, whether non-ASCII characters are acceptable on this mailing list is not a topic for the mailing list, please. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 8 16:13:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED983A6F37; Wed, 8 Jul 2009 16:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.934 X-Spam-Level: * X-Spam-Status: No, score=1.934 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIWcCblah77p; Wed, 8 Jul 2009 16:13:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0A493A686C; Wed, 8 Jul 2009 16:12:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOgGj-000L6P-UK for namedroppers-data0@psg.com; Wed, 08 Jul 2009 23:09:41 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOgGY-000L4u-LX for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 23:09:36 +0000 Received: (qmail 46800 invoked from network); 9 Jul 2009 00:50:44 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 9 Jul 2009 00:50:44 -0000 Message-ID: <4A552710.9080305@necom830.hpcl.titech.ac.jp> Date: Thu, 09 Jul 2009 08:09:04 +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: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> <1247048045.3922.19886.camel@shane-asus-laptop> <4A54A93B.3030508@necom830.hpcl.titech.ac.jp> <4A5510BD.6070809@necom830.hpcl.titech.ac.jp> <20090708224959.GB19410@shinkuro.com> In-Reply-To: <20090708224959.GB19410@shinkuro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: >>MIME, Unicode and (to avoid off topic discussion :-) IDN are > Too late, I fear. I and other Japanese have been using, without any problem, ASCII internationally and Japanese characters not encoded in Unicode locally long before MIME and Unicode were standaradized and standardizations did not change it. So, I'm perfectly fine people locally use any encoding including but not limited to Unicode. 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 sereshoqs190@islandgutters.com Wed Jul 8 17:17:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D293A6B00; Wed, 8 Jul 2009 17:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.344 X-Spam-Level: X-Spam-Status: No, score=-50.344 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7qIUJveQumZ; Wed, 8 Jul 2009 17:17:21 -0700 (PDT) Received: from 187-26-142-131.3g.claro.net.br (187-26-142-131.3g.claro.net.br [187.26.142.131]) by core3.amsl.com (Postfix) with ESMTP id D803C3A6B60; Wed, 8 Jul 2009 17:17:07 -0700 (PDT) Message-ID: <000d01ca002a$9ff59a20$6400a8c0@sereshoqs190> From: To: Subject: Lose weight without joining expensive Gyms, Acai Berry. Date: Wed, 8 Jul 2009 21:17:20 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA002A.9FF59A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA002A.9FF59A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lose weight and stay healthy the acaiberry way=20   Claim your risk free trial of Acai Berry now =20 Welcoming you =20 best regards Axel=20 Cramer =20 =20 ------=_NextPart_000_0007_01CA002A.9FF59A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Los= e weight and stay healthy the acaiberry way=20
&n= bsp;
Claim your risk free trial of Acai Berry now<= /DIV>
<= A=20 href=3D"http://vuac00.uigfwdpo.cn/">Welcoming you
best regards Axel=20 Cramer
------=_NextPart_000_0007_01CA002A.9FF59A20-- From owner-namedroppers@ops.ietf.org Thu Jul 9 02:37:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8D23A6C24; Thu, 9 Jul 2009 02:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZZ3A-HasXvk; Thu, 9 Jul 2009 02:37:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3ABAF3A6A5E; Thu, 9 Jul 2009 02:37:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOpyA-0005Xo-IC for namedroppers-data0@psg.com; Thu, 09 Jul 2009 09:31:10 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOpxx-0005WX-Pi for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 09:31:03 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:fecd:6a66]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n699UpnI068713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 11:30:52 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A55B81A.2030803@NLnetLabs.nl> Date: Thu, 09 Jul 2009 11:27:54 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> In-Reply-To: <20090708180926.GB18387@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 09 Jul 2009 11:30:52 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: > On Wed, Jul 08, 2009 at 12:45:53PM +0200, Shane Kerr wrote: > >> The current style of DNS standards work seems to be that we have a >> number of people working full-time on DNS stuff, and occasionally they >> think of something that should be standardized, so when they have a few >> moments they write something down and present it to the dnsext working >> group. This seems to work pretty good (except for the huge mass of >> confusing RFCs, hopefully an effort to fix that will arise again some >> day). > > Well, the last effort was undertaken as a planned attack on the > overall problem. It failed because we didn't get text. It could be, > however, that a less centrally-planned effort would work. If someone > were to write a "DNS Guide to the Perplexed" as an I-D and just ask > for comments, perhaps it would bear fruit. > Everytime this issue comes up I'm wondering where we got so deep into the RFC model that we are actually discussing writing a new RFC to counter the problem of having too many RFCs... My general issue with that still stands; the DNS-in-a-nutshell RFC will be outdated as soon as dns-I'm-still-alive-ext publishes a new extension. It's what we do, and despite multiple attempts to kill the working group, no hero has succeeded yet. The update for Nutshell will be an RFC itself, effectively multiplying the DNS RFC growth rate. Not that I'm against the effort; and overview of DNS in it's current state, with references to the myriad of RFCs and other known extensions/exceptions, would be fantastic. But IMHO it would be better implemented as either a website or a non-RFC publication. And it would only be useful if actually kept up-to-date. > >> Maybe we should collect small DNS work in a separate area and then >> create a "dnsfix" group every now and then to push them through the >> standards process? It hardly seems ideal, but... > > Creating a new group would be even more work than just rechartering > DNSEXT to do the work, I note. But perhaps your suggesting includes > an implicit step, "Shut down DNSEXT." Since the fondest hope of every > working group chair is supposed to be the closing down of the working > group on the grounds that there's no more work to do, I plan to be the > last voice opposing that suggestion if indeed you are making it. > Speaking from recent personal experience, classifying dnsext-related work as "small" work can be harder than it seems. There's also the protocol-police part that's in both the current and the proposed charters to consider when thinking about shutting down btw. I think it's worth it to try and get IFXR-only in the charter now (or consensus that the work is not worth it), which will save us at least one recharter. But it appears that frequent recharters are inevitable with an immortal working group. Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 04:09:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981263A6BF0; Thu, 9 Jul 2009 04:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12UZIwhdVGPb; Thu, 9 Jul 2009 04:09:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9C883A6AD3; Thu, 9 Jul 2009 04:09:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOrR6-000FYw-U7 for namedroppers-data0@psg.com; Thu, 09 Jul 2009 11:05:08 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOrQq-000FWN-2K for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 11:05:00 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0739D7C1B7; Thu, 9 Jul 2009 13:04:49 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 0947B1576A4; Thu, 9 Jul 2009 12:57:35 +0200 (CEST) Date: Thu, 9 Jul 2009 12:57:35 +0200 From: Stephane Bortzmeyer To: Yuming Huang Cc: IETF DNS Extensions Working Group Subject: [dnsext] Re: I-D ACTION:draft-huang-dnsext-reputation-00.txt Message-ID: <20090709105735.GA8495@laperouse.bortzmeyer.org> References: <20090707183001.CEAFC3A6ED3@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707183001.CEAFC3A6ED3@core3.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 07, 2009 at 11:30:01AM -0700, Internet-Drafts@ietf.org wrote a message of 57 lines which said: > Title : DNS Encoding of Domain Reputation and IP# Classification > Author(s) : Y. Huang > Filename : draft-huang-dnsext-reputation-00.txt > Therefore, a Resource Record (RR), Domain Reputation and IP# > Classification (DRIC), are recommended as an extension to the > existing DNS protocol. So, copy to the DNS extensions WG, because it is one of its roles. General review: you really need to add a high-level summary of your idea because it is quite difficult to understand. The way you describe it (your zone file example), it seems a domain chooses its own reputation, which is convenient but not very good for figthing abuses :-) > Reputation is a byte integer which encodes a reputation measure for > a string (domain name, host name, or URL) sent by a DNS client to a > DNS server to resolve. A DNS client never sends an URL, it only sends domain names (QNAME field). > A generic form of URL is protocol://userid:password@hostname(ip#):port/path?parameter#anchor No, the first field is not a protocol (RFC 3986, section 1.2.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 lumpyhtx8@irds.net Thu Jul 9 07:36:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D494F3A683A; Thu, 9 Jul 2009 07:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.38 X-Spam-Level: X-Spam-Status: No, score=-31.38 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIapEmKLDvoz; Thu, 9 Jul 2009 07:36:47 -0700 (PDT) Received: from pc-239-54-214-201.cm.vtr.net (pc-239-54-214-201.cm.vtr.net [201.214.54.239]) by core3.amsl.com (Postfix) with ESMTP id D743728C150; Thu, 9 Jul 2009 07:36:46 -0700 (PDT) Received: from 201.214.54.239 by mail.eurorail.eu; Thu, 9 Jul 2009 10:36:59 -0400 From: emu-request@ietf.org To: emu-request@ietf.org Subject: Imagine not being hungry all day without feeling side effects typical of diet pills, like a racing heart or queasy stomach Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: Date: Thu, 9 Jul 2009 07:36:46 -0700 (PDT)
Exceptionnaly sweet and totally advanced formula will have you looking great.
 
Start your day right, Try Acai Berry.
Don't fear the measuring tape anymore , Acai Berri.
best regards Brayan Grayson
From bipolarht33@istegol.com Thu Jul 9 08:40:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF363A683A; Thu, 9 Jul 2009 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.257 X-Spam-Level: X-Spam-Status: No, score=-15.257 tagged_above=-999 required=5 tests=[BAYES_80=2, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxLLgJBVi6pl; Thu, 9 Jul 2009 08:40:06 -0700 (PDT) Received: from adsl-99-138-74-166.dsl.irvnca.sbcglobal.net (adsl-99-138-74-166.dsl.irvnca.sbcglobal.net [99.138.74.166]) by core3.amsl.com (Postfix) with ESMTP id 6D2E628C24B; Thu, 9 Jul 2009 08:39:52 -0700 (PDT) Date: Thu, 9 Jul 2009 08:40:19 -0800 Message-Id: <5E4U4Y6793.VLW44JBQ0036@99.138.74.166.istegol.com> From: emu-request@ietf.org To: emu-request@ietf.org Subject: Rich in antioxidants , Acai Berry is your answer to unwanted weight. Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Feel great with Acai Flush.
 
Improve mental clarity with Acai Diet.
Acai diet will lead to incredible weight loss.
best regards Paige Sosa
From owner-namedroppers@ops.ietf.org Thu Jul 9 09:58:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000AD28C179; Thu, 9 Jul 2009 09:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5gI6IkiR2yJ; Thu, 9 Jul 2009 09:58:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B07963A69A8; Thu, 9 Jul 2009 09:58:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOwqr-0003k5-Qk for namedroppers-data0@psg.com; Thu, 09 Jul 2009 16:52:05 +0000 Received: from [204.235.121.150] (helo=pblpas02.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOwqZ-0003iG-PM for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 16:51:59 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="430640120" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 09 Jul 2009 12:51:44 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 12:51:40 -0400 Received: from pblpas02.twcable.com ([204.235.121.150]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 05:16:44 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAACoBVEqTHAA+kWdsb2JhbACZDgEBAQEJCwoHEwW2IoQIBYE6gig X-IronPort-AV: E=Sophos;i="4.42,367,1243828800"; d="scan'208";a="430170126" Received: from psg.com ([147.28.0.62]) by pblpas02.twcable.com with ESMTP; 08 Jul 2009 05:16:43 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSzu-00060h-Vc for namedroppers-data0@psg.com; Wed, 08 Jul 2009 08:59:26 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSzj-0005yk-Qq for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 08:59:21 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MOT30-0005Ca-Ao; Wed, 08 Jul 2009 11:02:38 +0200 Received: by bfk.de with local id 1MOSzf-0006rx-2P; Wed, 08 Jul 2009 08:59:11 +0000 To: Stephane Bortzmeyer Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> From: Florian Weimer Date: Wed, 08 Jul 2009 08:59:11 +0000 In-Reply-To: <20090706095144.GB25939@nic.fr> (Stephane Bortzmeyer's message of "Mon\, 6 Jul 2009 11\:51\:44 +0200") Message-ID: <82ocrv5z4w.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable List-ID: X-OriginalArrivalTime: 08 Jul 2009 09:16:44.0145 (UTC) FILETIME=[CFBC4610:01C9FFAC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Stephane Bortzmeyer: > On Mon, Jul 06, 2009 at 01:15:01AM -0700, > Internet-Drafts@ietf.org wrote=20 > a message of 53 lines which said: > >> There are two kinds of TYPE for host IP address: one is A, the other >> is AAAA, which records IPv4 and IPv6 addresses respectively. This >> document defines a new TYPE, which is mainly used in queries in >> order to get both IPv4 and IPv6 addresses. > > Certainly a good idea and I applaud the effort. But I vaguely remember > there was a long time ago a project to have a query type ADDR and that > it failed, so you may research history of this project to see what was > the problem. Hmm. I don't think I got the original message, and I think I might already have replied to your message. Oh well. Would it help if there was some sort of EDNS0 flag/option which instructed the server to include an NSEC(3) record for the QNAME, to reveal which other RR types exist at that name? Which type to query first could be based on past performance. --=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: -- to unsubscribe send a message to namedroppers-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 Jul 9 10:01:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B78228C250; Thu, 9 Jul 2009 10:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWprEx34gzyJ; Thu, 9 Jul 2009 10:01:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3362828C179; Thu, 9 Jul 2009 10:01:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOwwb-0004Jw-0o for namedroppers-data0@psg.com; Thu, 09 Jul 2009 16:58:01 +0000 Received: from [204.235.121.149] (helo=pblpas01.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOwv5-00048T-PZ for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 16:56:49 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="431565726" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 09 Jul 2009 12:56:03 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 12:55:42 -0400 Received: from pblpas01.twcable.com ([204.235.121.149]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 06:37:06 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAO0TVEqTHAA+kWdsb2JhbACZDgEBAQEJCwoHEwW3D4QIBYNihTg X-IronPort-AV: E=Sophos;i="4.42,368,1243828800"; d="scan'208";a="431097088" Received: from psg.com ([147.28.0.62]) by pblpas01.twcable.com with ESMTP; 08 Jul 2009 06:37:06 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUAP-000Dz1-2w for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:14:21 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUAD-000DxO-TT for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:14:15 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 64540E6071; Wed, 8 Jul 2009 10:14:08 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) From: Shane Kerr To: Masataka Ohta Cc: namedroppers@ops.ietf.org In-Reply-To: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="UTF-8" Organization: ISC Date: Wed, 08 Jul 2009 12:14:05 +0200 Message-Id: <1247048045.3922.19886.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit List-ID: X-OriginalArrivalTime: 08 Jul 2009 10:37:06.0255 (UTC) FILETIME=[09EFDDF0:01C9FFB8] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ohta-san, On Wed, 2009-07-08 at 05:57 +0900, Masataka Ohta wrote: > First of all, I recommend you not to use ISO 8859 specific characters > for your name, because they are not internationally available including, > but not limited to, Japanese environment. This is my fault, trying to render Ondřej's name as it is, rather than an ASCII-approximation. The XML source actually uses the funky markup codes which should translate into the appropriate encoding (Unicode for example), but I guess xml2rfc isn't smart enough to convert it to plain ASCII when the output is... plain ASCII. I have fixed this for the next version of the draft. > > For example, master NS1 may have serials 1, 2, and 3 for a zone, and > > master NS2 may have serials 1 and 3. A slave that is at serial 2 > > Can't the problem better solved operationally by configuring > masters always request IXFR and never answer to other masters > with condensation of RFC1995: > > An IXFR server may optionally condense multiple difference sequences > into a single difference sequence, thus, dropping information on > intermediate versions. Not necessarily. Masters only keep a limited number of old versions of zones. A slave may still be able to IXFR from some of its masters but not all in this case. IXFR-ONLY also supports best-possible IXFR no matter how the masters got their data, even if it is not via the DNS protocol itself. Thanks for your attention, -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 10:08:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C67A28C260; Thu, 9 Jul 2009 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIVgRub9dJ5Z; Thu, 9 Jul 2009 10:08:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B07BE28C24D; Thu, 9 Jul 2009 10:08:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOx2i-0005th-J0 for namedroppers-data0@psg.com; Thu, 09 Jul 2009 17:04:20 +0000 Received: from [204.235.121.150] (helo=pblpas02.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOx2T-0005qJ-Fi for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 17:04:15 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="430645186" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 09 Jul 2009 13:04:04 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 13:04:04 -0400 Received: from pblpas01.twcable.com ([204.235.121.149]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 07:07:57 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUDAPAaVEqTHAA+kWdsb2JhbACDAYlIjEUBAQEBCQsKBxMFtx+ECAWBOoIo X-IronPort-AV: E=Sophos;i="4.42,368,1243828800"; d="scan'208";a="431100938" Received: from psg.com ([147.28.0.62]) by pblpas01.twcable.com with ESMTP; 08 Jul 2009 07:07:57 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUiA-000HZq-Fv for namedroppers-data0@psg.com; Wed, 08 Jul 2009 10:49:14 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOUhz-000HZC-Hy for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 10:49:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id A1C4C501EE6; Wed, 8 Jul 2009 11:49:02 +0100 (BST) Cc: Florian Weimer , Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Message-Id: <335311FE-7E3C-4737-8915-D0C54CDAD537@rfc1035.com> From: Jim Reid To: Mark Andrews In-Reply-To: <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Date: Wed, 8 Jul 2009 11:49:02 +0100 References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) List-ID: X-OriginalArrivalTime: 08 Jul 2009 11:07:57.0700 (UTC) FILETIME=[597BF440:01C9FFBC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8 Jul 2009, at 11:40, Mark Andrews wrote: > You can't ask for NSEC3 records. dig @a0.org.afilias-nst.info org nsec3 +dnssec seems to work reasonably well even though the NSEC3 RR is in the Authority Section. :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Jul 9 10:10:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F603A69A8; Thu, 9 Jul 2009 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXr7Fht7BBxh; Thu, 9 Jul 2009 10:10:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8801B3A679F; Thu, 9 Jul 2009 10:10:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOx5n-0006HT-88 for namedroppers-data0@psg.com; Thu, 09 Jul 2009 17:07:31 +0000 Received: from [204.235.121.150] (helo=pblpas02.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOx5X-0006EE-IH for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 17:07:24 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="430646478" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 09 Jul 2009 13:07:14 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 13:07:14 -0400 Received: from pblpas01.twcable.com ([204.235.121.149]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 05:58:17 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAIcKVEqTHAA+kWdsb2JhbACZDgEBAQEJCwoHEwW2VoQIBYE6gig X-IronPort-AV: E=Sophos;i="4.42,367,1243828800"; d="scan'208";a="431092859" Received: from psg.com ([147.28.0.62]) by pblpas01.twcable.com with ESMTP; 08 Jul 2009 05:58:17 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTbm-000ACh-1Q for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:38:34 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTbX-000A9y-Fu for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:38:28 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MOTeo-00037h-PF; Wed, 08 Jul 2009 11:41:42 +0200 Received: by bfk.de with local id 1MOTbT-0000Jk-Fi; Wed, 08 Jul 2009 09:38:15 +0000 To: Jim Reid Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <828wiz5y19.fsf@mid.bfk.de> <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> From: Florian Weimer Date: Wed, 08 Jul 2009 09:38:15 +0000 In-Reply-To: <486FECD3-5DB3-4C1D-82C9-86F56CAD20D3@rfc1035.com> (Jim Reid's message of "Wed\, 8 Jul 2009 10\:27\:19 +0100") Message-ID: <824otn5xbs.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable List-ID: X-OriginalArrivalTime: 08 Jul 2009 09:58:17.0488 (UTC) FILETIME=[9DE23900:01C9FFB2] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Jim Reid: > On 8 Jul 2009, at 10:22, Florian Weimer wrote: > >>> On 8 Jul 2009, at 09:59, Florian Weimer wrote: >>> >>>> Would it help if there was some sort of EDNS0 flag/option which >>>> instructed the server to include an NSEC(3) record for the QNAME, to >>>> reveal which other RR types exist at that name? >>> >>> No. If some client wants to get an NSEC(3) RR in a response, it >>> should >>> explictly ask for one. >> >> Ahem, and how is AAAA different? > > Please define what you mean by "different" here. Your question makes > no sense. The proposed draft attempts to reduce the number of queries during transition to IPv6. You say that you should just send more than one query. This could mean that you think the proposed protocol improvement is unnecessary, or that the situation is somewhat different there. --=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: -- to unsubscribe send a message to namedroppers-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 Jul 9 10:11:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AA73A69A8; Thu, 9 Jul 2009 10:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.062 X-Spam-Level: X-Spam-Status: No, score=-1.062 tagged_above=-999 required=5 tests=[AWL=-1.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrm77QVEDHen; Thu, 9 Jul 2009 10:11:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 256603A679F; Thu, 9 Jul 2009 10:11:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOx76-0006Qo-Ud for namedroppers-data0@psg.com; Thu, 09 Jul 2009 17:08:53 +0000 Received: from [204.235.121.150] (helo=pblpas02.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOx6v-0006P4-43 for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 17:08:47 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="430647119" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 09 Jul 2009 13:08:40 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 13:08:39 -0400 Received: from pblpas01.twcable.com ([204.235.121.149]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 06:06:05 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAN8MVEqTHAA+kWdsb2JhbACZDgEBAQEJCwoHEwW2aoQIBYNi X-IronPort-AV: E=Sophos;i="4.42,367,1243828800"; d="scan'208";a="431094426" Received: from psg.com ([147.28.0.62]) by pblpas01.twcable.com with ESMTP; 08 Jul 2009 06:05:55 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTke-000BDH-Uz for namedroppers-data0@psg.com; Wed, 08 Jul 2009 09:47:44 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOTkT-000BCF-Mw for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 09:47:39 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 4D233E601C; Wed, 8 Jul 2009 09:47:32 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) From: Shane Kerr To: Jelte Jansen Cc: namedroppers@ops.ietf.org In-Reply-To: <4A53558C.5030702@NLnetLabs.nl> References: <4A53558C.5030702@NLnetLabs.nl> Content-Type: text/plain Organization: ISC Date: Wed, 08 Jul 2009 11:47:29 +0200 Message-Id: <1247046449.3922.19784.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 08 Jul 2009 10:06:05.0389 (UTC) FILETIME=[B4C63FD0:01C9FFB3] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Jelte, On Tue, 2009-07-07 at 16:02 +0200, Jelte Jansen wrote: > looks nice. I only gave it a cursory read, but one thing that came to mind was > that a master could also respond with AXFR because that is simply smaller than > the IXFR it would have made. In that specific case sending the axfr would be > more in the spirit of the draft than returning cannotIXFR. > > It could be in between the lines ("..for the serial requested") but in that case > i'd make it quite a bit more explicit. Interesting. I can't think of a reason not to support such a method, although I have a vague notion that it might be bad in some circumstances. I'll update the draft to allow this behavior. Thanks, -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 10:23:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5688328C1C4; Thu, 9 Jul 2009 10:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.649 X-Spam-Level: ** X-Spam-Status: No, score=2.649 tagged_above=-999 required=5 tests=[AWL=2.376, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QZ0FIpfVu3K; Thu, 9 Jul 2009 10:23:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FAF53A6D1C; Thu, 9 Jul 2009 10:23:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOxIQ-0008II-Nx for namedroppers-data0@psg.com; Thu, 09 Jul 2009 17:20:34 +0000 Received: from [204.235.121.150] (helo=pblpas02.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOxID-0008F6-RO for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 17:20:28 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="430652476" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 09 Jul 2009 13:20:21 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 13:19:44 -0400 Received: from pblpas02.twcable.com ([204.235.121.150]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 08:17:50 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikDAFcrVEqTHAA+kWdsb2JhbACBS4ktjhYBAQEBCQsKBxMFty2ECAWBOoIo X-IronPort-AV: E=Sophos;i="4.42,368,1243828800"; d="scan'208";a="430198884" Received: from psg.com ([147.28.0.62]) by pblpas02.twcable.com with ESMTP; 08 Jul 2009 08:17:50 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOVh1-000OPU-1h for namedroppers-data0@psg.com; Wed, 08 Jul 2009 11:52:07 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOVgq-000OON-1h for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 11:52:01 +0000 Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MOVgm-0007mc-IB; Wed, 08 Jul 2009 12:51:52 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MOVgm-0005MQ-2f; Wed, 08 Jul 2009 12:51:52 +0100 Message-ID: <90B3E3981C064F7F91CDDE7374CED407@localhost> From: "George Barwood" To: "Michael Graff" Cc: "IETF DNSEXT WG" References: <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> <4A5440A4.2050203@isc.org> <3482744445FC4DB9999AC42A2E96714D@localhost> <4A546249.5050302@isc.org> Subject: Re: [dnsext] Name server agility with DNSSEC Date: Wed, 8 Jul 2009 12:51:50 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original List-ID: X-OriginalArrivalTime: 08 Jul 2009 12:17:50.0053 (UTC) FILETIME=[1C524150:01C9FFC6] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Michael Graff" To: "George Barwood" Cc: "IETF DNSEXT WG" Sent: Wednesday, July 08, 2009 10:09 AM Subject: Re: [dnsext] Name server agility with DNSSEC > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > George Barwood wrote: > > You say this... > >> No state exists on the server, that is the point, yes. > > And then you say this: > >> The server does have to maintain version information though, so it's not >> 100% magic. > > That, to me, is state. How long would it maintain version information > for? How is this sufficiently different than maintaining TCP state for > a short time? This is not state on a per client basis, it's global. It's tracking when the DNS data changes ( due to dynamic updates, AXFR/IXFR etc. ) This is needed so that the client knows it has got a consistent set of pages. A single global 32 bit integer is probably adequate if updates are infrequent. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 10:49:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE393A6AEF; Thu, 9 Jul 2009 10:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-1.403, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-ilfvL+s1Xt; Thu, 9 Jul 2009 10:49:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56E5128C268; Thu, 9 Jul 2009 10:49:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOxdq-000Bi9-Mm for namedroppers-data0@psg.com; Thu, 09 Jul 2009 17:42:42 +0000 Received: from [204.235.121.149] (helo=pblpas01.twcable.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOxci-000BWv-EV for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 17:41:55 +0000 X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,374,1243828800"; d="scan'208";a="431589117" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 09 Jul 2009 13:41:31 -0400 Received: from mail pickup service by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC; Thu, 9 Jul 2009 13:41:00 -0400 Received: from pblpas02.twcable.com ([204.235.121.150]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 08:56:51 -0400 X-SENDER-IP: 147.28.0.62 X-SENDER-REPUTATION: 4.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoABALc0VEqTHAA+kWdsb2JhbACDAZYNAQEBAQkLCgcTBbc+hAgFgTqCKA X-IronPort-AV: E=Sophos;i="4.42,368,1243828800"; d="scan'208";a="430208926" Received: from psg.com ([147.28.0.62]) by pblpas02.twcable.com with ESMTP; 08 Jul 2009 08:56:51 -0400 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOWLW-00037s-I4 for namedroppers-data0@psg.com; Wed, 08 Jul 2009 12:33:58 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOWLL-00036m-CL for namedroppers@ops.ietf.org; Wed, 08 Jul 2009 12:33:52 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id ECC279558E; Wed, 8 Jul 2009 14:33:44 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id A5168157611; Wed, 8 Jul 2009 14:30:46 +0200 (CEST) Date: Wed, 8 Jul 2009 14:30:46 +0200 From: Stephane Bortzmeyer To: Jim Reid Cc: lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: [dnsext] Re: a new EDNS feature for draft-li-dnsext-ipv4-ipv6-00.txt Message-ID: <20090708123046.GD24439@laperouse.bortzmeyer.org> References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <4F57F3F7-AA72-4E81-8F67-F01A2EA4E087@rfc1035.com> <200907081040.n68Ae7Xs034194@drugs.dv.isc.org> <335311FE-7E3C-4737-8915-D0C54CDAD537@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <335311FE-7E3C-4737-8915-D0C54CDAD537@rfc1035.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) List-ID: X-OriginalArrivalTime: 08 Jul 2009 12:56:51.0561 (UTC) FILETIME=[8FF80590:01C9FFCB] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 08, 2009 at 11:49:02AM +0100, Jim Reid wrote a message of 7 lines which said: > dig @a0.org.afilias-nst.info org nsec3 +dnssec seems to work > reasonably well even though the NSEC3 RR is in the Authority > Section. :-) It should not :-) RFC 5155, 7.2.8, "Responding to Queries for NSEC3 Owner Names" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Jul 9 16:37:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F5B3A6D3F; Thu, 9 Jul 2009 16:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-WHQKrdvKZn; Thu, 9 Jul 2009 16:37:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67DB03A69B6; Thu, 9 Jul 2009 16:37:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP32p-000PIb-CZ for namedroppers-data0@psg.com; Thu, 09 Jul 2009 23:28:51 +0000 Received: from [216.168.239.75] (helo=osprey.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP32a-000PH3-SL for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 23:28:45 +0000 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n69NGWci013371 for ; Thu, 9 Jul 2009 19:16:32 -0400 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 00:28:34 +0100 Received: from [10.131.29.40] ([10.131.29.40]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 19:28:34 -0400 Message-Id: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> From: David Blacka To: namedroppers@ops.ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-46-439458558; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] dnssec-bis-updates question #1 Date: Thu, 9 Jul 2009 19:28:34 -0400 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Jul 2009 23:28:34.0436 (UTC) FILETIME=[FA418440:01CA00EC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-46-439458558 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit In trying to get -09 out, I've come up with a few things that I think need clarification. Here is the first one. In dnssec-bis-updates-08 (and many earlier versions) section 3.3 (Check for CNAME) says: Section 5 of [RFC4035] says little about validating responses based on (or that should be based on) CNAMEs. When validating a NOERROR/ NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap. If the CNAME bit is set, the validator MUST validate the CNAME RR and follow it, as appropriate. This paragraph, when I read it closely, doesn't make any sense to me. The second sentence is talking about validating a NOERROR/NODATA response. But the third sentence says "MUST validate the CNAME RR and follow it..." What CNAME RR? If there was a CNAME present, then the response wasn't a NOERROR/NODATA response, right? I *think* that the general idea here is to make sure that someone didn't take a CNAME response and turn it into a NODATA. This is a situation that a validator might miss because it will check the original qtype and forget to check for the CNAME bit in the NSEC record. But if it gets such a case, then the only recourse is to consider the response bogus. My suggested replacement text: Section 4 of [RFC4035] says little about validating responses based on (or that should be based on) CNAMEs. When validating a NOERROR/ NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the bit for the query type. Without this check, an attacker could successfully transform a positive CNAME response into a NOERROR/NODATA response. Is this better? I am assuming that we don't need to clarify the validation of a positive CNAME response even though RFC 4035's section 5 doesn't really explicitly address it. -- David Blacka Sr. Engineer VeriSign Platform Product Development --Apple-Mail-46-439458558 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcDCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBk4wggU2oAMCAQICEFlESltAaqYwh1BuJmTypIAwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0wOTA0MTUwMDAwMDBaFw0xMDA0MTUwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMJF5/YeA95kbx4bUSDqFnlh1w2cBRUWJBXoYOYxaWzzT5vH MutLNO6oCmbl+R8dZoR2QgOPLhtxQEgr0bryxv2yOiRPJ4t+yZCdow7LPfvtjwSiMMn5d+EgSQ0Q 7VkMwXDA5s4JMf5FT9nB1SER9hJZd9nEJ0FfR1yWPYbj+AMT7LtcuVVz4I7uAPwQo66kYlUMxLZM Mh/DvOE/O10W3/M/I+NDbj9Cp6gkTuCK+It6E5HfumFKJsHDMqA+hwcAPtK/aFMGM2nSmr4bFTB7 ooYFIWedG2+lS73JdbLow8vk9sxbSrGGkOivZYIHWg7H3vouIuqfMvVuW5sKUTMJDkcCAwEAAaOC AqYwggKiMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1 MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwDQYJ KoZIhvcNAQEFBQADggEBAK3/93oCO1EhAYcff6uSUu9RT7MiBM1okOvJcpLH28NVeXBs2/ugeCV9 t/DfHUTBPG4yje39rT+F4uN3aOhW9iGzz7m8Bq7OcWIjtWhP465FSsnbq5O+Jvmuc6rwOG8qKTDd W1RJ9MMQ3tVnWkDbM3UNFvEu8qw86noZ3C2seAX6CyBACwpMh331pu1WD2v9Dxzj1EtyKCBMPMVb pKwlQHrcHS6vOcmfmX6HZ9A4JhVGzPz5D9fbCTz7GsBjcCFuvfQqoJwXCoDq6E0kHMvihtppC6WU yzlhNTiJvoQ7+SPRmw6dYyZN6X1ZYhOOuywJWzXEFGR70B/w2wTmzX2wwQ4xggQCMIID/gIBATCB xTCBsDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEqMCgGA1UEAxMhVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQSAtIEczAhBZREpbQGqmMIdQbiZk8qSAMAkGBSsOAwIaBQCgggIRMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDcwOTIzMjgzNFowIwYJKoZIhvcNAQkEMRYE FD7rcjUqlYMbc+g9+//jwD2cHQkkMIHWBgkrBgEEAYI3EAQxgcgwgcUwgbAxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQWURKW0Bq pjCHUG4mZPKkgDCB2AYLKoZIhvcNAQkQAgsxgciggcUwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UE CxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAo BgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQWURKW0BqpjCHUG4mZPKk gDANBgkqhkiG9w0BAQEFAASCAQCrXfX/FREjP20x3S1WG0nIgKh84WKkqcyJq0rb4Wp2iEp6ms2t KxCuLMLXHvkE+uAuypwh199z1v8bjVgy/FQ0D942cy+P/CGd/Bm4bW2B3lvPYSe+vyXW1RSrOAI0 UKkFA0CxT63q4wClIrz6t58n0TzK3+VMUov5Y8+D+y/ZW/7uiwY45SGFqT+w9pbidzY1jVQAtaks b0KzzS8y55z70eWjKz88OjHCw6/cZC32ZReImwPs3hbtYtet0kkm0rFbq+B+vMhbUhF7p6ISE3Oi dfjPiXhVp6ylBp3aO9kOuThDKAtYbzusAG0v2mFNpfaIXGm0QEvFdwtNk5cSvZAUAAAAAAAA --Apple-Mail-46-439458558-- -- to unsubscribe send a message to namedroppers-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 Jul 9 16:40:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D635A3A69B6; Thu, 9 Jul 2009 16:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, MANGLED_PRBLMS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHEyTB4H8Pol; Thu, 9 Jul 2009 16:40:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 073613A6925; Thu, 9 Jul 2009 16:40:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP3BV-0000C5-JQ for namedroppers-data0@psg.com; Thu, 09 Jul 2009 23:37:49 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP3BC-0000Av-3Z for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 23:37:42 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 3C7D6E6070; Thu, 9 Jul 2009 23:37:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n69NbOha065522; Fri, 10 Jul 2009 09:37:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907092337.n69NbOha065522@drugs.dv.isc.org> To: Jelte Jansen Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) In-reply-to: Your message of "Thu, 09 Jul 2009 11:27:54 +0200." <4A55B81A.2030803@NLnetLabs.nl> Date: Fri, 10 Jul 2009 09:37:24 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <4A55B81A.2030803@NLnetLabs.nl>, Jelte Jansen writes: > Andrew Sullivan wrote: > > On Wed, Jul 08, 2009 at 12:45:53PM +0200, Shane Kerr wrote: > > > >> The current style of DNS standards work seems to be that we have a > >> number of people working full-time on DNS stuff, and occasionally they > >> think of something that should be standardized, so when they have a few > >> moments they write something down and present it to the dnsext working > >> group. This seems to work pretty good (except for the huge mass of > >> confusing RFCs, hopefully an effort to fix that will arise again some > >> day). > > > > Well, the last effort was undertaken as a planned attack on the > > overall problem. It failed because we didn't get text. It could be, > > however, that a less centrally-planned effort would work. If someone > > were to write a "DNS Guide to the Perplexed" as an I-D and just ask > > for comments, perhaps it would bear fruit. > > > > Everytime this issue comes up I'm wondering where we got so deep into the RFC > > model that we are actually discussing writing a new RFC to counter the proble > m > of having too many RFCs... > > My general issue with that still stands; the DNS-in-a-nutshell RFC will be > outdated as soon as dns-I'm-still-alive-ext publishes a new extension. It's w > hat > we do, and despite multiple attempts to kill the working group, no hero has > succeeded yet. The update for Nutshell will be an RFC itself, effectively > multiplying the DNS RFC growth rate. > > Not that I'm against the effort; and overview of DNS in it's current state, w > ith > references to the myriad of RFCs and other known extensions/exceptions, would > be > fantastic. But IMHO it would be better implemented as either a website or a > non-RFC publication. And it would only be useful if actually kept up-to-date. This sounds like a excellent plan. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 16:58:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428AA3A6842; Thu, 9 Jul 2009 16:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.324 X-Spam-Level: X-Spam-Status: No, score=-5.324 tagged_above=-999 required=5 tests=[AWL=-0.887, 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 B1nJHG1R6Nvy; Thu, 9 Jul 2009 16:58:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49E3C3A6A37; Thu, 9 Jul 2009 16:58:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP3Re-0001j5-Vs for namedroppers-data0@psg.com; Thu, 09 Jul 2009 23:54:30 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP3RT-0001hi-7k for namedroppers@ops.ietf.org; Thu, 09 Jul 2009 23:54:25 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id A46E3A94442; Thu, 9 Jul 2009 23:54:18 +0000 (UTC) From: Douglas Otis To: George Barwood In-Reply-To: <3482744445FC4DB9999AC42A2E96714D@localhost> Subject: Re: [dnsext] Name server agility with DNSSEC X-Priority: 3 References: <72CE0A0D4D644A599AD7ABB6A169157B@localhost> <86172.1246814309@nsa.vix.com> <87ljn2oqrk.fsf@mid.deneb.enyo.de> <87zlbin9np.fsf@mid.deneb.enyo.de> <200907052342.n65NgHtY092827@drugs.dv.isc.org> <4A526415.1050701@isc.org> <81CBF748AE054E5A84E13D23F2D25ECE@localhost> <4A539E22.20404@isc.org> <200907080154.n681rxNQ029157@drugs.dv.isc.org> <4A5440A4.2050203@isc.org> <3482744445FC4DB9999AC42A2E96714D@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 16:54:17 -0700 Cc: "Michael Graff" , "IETF DNSEXT WG" X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 8, 2009, at 1:08 AM, George Barwood wrote: >> I, for one, don't think we need to reinvent protocols here. SCTP >> is perhaps a good idea since it appears to scale down to something >> very close to UDP if desired. > > I haven't studied SCTP closely, but it seems quite similar to TCP, > so I suspect it will suffer from the same problem inherent in any > connection-oriented protocol, which will always have state. SCTP is not dependent upon unspecified auxiliary defensives such as those offered in firewalls that defend resource commitment from spoofed IP addresses. SCTP simplifies message handling by offering header alignment to facilitate partial message placement, and PR-SCTP can delegate message loss recovery to that of the client. TCP resource exhaustion mitigation at the application would likely be limited to controlling resources that are in the established state, although several other states can strand resources. Auxiliary TCP defensive strategies normally are aimed at protecting the OS, and not at retaining a fair minimum, which would be desired for a critical service. Importantly, SCTP/53 does not prevent UDP/53 from functioning, but SCTP should have priority. >> Paginating a UDP response seems like a hack and is just as likely >> to be rejected by the very devices you are attempting to bypass, >> that of a broken filtering gateway. > > I don't think there is any evidence for this, it semes unlikely. The > packets are properly formatted, I doubt a gateway would be > inspecting EDNS option records. This needs further review with respect potential exploits that might be enabled. A global state determining the version does not offer much protection when not used with DNSSEC. Perhaps this scheme would expect query information be repeated in each packet? Eventually, this approach might arrive at being fairly similar to that of SCTP. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 17:07:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6E73A6D42; Thu, 9 Jul 2009 17:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.159 X-Spam-Level: X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CDezWTAjHwm; Thu, 9 Jul 2009 17:07:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 835803A6D3F; Thu, 9 Jul 2009 17:07:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP3b7-0002fB-F8 for namedroppers-data0@psg.com; Fri, 10 Jul 2009 00:04:17 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP3Zr-0002Wd-Pp for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 00:03:29 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 72F62A94442; Fri, 10 Jul 2009 00:02:59 +0000 (UTC) Cc: namedroppers@ops.ietf.org Message-Id: <157BB002-7FDF-4E86-87A3-950B2CCDF549@mail-abuse.org> From: Douglas Otis To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) Date: Thu, 9 Jul 2009 17:02:59 -0700 References: <4A53B6BD.9060905@necom830.hpcl.titech.ac.jp> <1247048045.3922.19886.camel@shane-asus-laptop> <4A54A93B.3030508@necom830.hpcl.titech.ac.jp> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 8, 2009, at 9:29 AM, Ond=C5=99ej Sur=C3=BD wrote: > [resent since Trend Micro blocked first try] Unless this represents an older transfer list service, as a customer =20 selectable option, there is a less aggressive list available that =20 normally does not affect gmail. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 20:12:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF423A6CAF; Thu, 9 Jul 2009 20:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf4YeHTYegKP; Thu, 9 Jul 2009 20:12:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 256C43A6B1E; Thu, 9 Jul 2009 20:12:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP6SB-000Kfw-4X for namedroppers-data0@psg.com; Fri, 10 Jul 2009 03:07:15 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP6Rr-000Kcq-Oc for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 03:07:01 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8DFA7E609F; Fri, 10 Jul 2009 03:06:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6A2sgsn067902; Fri, 10 Jul 2009 12:54:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907100254.n6A2sgsn067902@drugs.dv.isc.org> To: Florian Weimer Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org From: Mark Andrews References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt In-reply-to: Your message of "Wed, 08 Jul 2009 08:59:11 GMT." <82ocrv5z4w.fsf@mid.bfk.de> Date: Fri, 10 Jul 2009 12:54:42 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <82ocrv5z4w.fsf@mid.bfk.de>, Florian Weimer writes: > * Stephane Bortzmeyer: > > > On Mon, Jul 06, 2009 at 01:15:01AM -0700, > > Internet-Drafts@ietf.org wrote=20 > > a message of 53 lines which said: > > > >> There are two kinds of TYPE for host IP address: one is A, the other > >> is AAAA, which records IPv4 and IPv6 addresses respectively. This > >> document defines a new TYPE, which is mainly used in queries in > >> order to get both IPv4 and IPv6 addresses. > > > > Certainly a good idea and I applaud the effort. But I vaguely remember > > there was a long time ago a project to have a query type ADDR and that > > it failed, so you may research history of this project to see what was > > the problem. > > Hmm. I don't think I got the original message, and I think I might > already have replied to your message. Oh well. > > Would it help if there was some sort of EDNS0 flag/option which > instructed the server to include an NSEC(3) record for the QNAME, to > reveal which other RR types exist at that name? Which type to query > first could be based on past performance. So you want NXRRSET synthesis in caches? > --=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: > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 21:03:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7C13A6C29; Thu, 9 Jul 2009 21:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40kvkV9BgexR; Thu, 9 Jul 2009 21:03:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C8353A685C; Thu, 9 Jul 2009 21:03:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP7Ge-0000Zg-El for namedroppers-data0@psg.com; Fri, 10 Jul 2009 03:59:24 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP7GR-0000YK-PA for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 03:59:18 +0000 Received: from [192.168.1.109] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6A3x442023872; Thu, 9 Jul 2009 23:59:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> Date: Thu, 9 Jul 2009 23:59:02 -0400 To: David Blacka From: Edward Lewis Subject: Re: [dnsext] dnssec-bis-updates question #1 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: An example of the topic is this (I think it helps sort out the multiple errors in the initial text): $ dig www.neustar.biz hinfo ; <<>> DiG 9.6.1 <<>> www.neustar.biz hinfo ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42989 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.neustar.biz. IN HINFO ;; ANSWER SECTION: www.neustar.biz. 900 IN CNAME neustar.biz. ;; AUTHORITY SECTION: neustar.biz. 900 IN SOA PDNS1.ULTRADNS.NET. sec_grp.neustar.com. 1246888833 10800 3600 604800 600 ;; Query time: 191 msec ;; SERVER: 68.105.28.12#53(68.105.28.12) ;; WHEN: Thu Jul 9 23:15:59 2009 ;; MSG SIZE rcvd: 120 If this were a signed answer, the ANSWER would have www.neustar.biz CNAME neustar.biz RRSIG CNAME AUTHORITY would have this (right?) and maybe a SOA/RRSIG(SOA) neustar.biz NSEC(?) ... not what's asked for ...; or hash(X) for NSEC3 RRSIG NSEC(?) At 19:28 -0400 7/9/09, David Blacka wrote: >In trying to get -09 out, I've come up with a few things that I >think need clarification. Here is the first one. > >In dnssec-bis-updates-08 (and many earlier versions) section 3.3 >(Check for CNAME) says: > > Section 5 of [RFC4035] says little about validating responses based > on (or that should be based on) CNAMEs. When validating a NOERROR/ > NODATA response, validators MUST check the CNAME bit in the matching > NSEC or NSEC3 RR's type bitmap. If the CNAME bit is set, the > validator MUST validate the CNAME RR and follow it, as appropriate. > >This paragraph, when I read it closely, doesn't make any sense to >me. The second sentence is talking about validating a NOERROR/NODATA >response. But the third sentence says "MUST validate the CNAME RR >and follow it..." What CNAME RR? If there was a CNAME present, then >the response wasn't a NOERROR/NODATA response, right? > >I *think* that the general idea here is to make sure that someone >didn't take a CNAME response and turn it into a NODATA. This is a >situation that a validator might miss because it will check the >original qtype and forget to check for the CNAME bit in the NSEC >record. But if it gets such a case, then the only recourse is to >consider the response bogus. > >My suggested replacement text: > > Section 4 of [RFC4035] says little about validating responses based > on (or that should be based on) CNAMEs. When validating a NOERROR/ > NODATA response, validators MUST check the CNAME bit in the matching > NSEC or NSEC3 RR's type bitmap in addition to the bit for the query > type. Without this check, an attacker could successfully transform a > positive CNAME response into a NOERROR/NODATA response. (Sect 4 or 5? I think you meant 5) Section 5 of RFC 4035 says little about validating responses whose answer section contains one or more CNAME RRSets and no RRSet matching the QTYPE. Such responses ought to have a NSEC(?) RRset owned by the name indicated by the last of the CNAME RRSets in the Authority section. In such a response: for each CNAME RRSet in the Answer Section the CNAME RRSet signature MUST be validated, the collection of CNAME RRSets must form a chain, from RDATA of one CNAME RRSet to the owner of the next starting with the QNAME as owner, and the final name of the CNAME "chain" being the NSEC(?) owner in the Authority section. (Sorry, it's a run-on otherwise.) Failure to check these three conditions could result in acceptance of ... an improperly assembled answer. In essence, the validator just has to check the all the usual signatures and that there is no matching TYPE in the NSEC(?) inside the AUTHORITY. Am I missing something? > >Is this better? I think the new wording needs more help, even mine. It's been a long day and it's about midnight here for me. >I am assuming that we don't need to clarify the validation of a >positive CNAME response even though RFC 4035's section 5 doesn't >really explicitly address it. Haven't looked at that. A positive CNAME response is the same as any other positive response. when QTYPE=CNAME, we don't "chase" through CNAME RR Sets, we match CNAME like any other type. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 9 22:24:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E0B3A6D7A; Thu, 9 Jul 2009 22:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G4oELKDCRkH; Thu, 9 Jul 2009 22:24:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D2633A68FE; Thu, 9 Jul 2009 22:24:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP8W1-0006Vg-MK for namedroppers-data0@psg.com; Fri, 10 Jul 2009 05:19:21 +0000 Received: from [209.86.89.64] (helo=elasmtp-curtail.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MP8Vp-0006UO-1l for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 05:19:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RlRJ1y5A/H7U5Hm4L85ZnGeREUwMZnWCBQQei+3o+OwEDbilLmE9gtpfki6oYERo; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.98.147] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MP8Vd-0003eJ-E2; Fri, 10 Jul 2009 01:19:05 -0400 Message-ID: <4A56CF28.706099D8@ix.netcom.com> Date: Thu, 09 Jul 2009 22:18:33 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: David Blacka , namedroppers@ops.ietf.org Subject: Re: [dnsext] dnssec-bis-updates question #1 References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688ea7e544e56415359bb63e7dab84be6a2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.98.147 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ed and all, Also not unsurprisingly neustar.biz has some other DNS problems as well. See: http://www.dnsstuff.com/tools/dnsreport?domain=neustar.biz&token=05308c03c7e974de2751ce970e090010 Edward Lewis wrote: > An example of the topic is this (I think it helps sort out the > multiple errors in the initial text): > > $ dig www.neustar.biz hinfo > > ; <<>> DiG 9.6.1 <<>> www.neustar.biz hinfo > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42989 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.neustar.biz. IN HINFO > > ;; ANSWER SECTION: > www.neustar.biz. 900 IN CNAME neustar.biz. > > ;; AUTHORITY SECTION: > neustar.biz. 900 IN SOA PDNS1.ULTRADNS.NET. > sec_grp.neustar.com. 1246888833 10800 3600 604800 600 > > ;; Query time: 191 msec > ;; SERVER: 68.105.28.12#53(68.105.28.12) > ;; WHEN: Thu Jul 9 23:15:59 2009 > ;; MSG SIZE rcvd: 120 > > If this were a signed answer, the ANSWER would have > > www.neustar.biz CNAME neustar.biz > RRSIG CNAME > > AUTHORITY would have this (right?) and maybe a SOA/RRSIG(SOA) > > neustar.biz NSEC(?) ... not what's asked for ...; or hash(X) for NSEC3 > RRSIG NSEC(?) > > At 19:28 -0400 7/9/09, David Blacka wrote: > >In trying to get -09 out, I've come up with a few things that I > >think need clarification. Here is the first one. > > > >In dnssec-bis-updates-08 (and many earlier versions) section 3.3 > >(Check for CNAME) says: > > > > Section 5 of [RFC4035] says little about validating responses based > > on (or that should be based on) CNAMEs. When validating a NOERROR/ > > NODATA response, validators MUST check the CNAME bit in the matching > > NSEC or NSEC3 RR's type bitmap. If the CNAME bit is set, the > > validator MUST validate the CNAME RR and follow it, as appropriate. > > > >This paragraph, when I read it closely, doesn't make any sense to > >me. The second sentence is talking about validating a NOERROR/NODATA > >response. But the third sentence says "MUST validate the CNAME RR > >and follow it..." What CNAME RR? If there was a CNAME present, then > >the response wasn't a NOERROR/NODATA response, right? > > > >I *think* that the general idea here is to make sure that someone > >didn't take a CNAME response and turn it into a NODATA. This is a > >situation that a validator might miss because it will check the > >original qtype and forget to check for the CNAME bit in the NSEC > >record. But if it gets such a case, then the only recourse is to > >consider the response bogus. > > > >My suggested replacement text: > > > > Section 4 of [RFC4035] says little about validating responses based > > on (or that should be based on) CNAMEs. When validating a NOERROR/ > > NODATA response, validators MUST check the CNAME bit in the matching > > NSEC or NSEC3 RR's type bitmap in addition to the bit for the query > > type. Without this check, an attacker could successfully transform a > > positive CNAME response into a NOERROR/NODATA response. > > (Sect 4 or 5? I think you meant 5) > > Section 5 of RFC 4035 says little about validating responses whose answer > section contains one or more CNAME RRSets and no RRSet matching the > QTYPE. Such responses ought to have a NSEC(?) RRset owned by the > name indicated by the last of the CNAME RRSets in the Authority > section. > > In such a response: > for each CNAME RRSet in the Answer Section the CNAME RRSet signature > MUST be validated, > > the collection of CNAME RRSets must form a chain, from RDATA of one > CNAME RRSet to the owner of the next starting with the QNAME as owner, > > and the final name of the CNAME "chain" being the NSEC(?) owner in > the Authority section. > > (Sorry, it's a run-on otherwise.) Failure to check these three > conditions could result in acceptance of ... an improperly assembled > answer. > > In essence, the validator just has to check the all the usual > signatures and that there is no matching TYPE in the NSEC(?) inside > the AUTHORITY. > > Am I missing something? > > > > >Is this better? > > I think the new wording needs more help, even mine. It's been a long > day and it's about midnight here for me. > > >I am assuming that we don't need to clarify the validation of a > >positive CNAME response even though RFC 4035's section 5 doesn't > >really explicitly address it. > > Haven't looked at that. A positive CNAME response is the same as any > other positive response. when QTYPE=CNAME, we don't "chase" through > CNAME RR Sets, we match CNAME like any other type. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless surfaces is > that they're not getting traction. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 10 00:20:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187A73A67ED; Fri, 10 Jul 2009 00:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 W+5nX4ySjDcJ; Fri, 10 Jul 2009 00:20:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B81F3A6B4F; Fri, 10 Jul 2009 00:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPAKN-000HA7-RK for namedroppers-data0@psg.com; Fri, 10 Jul 2009 07:15:27 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPAKB-000H6n-Ad for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 07:15:21 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MPANW-0005rV-LQ; Fri, 10 Jul 2009 09:18:42 +0200 Received: by bfk.de with local id 1MPAK2-0001pW-JS; Fri, 10 Jul 2009 07:15:06 +0000 To: Mark Andrews Cc: Stephane Bortzmeyer , lilianyuan@chinamobile.com, lizhenqiang@chinamobile.com, duanxiaodong@chinamobile.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt References: <20090706081501.530263A6B0A@core3.amsl.com> <20090706095144.GB25939@nic.fr> <82ocrv5z4w.fsf@mid.bfk.de> <200907100254.n6A2sgsn067902@drugs.dv.isc.org> From: Florian Weimer Date: Fri, 10 Jul 2009 07:15:06 +0000 In-Reply-To: <200907100254.n6A2sgsn067902@drugs.dv.isc.org> (Mark Andrews's message of "Fri\, 10 Jul 2009 12\:54\:42 +1000") Message-ID: <82my7duhz9.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Mark Andrews: >> Would it help if there was some sort of EDNS0 flag/option which >> instructed the server to include an NSEC(3) record for the QNAME, to >> reveal which other RR types exist at that name? Which type to query >> first could be based on past performance. > > So you want NXRRSET synthesis in caches? Sure. It's the only way to throttle junk queries. --=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 Jul 10 04:54:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622563A6E28; Fri, 10 Jul 2009 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn0Shm0d6ROG; Fri, 10 Jul 2009 04:54:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6AB763A6939; Fri, 10 Jul 2009 04:53:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPEZD-000Law-9r for namedroppers-data0@psg.com; Fri, 10 Jul 2009 11:47:03 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPEZ1-000LZc-KC for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 11:46:57 +0000 Received: from [192.168.1.14] (pool-96-231-164-92.washdc.fios.verizon.net [96.231.164.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id 7D51B13668C; Fri, 10 Jul 2009 07:46:49 -0400 (EDT) Cc: namedroppers@ops.ietf.org Message-Id: <165C17D2-48A2-4DA9-BC53-BD6A797CA534@verisign.com> From: "Blacka, David" To: Edward Lewis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] dnssec-bis-updates question #1 Date: Fri, 10 Jul 2009 07:46:48 -0400 References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 9, 2009, at 11:59 PM, Edward Lewis wrote: >> My suggested replacement text: >> >> Section 4 of [RFC4035] says little about validating responses based >> on (or that should be based on) CNAMEs. When validating a NOERROR/ >> NODATA response, validators MUST check the CNAME bit in the matching >> NSEC or NSEC3 RR's type bitmap in addition to the bit for the query >> type. Without this check, an attacker could successfully >> transform a >> positive CNAME response into a NOERROR/NODATA response. > > (Sect 4 or 5? I think you meant 5) 5. This is what I get for not cutting and pasting... > Section 5 of RFC 4035 says little about validating responses whose > answer > section contains one or more CNAME RRSets and no RRSet matching the > QTYPE. Such responses ought to have a NSEC(?) RRset owned by the > name indicated by the last of the CNAME RRSets in the Authority > section. > > In such a response: > for each CNAME RRSet in the Answer Section the CNAME RRSet > signature > MUST be validated, > > the collection of CNAME RRSets must form a chain, from RDATA of one > CNAME RRSet to the owner of the next starting with the QNAME as > owner, > > and the final name of the CNAME "chain" being the NSEC(?) owner in > the Authority section. > > (Sorry, it's a run-on otherwise.) Failure to check these three > conditions could result in acceptance of ... an improperly assembled > answer. > > In essence, the validator just has to check the all the usual > signatures and that there is no matching TYPE in the NSEC(?) inside > the AUTHORITY. > > Am I missing something? I think you are misreading the original intent of this section of dnssec-bis-updates (or maybe I am). From my reading, the intent was to address a common (or presumed to be common) validator error. I am thinking that you think it was about how to validate responses with CNAMEs in general, right? >> >> Is this better? > > I think the new wording needs more help, even mine. It's been a > long day and it's about midnight here for me. > >> I am assuming that we don't need to clarify the validation of a >> positive CNAME response even though RFC 4035's section 5 doesn't >> really explicitly address it. > > Haven't looked at that. A positive CNAME response is the same as > any other positive response. when QTYPE=CNAME, we don't "chase" > through CNAME RR Sets, we match CNAME like any other type. No, what I meant by "positive CNAME response" wasn't a response to a qtype=CNAME query, but what you actually describe above. That is, a response containing one or more CNAMEs that do not terminate in a final answer. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless > surfaces is > that they're not getting traction. -- David Blacka Sr. Engineer Platform Product Development -- to unsubscribe send a message to namedroppers-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 Jul 10 05:36:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B5D3A7063; Fri, 10 Jul 2009 05:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEz82CMMLeKn; Fri, 10 Jul 2009 05:36:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EBC63A7068; Fri, 10 Jul 2009 05:36:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPFGD-0000mk-Pc for namedroppers-data0@psg.com; Fri, 10 Jul 2009 12:31:29 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPFFy-0000kG-Ph for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 12:31:23 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6ACVBo4013829; Fri, 10 Jul 2009 05:31:11 -0700 (PDT) Cc: Nicholas Weaver , Edward Lewis , David Blacka , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: "Jeffrey A. Williams" In-Reply-To: <4A56CF28.706099D8@ix.netcom.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] dnssec-bis-updates question #1 Date: Fri, 10 Jul 2009 05:31:11 -0700 References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> <4A56CF28.706099D8@ix.netcom.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 9, 2009, at 10:18 PM, Jeffrey A. Williams wrote: > Ed and all, > > Also not unsurprisingly neustar.biz has some other DNS > problems as well. See: > http://www.dnsstuff.com/tools/dnsreport?domain=neustar.biz&token=05308c03c7e974de2751ce970e090010 The first warning is bogus: its complaining that the .biz GTLD is not giving glue records for the nameservers, which are: neustar.biz. 900 IN NS PDNS5.ULTRADNS.INFO. neustar.biz. 900 IN NS PDNS6.ULTRADNS.CO.UK. neustar.biz. 900 IN NS PDNS1.ULTRADNS.NET. neustar.biz. 900 IN NS PDNS2.ULTRADNS.NET. neustar.biz. 900 IN NS PDNS3.ULTRADNS.ORG. neustar.biz. 900 IN NS PDNS4.ULTRADNS.ORG. out of bailywick completely for the .biz gtld, and returning those would be pointless because no nameserver should accept it. The second warning is bogus: it simply goes "Oh, there's no glue, so I can't say a thing...", when it actually did do a lookup. -- to unsubscribe send a message to namedroppers-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 Jul 10 07:25:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC893A6AAF; Fri, 10 Jul 2009 07:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imAFT2hhZWc4; Fri, 10 Jul 2009 07:25:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D58B28C35A; Fri, 10 Jul 2009 07:24:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPGxA-000Jd0-Ki for namedroppers-data0@psg.com; Fri, 10 Jul 2009 14:19:56 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPGwx-000JbS-0Z for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 14:19:50 +0000 Received: from [10.31.200.146] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6AEJZGU029259; Fri, 10 Jul 2009 10:19:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <165C17D2-48A2-4DA9-BC53-BD6A797CA534@verisign.com> References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> <165C17D2-48A2-4DA9-BC53-BD6A797CA534@verisign.com> Date: Fri, 10 Jul 2009 10:19:33 -0400 To: "Blacka, David" From: Edward Lewis Subject: Re: [dnsext] dnssec-bis-updates question #1 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-964886919==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-964886919==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:46 -0400 7/10/09, Blacka, David wrote: >I think you are misreading the original intent of this section of >dnssec-bis-updates (or maybe I am). From my reading, the intent was >to address a common (or presumed to be common) validator error. I >am thinking that you think it was about how to validate responses >with CNAMEs in general, right? > Here's the "offending text" (again) as it is in -08: 3.3. Check for CNAME Section 5 of [RFC4035] says little about validating responses based on (or that should be based on) CNAMEs. When validating a NOERROR/ NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap. If the CNAME bit is set, the validator MUST validate the CNAME RR and follow it, as appropriate. The issue is, as seen in the example dig I used last night, is that if you are validating a NoError/NoData response there won't be any CNAME RRSets present in the reply. The language in 3.3 is imprecise to the point of nothing-but-jargon. "NoError/NoData" mean that the RCODE field is 0 and the ANCOUNT is 0. Reading RFC 1034, my fav section 4.3.2 (the algorithm for responding servers): If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. So, each time you see a CNAME on the path to resolution, you copy it into the answer section (thus ANCOUNT++) If you run across the need to synthesize from a wild card name match (per RFC 4592's update): If the data at the source of synthesis is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response changing the owner name to the QNAME, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Again ANCOUNT++ Finally, if you get to a name without a CNAME, you apply this rule: Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. and step 6: 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. The "copy all RRs (sets) which match QTYPE" might mean copy zero RR sets. So, there's no difference in the answer section of a response whether there is matching data or not. All differences are in the authority section. What's missing from the discussion is found in RFC 2308 (NCACHE): "QNAME" - the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME. The last CNAME in this sense is that which contains a value which does not resolve to another CNAME. Implementations should note that including CNAME records in responses in order, so that the first has the label from the query section, and then each in sequence has the label from the data section of the previous (where more than one CNAME is needed) allows the sequence to be processed in one pass, and considerably eases the task of the receiver. Other relevant records (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs. and (relating to NXDOMAIN, included for completeness): Name errors (NXDOMAIN) are indicated by the presence of "Name Error" in the RCODE field. In this case the domain referred to by the QNAME does not exist. Note: the answer section may have SIG and CNAME RRs and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. and NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section. The authority section will contain an SOA record, or there will be no NS records there. NODATA responses have to be algorithmically determined from the response's contents as there is no RCODE value to indicate NODATA. In some cases to determine with certainty that NODATA is the correct response it can be necessary to send another query. The authority section may contain NXT and SIG RRsets in addition to NS and SOA records. CNAME and SIG records may exist in the answer section. Ok, so in 2308 "NODATA" does not mean ANCOUNT==0, rather that there is no relevant response RR Set. And it defines what goes into the authority section (SOA, no NS). What 3.3 should be conveying is that it is important for the validator to validate all relevant records AND check that the process as described above is followed. I.e., check the CNAME RR set signatures and that they do form a chain. This is true whether it is a NoError/NoData response, a NoError/withData response, NXDOMAIN response, or a CNAME-leading-to-a-referal response/condition. Same basic idea for DNAME validation and treatment of the DNAME-synthezized CNAME (as opposed to a wild card synthesized CNAME). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-964886919==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] dnssec-bis-updates question #1
At 7:46 -0400 7/10/09, Blacka, David wrote:

>I think you are misreading the original intent of this section of dnssec-bis-updates (or maybe I am).  From my reading, the intent was to address a common (or presumed to be common) validator error.  I am thinking that you think it was about how to validate responses with CNAMEs in general, right?
>

Here's the "offending text" (again) as it is in -08:

3.3.  Check for CNAME

   Section 5 of [RFC4035] says little about validating responses based
   on (or that should be based on) CNAMEs.  When validating a NOERROR/
   NODATA response, validators MUST check the CNAME bit in the matching
   NSEC or NSEC3 RR's type bitmap.  If the CNAME bit is set, the
   validator MUST validate the CNAME RR and follow it, as appropriate.
The issue is, as seen in the example dig I used last night, is that if you are validating a NoError/NoData response there won't be any CNAME RRSets present in the reply.  The language in 3.3 is imprecise to the point of nothing-but-jargon.

"NoError/NoData" mean that the RCODE field is 0 and the ANCOUNT is 0.

Reading RFC 1034, my fav section 4.3.2 (the algorithm for responding servers):

            If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

So, each time you see a CNAME on the path to resolution, you copy it into the answer section (thus ANCOUNT++)

If you run across the need to synthesize from a wild card name match (per RFC 4592's update):

      If the data at the source of synthesis is a CNAME, and QTYPE
      doesn't match CNAME, copy the CNAME RR into the answer section of
      the response changing the owner name to the QNAME, change QNAME to
      the canonical name in the CNAME RR, and go back to step 1.
Again ANCOUNT++

Finally, if you get to a name without a CNAME, you apply this rule:

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.
and step 6:
   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.
The "copy all RRs (sets) which match QTYPE" might mean copy zero RR sets.

So, there's no difference in the answer section of a response whether there is matching data or not.  All differences are in the authority section.

What's missing from the discussion is found in RFC 2308 (NCACHE):

   "QNAME" - the name in the query section of an answer, or where this
   resolves to a CNAME, or CNAME chain, the data field of the last
   CNAME.  The last CNAME in this sense is that which contains a value
   which does not resolve to another CNAME.  Implementations should note
   that including CNAME records in responses in order, so that the first
   has the label from the query section, and then each in sequence has
   the label from the data section of the previous (where more than one
   CNAME is needed) allows the sequence to be processed in one pass, and
   considerably eases the task of the receiver.  Other relevant records
   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
and (relating to NXDOMAIN, included for completeness):

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

   NODATA is indicated by an answer with the RCODE set to NOERROR and no
   relevant answers in the answer section.  The authority section will
   contain an SOA record, or there will be no NS records there.

   NODATA responses have to be algorithmically determined from the
   response's contents as there is no RCODE value to indicate NODATA.
   In some cases to determine with certainty that NODATA is the correct
   response it can be necessary to send another query.

   The authority section may contain NXT and SIG RRsets in addition to
   NS and SOA records.  CNAME and SIG records may exist in the answer
   section.
Ok, so in 2308 "NODATA" does not mean ANCOUNT==0, rather that there is no relevant response RR Set.  And it defines what goes into the authority section (SOA, no NS).

What 3.3 should be conveying is that it is important for the validator to validate all relevant records AND check that the process as described above is followed.  I.e., check the CNAME RR set signatures and that they do form a chain.  This is true whether it is a NoError/NoData response, a NoError/withData response, NXDOMAIN response, or a CNAME-leading-to-a-referal response/condition.

Same basic idea for DNAME validation and treatment of the DNAME-synthezized CNAME (as opposed to a wild card synthesized CNAME).

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-964886919==_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 Jul 10 09:08:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B64128C33A; Fri, 10 Jul 2009 09:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZK2k256plv4; Fri, 10 Jul 2009 09:08:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E6A928C2CF; Fri, 10 Jul 2009 09:08:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPIXP-0005uw-Qb for namedroppers-data0@psg.com; Fri, 10 Jul 2009 16:01:27 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPIXD-0005tc-Lw for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 16:01:21 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1E8BF2FE9536 for ; Fri, 10 Jul 2009 16:01:14 +0000 (UTC) Date: Fri, 10 Jul 2009 12:01:12 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] 1st version of agenda for IETF75 Message-ID: <20090710160112.GC735@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, I just posted the agenda for the DNSEXT meeting at IETF75. Please check it to make sure I haven't missed anything. In particular, if you requested a slot please verify that I've put you on. It's posted at http://www.ietf.org/proceedings/09jul/agenda/dnsext.txt. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 10 09:55:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E79F3A690F; Fri, 10 Jul 2009 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aoxc2TJgkJx; Fri, 10 Jul 2009 09:55:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A11BD3A67AD; Fri, 10 Jul 2009 09:55:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPJKC-000BcS-Sd for namedroppers-data0@psg.com; Fri, 10 Jul 2009 16:51:52 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPJJw-000BZv-RG for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 16:51:44 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5FF242FE9536 for ; Fri, 10 Jul 2009 16:51:35 +0000 (UTC) Date: Fri, 10 Jul 2009 12:51:33 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] 1st version of agenda for IETF75 Message-ID: <20090710165133.GD735@shinkuro.com> References: <20090710160112.GC735@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090710160112.GC735@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Fri, Jul 10, 2009 at 12:01:12PM -0400, Andrew Sullivan wrote: > It's posted at > http://www.ietf.org/proceedings/09jul/agenda/dnsext.txt. Someone has pointed out to me that the formatting of that agenda be a little surprising. The times on the agenda are the _end_ times for each item. You can infer the start time of the item from the end time of the previous item. Sorry if this wasn't clear. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 10 10:21:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11ED83A6894; Fri, 10 Jul 2009 10:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pL4ZvDWsudv; Fri, 10 Jul 2009 10:21:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2E163A67AD; Fri, 10 Jul 2009 10:21:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPJjO-000ESL-Jo for namedroppers-data0@psg.com; Fri, 10 Jul 2009 17:17:54 +0000 Received: from [216.168.239.74] (helo=peregrine.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPJj3-000EP9-Bx for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 17:17:43 +0000 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n6AH6WRb017542; Fri, 10 Jul 2009 13:06:34 -0400 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 18:17:28 +0100 Received: from [10.131.29.40] ([10.131.29.40]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 13:17:28 -0400 Cc: namedroppers@ops.ietf.org Message-Id: <47DA5BF2-B756-4036-B884-FD74447A9753@verisign.com> From: David Blacka To: Edward Lewis In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-59-503592270; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] dnssec-bis-updates question #1 Date: Fri, 10 Jul 2009 13:17:27 -0400 References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> <165C17D2-48A2-4DA9-BC53-BD6A797CA534@verisign.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 10 Jul 2009 17:17:28.0129 (UTC) FILETIME=[4CEA7310:01CA0182] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-59-503592270 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 10, 2009, at 10:19 AM, Edward Lewis wrote: > Here's the "offending text" (again) as it is in -08: > > 3.3. Check for CNAME ... > The issue is, as seen in the example dig I used last night, is that > if you are validating a NoError/NoData response there won't be any > CNAME RRSets present in the reply. The language in 3.3 is imprecise > to the point of nothing-but-jargon. Right, which is why I brought this up in the first place. > "NoError/NoData" mean that the RCODE field is 0 and the ANCOUNT is 0. That is the common understanding, yes. [elided description of how CNAME processing is defined in 1034] > So, there's no difference in the answer section of a response > whether there is matching data or not. All differences are in the > authority section. This sentence makes no sense. If there is "matching data", then there is a difference in the answer section, clearly. > What's missing from the discussion is found in RFC 2308 (NCACHE): ... > NODATA is indicated by an answer with the RCODE set to NOERROR > and no > relevant answers in the answer section. The authority section will > contain an SOA record, or there will be no NS records there. ... > Ok, so in 2308 "NODATA" does not mean ANCOUNT==0, rather that there > is no relevant response RR Set. And it defines what goes into the > authority section (SOA, no NS). So, CNAMEs aren't "relevant answers"? Is that what you are saying? I think you are asserting that as long as the CNAME chain in the answer section doesn't terminate in the final answer, the response is still NOERROR/NODATA. This is news to me. > > What 3.3 should be conveying is that it is important for the > validator to validate all relevant records AND check that the > process as described above is followed. I.e., check the CNAME RR > set signatures and that they do form a chain. This is true whether > it is a NoError/NoData response, a NoError/withData response, > NXDOMAIN response, or a CNAME-leading-to-a-referal response/condition. OK, Ed. My point was that the original intent of section 3.3 wasn't to describe this at all. No one (until now) has been complaining that 4035 doesn't adequately describe how to actually validate responses with CNAMEs in them. What I think it is trying to describe is this: Attacker takes this original response: RCODE: NOERROR ;; QUESTION SECTION ;www.example.com. IN AAAA ;; ANSWER SECTION: www.example.com. IN CNAME example.com. www.example.com. IN RRSIG CNAME ... ;; AUTHORITY SECTION: example.com. IN SOA ... example.com. IN RRSIG SOA .. www.example.com IN NSEC x.example.com CNAME RRSIG www.example.com IN RRSIG NSEC ... And turns it into: RCODE: NOERROR ;; QUESTION SECTION ;www.example.com. IN AAAA ;; ANSWER SECTION: ;; AUTHORITY SECTION: example.com. IN SOA ... example.com. IN RRSIG SOA .. www.example.com IN NSEC x.example.com CNAME RRSIG www.example.com IN RRSIG NSEC ... And the naive validator says: This is a NODATA response. OK, I see no AAAA bit in the type map ... OK, great! Secure! So, the advice is to "Check for CNAME". I.e., don't accept this response as Secure because the CNAME bit was set, so there should have been a CNAME. -- David Blacka Sr. Engineer VeriSign Platform Product Development --Apple-Mail-59-503592270 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcDCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBk4wggU2oAMCAQICEFlESltAaqYwh1BuJmTypIAwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0wOTA0MTUwMDAwMDBaFw0xMDA0MTUwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMJF5/YeA95kbx4bUSDqFnlh1w2cBRUWJBXoYOYxaWzzT5vH MutLNO6oCmbl+R8dZoR2QgOPLhtxQEgr0bryxv2yOiRPJ4t+yZCdow7LPfvtjwSiMMn5d+EgSQ0Q 7VkMwXDA5s4JMf5FT9nB1SER9hJZd9nEJ0FfR1yWPYbj+AMT7LtcuVVz4I7uAPwQo66kYlUMxLZM Mh/DvOE/O10W3/M/I+NDbj9Cp6gkTuCK+It6E5HfumFKJsHDMqA+hwcAPtK/aFMGM2nSmr4bFTB7 ooYFIWedG2+lS73JdbLow8vk9sxbSrGGkOivZYIHWg7H3vouIuqfMvVuW5sKUTMJDkcCAwEAAaOC AqYwggKiMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1 MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwDQYJ KoZIhvcNAQEFBQADggEBAK3/93oCO1EhAYcff6uSUu9RT7MiBM1okOvJcpLH28NVeXBs2/ugeCV9 t/DfHUTBPG4yje39rT+F4uN3aOhW9iGzz7m8Bq7OcWIjtWhP465FSsnbq5O+Jvmuc6rwOG8qKTDd W1RJ9MMQ3tVnWkDbM3UNFvEu8qw86noZ3C2seAX6CyBACwpMh331pu1WD2v9Dxzj1EtyKCBMPMVb pKwlQHrcHS6vOcmfmX6HZ9A4JhVGzPz5D9fbCTz7GsBjcCFuvfQqoJwXCoDq6E0kHMvihtppC6WU yzlhNTiJvoQ7+SPRmw6dYyZN6X1ZYhOOuywJWzXEFGR70B/w2wTmzX2wwQ4xggQCMIID/gIBATCB xTCBsDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEqMCgGA1UEAxMhVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQSAtIEczAhBZREpbQGqmMIdQbiZk8qSAMAkGBSsOAwIaBQCgggIRMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDcxMDE3MTcyOFowIwYJKoZIhvcNAQkEMRYE FCrMNC/ucs0Nkv0xKwYtasNsUXb4MIHWBgkrBgEEAYI3EAQxgcgwgcUwgbAxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQWURKW0Bq pjCHUG4mZPKkgDCB2AYLKoZIhvcNAQkQAgsxgciggcUwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UE CxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAo BgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQWURKW0BqpjCHUG4mZPKk gDANBgkqhkiG9w0BAQEFAASCAQCNt9BcXPVr/vmZ8U0m8nDpgR9qDN6SxyawnFHmIQMQ3bP19THb 8+BbIHSAQ0Xpq6ob3fRvv/lnkOFo9tfHTkoED4RzOvffgeNjuQrX70sTE16OCzvjv+x4ehhcmZwe FHzibEiyH4iSGqWxAytRygFjSx4NSDl9OoAyv1/EAXuvW0Ymyeeq2Q7uq6qh3dPujwrmA0KCRgkY WN9HLrX6+sAfzs/WIZXCQS2ezoH+DyopMWvwSpHfvl7fvBcfZYpOTevhVdqYuyBNtHOlcZ8/BQ5t u1/VnW7gQkJk2m4UyKAPZoD7FIEjRaEbl1xuwcCHXs87a5dZlMOeqavRsKB3yA06AAAAAAAA --Apple-Mail-59-503592270-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From pristinemj7119@isvinet.com Fri Jul 10 10:24:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D6E28C29B; Fri, 10 Jul 2009 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.402 X-Spam-Level: X-Spam-Status: No, score=-40.402 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxvvvGpsmSHl; Fri, 10 Jul 2009 10:24:49 -0700 (PDT) Received: from 189-54-103-125-nd.cpe.vivax.com.br (189-54-103-125-nd.cpe.vivax.com.br [189.54.103.125]) by core3.amsl.com (Postfix) with ESMTP id D5C8A28C1D3; Fri, 10 Jul 2009 10:24:48 -0700 (PDT) Date: Fri, 10 Jul 2009 14:23:54 -0300 From: aaa-archive@lists.ietf.org Subject: Time to give yourself an Edge over the other guys To: Message-ID: <000d01ca0183$33311a40$6400a8c0@pristinemj7119> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Boost your stamina today Over a million men have been helped with the potent ingredients in Pen is Growth Patch – men have experienced bigger size, more action, and super-satisfying results for themselves and their partners. Ring the bell here http://www.autbega.net/?gfssisngiph From owner-namedroppers@ops.ietf.org Fri Jul 10 10:49:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4387C28C330; Fri, 10 Jul 2009 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke2+Rd2DaalB; Fri, 10 Jul 2009 10:49:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A03F28C2F8; Fri, 10 Jul 2009 10:49:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPKAA-000HVS-6f for namedroppers-data0@psg.com; Fri, 10 Jul 2009 17:45:34 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPK9x-000HTz-1m for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 17:45:27 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 1820C5807B; Fri, 10 Jul 2009 19:45:20 +0200 (CEST) Received: from [192.168.254.8] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTP id DB6D557F2B; Fri, 10 Jul 2009 19:45:12 +0200 (CEST) Message-ID: <4A577E24.7090700@nlnetlabs.nl> Date: Fri, 10 Jul 2009 19:45:08 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: David Blacka CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] dnssec-bis-updates question #1 References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> <165C17D2-48A2-4DA9-BC53-BD6A797CA534@verisign.com> <47DA5BF2-B756-4036-B884-FD74447A9753@verisign.com> In-Reply-To: <47DA5BF2-B756-4036-B884-FD74447A9753@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9554/Fri Jul 10 19:05:16 2009 on rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 07/10/2009 07:17 PM, David Blacka wrote: > > RCODE: NOERROR > ;; QUESTION SECTION > ;www.example.com. IN AAAA > > ;; ANSWER SECTION: > > ;; AUTHORITY SECTION: > example.com. IN SOA ... > example.com. IN RRSIG SOA .. > www.example.com IN NSEC x.example.com CNAME RRSIG > www.example.com IN RRSIG NSEC ... > > And the naive validator says: This is a NODATA response. OK, I see no > AAAA bit in the type map ... OK, great! Secure! > > So, the advice is to "Check for CNAME". I.e., don't accept this response > as Secure because the CNAME bit was set, so there should have been a CNAME. +1. Yes similar to advice for validation of cases described in the dname-bis draft. If an NSEC(3) is presented to prove the non-existence of a type then check the CNAME and DNAME flags in the NSEC(3) type map. Best regards, Wouter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 10 10:49:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8DC28C330; Fri, 10 Jul 2009 10:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3068oyMFxlL; Fri, 10 Jul 2009 10:49:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E759628C29E; Fri, 10 Jul 2009 10:49:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPKBe-000HeO-9m for namedroppers-data0@psg.com; Fri, 10 Jul 2009 17:47:06 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPKBI-000HbU-9T for namedroppers@ops.ietf.org; Fri, 10 Jul 2009 17:46:56 +0000 Received: from [10.31.200.146] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6AHkadP031540; Fri, 10 Jul 2009 13:46:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <47DA5BF2-B756-4036-B884-FD74447A9753@verisign.com> References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> <165C17D2-48A2-4DA9-BC53-BD6A797CA534@verisign.com> <47DA5BF2-B756-4036-B884-FD74447A9753@verisign.com> Date: Fri, 10 Jul 2009 13:45:57 -0400 To: David Blacka From: Edward Lewis Subject: Re: [dnsext] dnssec-bis-updates question #1 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-964874499==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-964874499==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 13:17 -0400 7/10/09, David Blacka wrote: >On Jul 10, 2009, at 10:19 AM, Edward Lewis wrote: >> So, there's no difference in the answer section of a response whether there >>is matching data or not. All differences are in the authority section. > >This sentence makes no sense. If there is "matching data", then there is a >difference in the answer section, clearly. What I meant was - whether QTYPE == CNAME or QTYPE == something not in the zone, the last non-RRSIG in the ANSWER section will be a CNAME. (I assume you mean by a "positive CNAME" result as QTYPE == CNAME.) Comaparing digs for "www.neustar.biz/in/hinfo" and "www.neustar.biz/IN/CNAME" are the same in the ANSWER section. The differences are in the AUTHORITY section. >> Ok, so in 2308 "NODATA" does not mean ANCOUNT==0, rather that there >> is no relevant response RR Set. And it defines what goes into the >>authority section (SOA, no NS). > >So, CNAMEs aren't "relevant answers"? Is that what you are saying? I >think you are asserting that as long as the CNAME chain in the answer >section doesn't terminate in the final answer, the response is still >NOERROR/NODATA. This is news to me. Instead of "relevant" I should have said "matching" in the sense of QTYPE matching. It's news - from RFC 2308, see the last paragragh of 2.2 (showing the header for 2.2.1 to give the position in the section): 2.2 - No Data ... These examples, unlike the NXDOMAIN examples above, have no CNAME records, however they could, in just the same way that the NXDOMAIN examples did, in which case it would be the value of the last CNAME (the QNAME) for which NODATA would be concluded. 2.2.1 - Special Handling of No Data >OK, Ed. My point was that the original intent of section 3.3 wasn't to >describe this at all. No one (until now) has been complaining that 4035 >doesn't adequately describe how to actually validate responses with CNAMEs >in them. What I think it is trying to describe is this: Register my replies to say - 3.3 is confusing. From the example you gave: >Attacker takes this original response: > > RCODE: NOERROR > ;; QUESTION SECTION > ;www.example.com. IN AAAA > > ;; ANSWER SECTION: > www.example.com. IN CNAME example.com. > www.example.com. IN RRSIG CNAME ... > > ;; AUTHORITY SECTION: > example.com. IN SOA ... > example.com. IN RRSIG SOA .. > www.example.com IN NSEC x.example.com CNAME RRSIG > www.example.com IN RRSIG NSEC ... Why would there be the NSEC/RRSIG(NSEC) in the authority? That's a side issue, the point is that the attacker could already have it and slip it in. The "malicious" form is indeed possible. >Attacker takes this original response: >And the naive validator says: This is a NODATA response. OK, I see no AAAA >bit in the type map ... OK, great! Secure! > >So, the advice is to "Check for CNAME". I.e., don't accept this response >as Secure because the CNAME bit was set, so there should have been a CNAME. Blanket rule, it's not enough just to validate the signatures, a validator MUST also check to see if the response shows that the responder properly followed the protocol. In this case, if the response indicates that the QNAME's match owned a CNAME, there's better be a CNAME in the answer section. This all follows that blanket rule. Summing up - the intent of 3.3 is now clear to me, but the words in it are imprecise. E.g. "based on CNAMEs" is all jargon. As you can see, it certainly confused me as to the intent. E.g., I can see now what you meant by this: >>>> My suggested replacement text: >>>> >>>> Section 4 of [RFC4035] says little about validating responses based >>>> on (or that should be based on) CNAMEs. When validating a NOERROR/ >>>> NODATA response, validators MUST check the CNAME bit in the matching >>>> NSEC or NSEC3 RR's type bitmap in addition to the bit for the query >>>> type. Without this check, an attacker could successfully transform a >>>> positive CNAME response into a NOERROR/NODATA response. but not without this exchange of messages. PS - is the "legitimate" dig (as I copied here) a properly assembled reply? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-964874499==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] dnssec-bis-updates question #1
At 13:17 -0400 7/10/09, David Blacka wrote:
>On Jul 10, 2009, at 10:19 AM, Edward Lewis wrote:

>> So, there's no difference in the answer section of a response whether there
>>is matching data or not.  All differences are in the authority section.
>
>This sentence makes no sense.  If there is "matching data", then there is a
>difference in the answer section, clearly.
What I meant was - whether QTYPE == CNAME or QTYPE == something not in the zone, the last non-RRSIG in the ANSWER section will be a CNAME.  (I assume you mean by a "positive CNAME" result as QTYPE == CNAME.)  Comaparing digs for "www.neustar.biz/in/hinfo" and "www.neustar.biz/IN/CNAME" are the same in the ANSWER section.  The differences are in the AUTHORITY section.

>> Ok, so in 2308 "NODATA" does not mean ANCOUNT==0, rather that there
>> is no relevant response RR Set.  And it defines what goes into the
>>authority section (SOA, no NS).
>
>So, CNAMEs aren't "relevant answers"?  Is that what you are saying?  I
>think you are asserting that as long as the CNAME chain in the answer
>section doesn't terminate in the final answer, the response is still
>NOERROR/NODATA.  This is news to me.

Instead of "relevant" I should have said "matching" in the sense of QTYPE matching.

It's news - from RFC 2308, see the last paragragh of 2.2 (showing the header
for 2.2.1 to give the position in the section):

2.2 - No Data
...
   These examples, unlike the NXDOMAIN examples above, have no CNAME
   records, however they could, in just the same way that the NXDOMAIN
   examples did, in which case it would be the value of the last CNAME
   (the QNAME) for which NODATA would be concluded.
2.2.1 - Special Handling of No Data

>OK, Ed.  My point was that the original intent of section 3.3 wasn't to
>describe this at all.  No one (until now) has been complaining that 4035
>doesn't adequately describe how to actually validate responses with CNAMEs
>in them.  What I think it is trying to describe is this:

Register my replies to say - 3.3 is confusing.

From the example you gave:

>Attacker takes this original response:
>
>  RCODE: NOERROR
>  ;; QUESTION SECTION
>  ;www.example.com. IN AAAA
>
>  ;; ANSWER SECTION:
>  www.example.com. IN CNAME example.com.
>  www.example.com. IN RRSIG CNAME ...
>
>  ;; AUTHORITY SECTION:
>  example.com. IN SOA ...
>  example.com. IN RRSIG SOA ..
>  www.example.com  IN NSEC x.example.com CNAME RRSIG
>  www.example.com  IN RRSIG NSEC ...

Why would there be the NSEC/RRSIG(NSEC) in the authority?  That's a side issue, the point is that the attacker could already have it and slip it in.  The "malicious" form is indeed possible.
 
>Attacker takes this original response:
>And the naive validator says: This is a NODATA response.  OK, I see no AAAA
>bit in the type map ... OK, great! Secure!
>
>So, the advice is to "Check for CNAME".  I.e., don't accept this response
>as Secure because the CNAME bit was set, so there should have been a CNAME.

Blanket rule, it's not enough just to validate the signatures, a validator MUST also check to see if the response shows that the responder properly followed the protocol.  In this case, if the response indicates that the QNAME's match owned a CNAME, there's better be a CNAME in the answer section.  This all follows that blanket rule.

Summing up - the intent of 3.3 is now clear to me, but the words in it are imprecise.  E.g. "based on CNAMEs" is all jargon.  As you can see, it certainly confused me as to the intent.

E.g., I can see now what you meant by this:

>>>> My suggested replacement text:
>>>>
>>>>  Section 4 of [RFC4035] says little about validating responses based
>>>>  on (or that should be based on) CNAMEs.  When validating a NOERROR/
>>>>  NODATA response, validators MUST check the CNAME bit in the matching
>>>>  NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
>>>>  type.  Without this check, an attacker could successfully transform a
>>>>  positive CNAME response into a NOERROR/NODATA response.

but not without this exchange of messages.

PS - is the "legitimate" dig (as I copied here) a properly assembled reply?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-964874499==_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 foresterg90@mattali.com Fri Jul 10 14:42:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465B63A6E8A; Fri, 10 Jul 2009 14:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.849 X-Spam-Level: X-Spam-Status: No, score=-16.849 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnQtxqKQdTx7; Fri, 10 Jul 2009 14:42:00 -0700 (PDT) Received: from pool-72-89-120-154.nycmny.east.verizon.net (pool-72-89-120-154.nycmny.east.verizon.net [72.89.120.154]) by core3.amsl.com (Postfix) with ESMTP id 0B8893A6E59; Fri, 10 Jul 2009 14:41:13 -0700 (PDT) Message-ID: <000d01ca01a7$18125020$6400a8c0@foresterg90> From: dnsext-archive@lists.ietf.org To: Subject: Look better in a bathing suit this summer get your free trial now Date: Fri, 10 Jul 2009 14:40:50 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA01A7.18125020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA01A7.18125020 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy Get a Flat Stomach Naturally with Acai Berry = sign up for your free trial Now =A0 Waiting for you to enter Copyright C 2009=20 Meetnwsavxqvhm=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01CA01A7.18125020 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web.
= Unsubscrib= e=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy


 Get a Flat Stomach Naturally with = Acai Berry sign up for your free trial Now
= =A0
= Waiting fo= r you to enter


Copyright C 2009=20
Meetnwsavxqvhm=20 International,=20 Inc.
=A0
------=_NextPart_000_0007_01CA01A7.18125020-- From troupingvvm00@panther2.amd.com Fri Jul 10 14:42:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A823B28C1BA; Fri, 10 Jul 2009 14:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.083 X-Spam-Level: X-Spam-Status: No, score=-20.083 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FS_START_LOSE=1.493, GB_OPRAH=2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_UNI=0.591, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq2WOM0j96Wp; Fri, 10 Jul 2009 14:42:08 -0700 (PDT) Received: from 201009039214.user.veloxzone.com.br (201009039214.user.veloxzone.com.br [201.9.39.214]) by core3.amsl.com (Postfix) with ESMTP id AF8A63A6E8A; Fri, 10 Jul 2009 14:42:05 -0700 (PDT) Message-ID: <000d01ca01a7$55487aa0$6400a8c0@troupingvvm00> From: crisp-request@ietf.org To: Subject: Lose weight without stress , Acai Berry. Date: Fri, 10 Jul 2009 18:42:33 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA01A7.55487AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA01A7.55487AA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy Acai Berry is how oprah has lost weight and h= ow Rachel RAy has stayed slim. =A0 Break in here Copyright C 2009=20 Nomymtiiraeihm=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01CA01A7.55487AA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web.
= Unsubscrib= e=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy


 Acai Berry is how oprah has lost w= eight and how Rachel RAy has stayed slim.
= =A0
= Break in h= ere


Copyright C 2009=20
Nomymtiiraeihm=20 International,=20 Inc.
=A0
------=_NextPart_000_0007_01CA01A7.55487AA0-- From fortesy6@talisentech.com Fri Jul 10 16:36:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BC93A69A9; Fri, 10 Jul 2009 16:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.843 X-Spam-Level: X-Spam-Status: No, score=-3.843 tagged_above=-999 required=5 tests=[AWL=2.340, BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+WIpSkQdyoA; Fri, 10 Jul 2009 16:36:49 -0700 (PDT) Received: from r190-135-21-58.dialup.adsl.anteldata.net.uy (r190-135-21-58.dialup.adsl.anteldata.net.uy [190.135.21.58]) by core3.amsl.com (Postfix) with ESMTP id 929223A6896; Fri, 10 Jul 2009 16:36:47 -0700 (PDT) Message-ID: <000d01ca01b7$3bef9380$6400a8c0@fortesy6> From: dnsext-archive@lists.ietf.org To: Subject: Lose weight without joining expensive Gyms, Acai Berry. Date: Sat, 11 Jul 2009 00:36:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA01B7.3BEF9380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA01B7.3BEF9380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy tired Of feeling Down lose weight for free =A0 Have a look Copyright C 2009=20 Lhacwtzpiidnbi=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01CA01B7.3BEF9380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web.
= Unsubscribe<= /A>=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy


 tired Of feeling Down lose weight= for free
= =A0
= Have a look<= /A>


Copyright C 2009=20
Lhacwtzpiidnbi=20 International,=20 Inc.
=A0
------=_NextPart_000_0007_01CA01B7.3BEF9380-- From owner-namedroppers@ops.ietf.org Sat Jul 11 15:19:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B643A6846; Sat, 11 Jul 2009 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N6j3CIHIIBD; Sat, 11 Jul 2009 15:19:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E4FE3A689F; Sat, 11 Jul 2009 15:19:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPko1-00074u-3y for namedroppers-data0@psg.com; Sat, 11 Jul 2009 22:12:29 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MPkno-00074A-W7 for namedroppers@ops.ietf.org; Sat, 11 Jul 2009 22:12:23 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=wluMuPLnYPY86tFyAcnJU05yJArSjVofrQMttBri2X4dxB8F0UWLJFWw pySBL4t60ARiVw32HpcwkcEQqlNyQxz/lZxr94Ya/uJ7JpQdI5DZ1hAGS u00ex3zXEEngzXZ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1247350336; x=1278886336; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20[dnsext]=20dnssec-bis-updates=20question=20#1 |Date:=20Sat,=2011=20Jul=202009=2023:12:07=20+0100 |Message-ID:=20|To:=20David=20Blacka=20< davidb@verisign.com>|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<8C829D59-34FD-4128-8 828-B0D6EE2DC287@verisign.com>|References:=20<8C829D59-34 FD-4128-8828-B0D6EE2DC287@verisign.com>; bh=fvlqPU0nBI7UZSNwuQlT6QsXX452x2VhccQbsQEAxLQ=; b=JlUvmf++4ORriag1EffHeLga0gYX4qVM6xVuY19CeNWPyGO4wK4YAg3q 6on30sc99JGNSKv98AptndyYrsmuwIEuG9Y6DUOXjop0FwwvWqujTNnbB n4YRUm53LYk4XZV; X-IronPort-AV: E=Sophos;i="4.42,385,1243810800"; d="scan'208";a="15648183" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 11 Jul 2009 23:12:10 +0100 In-Reply-To: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> References: <8C829D59-34FD-4128-8828-B0D6EE2DC287@verisign.com> To: David Blacka Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] dnssec-bis-updates question #1 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: "Roy Arends" Date: Sat, 11 Jul 2009 23:12:07 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/07/2009 11:12:13 PM, Serialize complete at 11/07/2009 11:12:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0079F54C802575F0_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0079F54C802575F0_= Content-Type: text/plain; charset="US-ASCII" David Blacka wrote on 07/10/2009 12:28:34 AM: > In trying to get -09 out, I've come up with a few things that I think > need clarification. Here is the first one. > > In dnssec-bis-updates-08 (and many earlier versions) section 3.3 > (Check for CNAME) says: > > Section 5 of [RFC4035] says little about validating responses based > on (or that should be based on) CNAMEs. When validating a NOERROR/ > NODATA response, validators MUST check the CNAME bit in the matching > NSEC or NSEC3 RR's type bitmap. If the CNAME bit is set, the > validator MUST validate the CNAME RR and follow it, as appropriate. > > This paragraph, when I read it closely, doesn't make any sense to me. > The second sentence is talking about validating a NOERROR/NODATA > response. But the third sentence says "MUST validate the CNAME RR and > follow it..." What CNAME RR? If there was a CNAME present, then the > response wasn't a NOERROR/NODATA response, right? Right! I highlighted this issue at Dallas IETF in 2006, and re-iterated here: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01623.html (3) spoofing cname into nonexistence. If response is of type nodata: check NSEC for absence of CNAME type, otherwise a claim for nodata at name X/type Y might be a spoof, since the type might exist at the canonical name for X. > I *think* that the general idea here is to make sure that someone > didn't take a CNAME response and turn it into a NODATA. Correct. > This is a > situation that a validator might miss because it will check the > original qtype and forget to check for the CNAME bit in the NSEC > record. But if it gets such a case, then the only recourse is to > consider the response bogus. > > My suggested replacement text: > > Section 4 of [RFC4035] says little about validating responses based > on (or that should be based on) CNAMEs. When validating a NOERROR/ > NODATA response, validators MUST check the CNAME bit in the matching > NSEC or NSEC3 RR's type bitmap in addition to the bit for the query > type. Without this check, an attacker could successfully transform a > positive CNAME response into a NOERROR/NODATA response. > > Is this better? That is better. > I am assuming that we don't need to clarify the validation of a > positive CNAME response even though RFC 4035's section 5 doesn't > really explicitly address it. Right. Kind regards, Roy Arends Sr. Researcher Nominet UK --=_alternative 0079F54C802575F0_= Content-Type: text/html; charset="US-ASCII" David Blacka wrote on 07/10/2009 12:28:34 AM:

> In trying to get -09 out, I've come up with a few things that I think  
> need clarification.  Here is the first one.
>
> In dnssec-bis-updates-08 (and many earlier versions) section 3.3  
> (Check for CNAME) says:
>
>    Section 5 of [RFC4035] says little about validating responses based
>    on (or that should be based on) CNAMEs.  When validating a NOERROR/
>    NODATA response, validators MUST check the CNAME bit in the matching
>    NSEC or NSEC3 RR's type bitmap.  If the CNAME bit is set, the
>    validator MUST validate the CNAME RR and follow it, as appropriate.
>
> This paragraph, when I read it closely, doesn't make any sense to me.  
> The second sentence is talking about validating a NOERROR/NODATA  
> response.  But the third sentence says "MUST validate the CNAME RR and  
> follow it..." What CNAME RR?  If there was a CNAME present, then the  
> response wasn't a NOERROR/NODATA response, right?


Right!

I highlighted this issue at Dallas IETF in 2006, and re-iterated here:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01623.html

  (3) spoofing cname into nonexistence.

  If response is of type nodata: check NSEC for absence of CNAME type,
  otherwise a claim for nodata at name X/type Y might be a spoof, since the
  type might exist at the canonical name for X.

> I *think* that the general idea here is to make sure that someone  
> didn't take a CNAME response and turn it into a NODATA.


Correct.

> This is a  
> situation that a validator might miss because it will check the  
> original qtype and forget to check for the CNAME bit in the NSEC  
> record.  But if it gets such a case, then the only recourse is to  
> consider the response bogus.
>
> My suggested replacement text:
>
>    Section 4 of [RFC4035] says little about validating responses based
>    on (or that should be based on) CNAMEs.  When validating a NOERROR/
>    NODATA response, validators MUST check the CNAME bit in the matching
>    NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
>    type.  Without this check, an attacker could successfully transform a
>    positive CNAME response into a NOERROR/NODATA response.
>
> Is this better?


That is better.

> I am assuming that we don't need to clarify the validation of a  
> positive CNAME response even though RFC 4035's section 5 doesn't  
> really explicitly address it.

Right.

Kind regards,

Roy Arends
Sr. Researcher
Nominet UK --=_alternative 0079F54C802575F0_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From garza@iransamaneh.com Sun Jul 12 14:10:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC843A688F for ; Sun, 12 Jul 2009 14:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP4rJHA8r8sc for ; Sun, 12 Jul 2009 14:10:49 -0700 (PDT) Received: from cpe-74-69-137-212.stny.res.rr.com (cpe-74-69-137-212.stny.res.rr.com [74.69.137.212]) by core3.amsl.com (Postfix) with ESMTP id 2A1F93A6405 for ; Sun, 12 Jul 2009 14:10:47 -0700 (PDT) Date: Sun, 12 Jul 2009 17:11:16 -0500 From: dnsext-archive@lists.ietf.org Subject: Wow check out this huge enlargement patch sale! To: Message-ID: <000d01ca0335$4b2c1290$6400a8c0@garza> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal She will love you more than any other guy I know like 10 guys who have already stocked up on these! Our store http://www.frygettible.info/?xavnzdrrdwio From tableaua@israelbaseballleague.com Sun Jul 12 14:11:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DF93A688F; Sun, 12 Jul 2009 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC0BBdP8Px5s; Sun, 12 Jul 2009 14:11:53 -0700 (PDT) Received: from 201-67-176-62.bnut3703.dsl.brasiltelecom.net.br (201-67-176-62.bnut3703.dsl.brasiltelecom.net.br [201.67.176.62]) by core3.amsl.com (Postfix) with ESMTP id 1FD423A6405; Sun, 12 Jul 2009 14:11:53 -0700 (PDT) Date: Sun, 12 Jul 2009 18:11:34 -0300 From: eap-archive@ietf.org Subject: Finally a Patch that works! To: Message-ID: <000d01ca0335$55c081f0$6400a8c0@tableaua> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Avoid enhancement pills You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. Just click and see http://www.frygettible.info/?xavnzdrrdwio From bloodstreamsjxz@issi-central.com Mon Jul 13 05:07:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCE73A6810; Mon, 13 Jul 2009 05:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.273 X-Spam-Level: X-Spam-Status: No, score=-28.273 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAvjZF+49o8b; Mon, 13 Jul 2009 05:07:43 -0700 (PDT) Received: from 78-83-85-235.spectrumnet.bg (78-83-85-235.spectrumnet.bg [78.83.85.235]) by core3.amsl.com (Postfix) with ESMTP id 521C33A67F9; Mon, 13 Jul 2009 05:07:43 -0700 (PDT) Message-ID: <000d01ca03b2$97d967f0$6400a8c0@bloodstreamsjxz> From: To: Subject: Live long , healthy and happy with your new body, get your trial of Acai Berry now ! Date: Mon, 13 Jul 2009 15:08:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA03B2.97D967F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA03B2.97D967F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Have the Best weightloss product shipped to your door Number one health product this year - acaiberry=20   You are one click away =20 =20 Thank You!=20 best regards Lorna=20 Pettit ------=_NextPart_000_0007_01CA03B2.97D967F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Have the Best weightloss product shipped to your door
Number one health product this year - acaiberry
 
You are one click away
Thank You!
best regards Lorna=20 Pettit
------=_NextPart_000_0007_01CA03B2.97D967F0-- From caninghwn@iseproteccion.com Mon Jul 13 05:37:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F6528C381; Mon, 13 Jul 2009 05:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.129 X-Spam-Level: X-Spam-Status: No, score=-34.129 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DIET_1=0.083, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC-lhv9yIHFT; Mon, 13 Jul 2009 05:37:05 -0700 (PDT) Received: from h116.50.28.71.dynamic.ip.windstream.net (h116.50.28.71.dynamic.ip.windstream.net [71.28.50.116]) by core3.amsl.com (Postfix) with ESMTP id 883CF3A6810; Mon, 13 Jul 2009 05:37:05 -0700 (PDT) Date: Mon, 13 Jul 2009 08:37:25 -0500 Message-Id: From: emu-request@ietf.org To: emu-request@ietf.org Subject: Acai the fat buster Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
You could look great in no time with the help of Acai Berry.
 
Stay up late Feel Great . Acai Berry.
Add Acai Berry to your Diet. Lose weight Instantly.


best regards Bailey Graham
From obscenitynme3@isllc.com Mon Jul 13 10:05:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDFE28C4F1; Mon, 13 Jul 2009 10:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, UNPARSEABLE_RELAY=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b43cNIzV+PgM; Mon, 13 Jul 2009 10:05:39 -0700 (PDT) Received: from 201-77-114-183.desktop.com.br (201-77-114-183.desktop.com.br [201.77.114.183]) by core3.amsl.com (Postfix) with ESMTP id 17C6D28C569; Mon, 13 Jul 2009 10:03:54 -0700 (PDT) Received: from 201.77.114.183 by mail.isllc.com Date: Mon, 13 Jul 2009 14:02:09 -0300 Message-Id: From: emu-request@ietf.org To: emu-request@ietf.org Subject: Free amazing weight loss get it now Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
 

You're receiving this because you have subscribed to the Vjotut Mailinglist.
Having trouble reading this email? View it in your browser.

Lose weight feel great , Accai Berry Celebrity Diet.

Regulate your metabolism and lose weight fast.

This announcement has been sent to emu-request@ietf.org because you have subscribed to the dyz Mailinglist. If you're not interested in receiving these kinds of emails from us in the future, you can unsubscribe instantly.

From squaringk@ristuccia.net Mon Jul 13 14:18:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6837928C5DC; Mon, 13 Jul 2009 14:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.141 X-Spam-Level: X-Spam-Status: No, score=-40.141 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+7-uBFOLi5T; Mon, 13 Jul 2009 14:18:03 -0700 (PDT) Received: from pool-173-52-166-79.nycmny.east.verizon.net (pool-173-52-166-79.nycmny.east.verizon.net [173.52.166.79]) by core3.amsl.com (Postfix) with ESMTP id 5074E28C36C; Mon, 13 Jul 2009 14:18:03 -0700 (PDT) Received: from 173.52.166.79 by mx0.ristuccia.net; Mon, 13 Jul 2009 17:18:11 -0500 Date: Mon, 13 Jul 2009 17:18:11 -0500 From: dnsext-archive@lists.ietf.org Subject: Designed with you in mind , lose weight fast with Acai Berry. To: Message-ID: <000d01ca03ff$6cdeb940$6400a8c0@squaringk> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Loaded with Antioxidants Acai berry will make your body a fat burning factory. Enter fast http://www.krowelllyrics.info/?wtxfscixss best regards Jayne Salazar From owner-namedroppers@ops.ietf.org Mon Jul 13 15:40:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6A83A6A18; Mon, 13 Jul 2009 15:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.457 X-Spam-Level: **** X-Spam-Status: No, score=4.457 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMSKV8zFZgTe; Mon, 13 Jul 2009 15:40:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 821853A69B4; Mon, 13 Jul 2009 15:40:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQU5Z-000Axh-MZ for namedroppers-data0@psg.com; Mon, 13 Jul 2009 22:33:37 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQU5Q-000AuV-JI for namedroppers@ops.ietf.org; Mon, 13 Jul 2009 22:33:35 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1MQU5O-0008O4-UY for namedroppers@ops.ietf.org; Mon, 13 Jul 2009 23:33:26 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MQU5O-0002QH-Fe for namedroppers@ops.ietf.org; Mon, 13 Jul 2009 23:33:26 +0100 Message-ID: <6682BC04A3644413B184402CB53F6DF8@localhost> From: "George Barwood" To: Subject: [dnsext] Request for clarification on Truncation Date: Mon, 13 Jul 2009 23:33:25 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: (1) The original standard clearly considered that truncated responses might still be used by resolvers, but the more modern practice seems to be to always retry over TCP and to ignore any data in the truncated response. Therefore, is it acceptable for servers to return nothing except the question, when truncating? And if it is acceptable, is this best practice : saving bandwidth, and possibly helping to ensure that the response sucessfully reaches the client? Or is there a significant deployment of resolvers that makes good use of truncated packets, thus avoiding fallback to TCP? (2) It's clear that "additional section processing" does not cause truncation, instead the results of additional section processing are silently discarded if they do not fit, without setting the TC bit. However, in a referral, the addition of glue records is apparently not "additional section processing" but rather "a special search", from RFC 1034 : "NS records cause both the usual additional section processing to locate a type A record, and, when used in a referral, a special search of the zone in which they reside for glue information." It's fairly clearly an error to silently discard all the (necessary) glue, as this will probably lead to failure - it's unlikely resolvers will retry over TCP unless the TC bit is set. But in fact current authoritative resolvers do silently discard some glue, and marking a non-EDNS response as truncated because a small amount of glue does not fit does not seem sensible. So, how and where should the line be drawn? ( I apologise for bringing (2) up again, but so far there seems to have not even been a suggestion as to what is correct server behavior, let alone a consensus ). -- to unsubscribe send a message to namedroppers-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 Jul 13 19:05:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697303A6DA2; Mon, 13 Jul 2009 19:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmMqNKTUcYRr; Mon, 13 Jul 2009 19:05:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B6353A67A8; Mon, 13 Jul 2009 19:05:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQXHJ-0000HB-Kx for namedroppers-data0@psg.com; Tue, 14 Jul 2009 01:57:57 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQXH2-0000CM-MC for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 01:57:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F0329A911B for ; Tue, 14 Jul 2009 01:57:39 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Request for clarification on Truncation In-Reply-To: Your message of "Mon, 13 Jul 2009 23:33:25 +0100." <6682BC04A3644413B184402CB53F6DF8@localhost> References: <6682BC04A3644413B184402CB53F6DF8@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 14 Jul 2009 01:57:39 +0000 Message-ID: <64376.1247536659@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Mon, 13 Jul 2009 23:33:25 +0100 > > (1) The original standard clearly considered that truncated responses might > still be used by resolvers, but the more modern practice seems to be to > always retry over TCP and to ignore any data in the truncated response. what i used to try to do is assume that the second to the last non-empty section is unaffected by truncation. so if TC && ARCOUNT!=0 then the answer and authority sections could be cached, whereas if TC && ARCOUNT==0 && NSCOUNT!=0 then the answer section can be cached, etc. only if the response doesn't include the data i actually needed would i force a TCP retry. this turned out to be very hard to describe, so as far as i know, nobody does it this way today, and no standards document explains how to do it. > Therefore, is it acceptable for servers to return nothing except the > question, when truncating? And if it is acceptable, is this best > practice: saving bandwidth, and possibly helping to ensure that the > response sucessfully reaches the client? Or is there a significant > deployment of resolvers that makes good use of truncated packets, thus > avoiding fallback to TCP? i think we should continue to send "full" truncated responses so that the above logic can be used by those willing to try, and someday maybe documented by someone willing to try. > (2) It's clear that "additional section processing" does not cause > truncation, instead the results of additional section processing are > silently discarded if they do not fit, without setting the TC bit. clear in the spec perhaps, but wrong in some implementations i know of. if i see TC && ARCOUNT!=0 && NSCOUNT!=0 i'm going to assume that truncation is happening in the additional section not in the authority section. > However, in a referral, the addition of glue records is apparently not > "additional section processing" but rather "a special search", from RFC > 1034: > > "NS records cause both the usual additional section processing to locate > a type A record, and, when used in a referral, a special search of the > zone in which they reside for glue information." > > It's fairly clearly an error to silently discard all the (necessary) glue, > as this will probably lead to failure - it's unlikely resolvers will retry > over TCP unless the TC bit is set. if you get TC and are missing in-baliwick glue then that's an example of not getting everything you needed and having to therefore retry with TCP. > But in fact current authoritative resolvers do silently discard some glue, > and marking a non-EDNS response as truncated because a small amount of glue > does not fit does not seem sensible. insensible though it is, it happens. > So, how and where should the line be drawn? "Be liberal in what you accept, and conservative in what you send." -- jon > ( I apologise for bringing (2) up again, but so far there seems to have not > even been a suggestion as to what is correct server behavior, let alone a > consensus ). every time i try to descibe "necessary glue" or "soft truncation" i get hurt. -- to unsubscribe send a message to namedroppers-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 Jul 14 02:10:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485443A68C1; Tue, 14 Jul 2009 02:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95e9OnNHSoBp; Tue, 14 Jul 2009 02:10:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B7F23A6887; Tue, 14 Jul 2009 02:10:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQdsk-0009Bh-9h for namedroppers-data0@psg.com; Tue, 14 Jul 2009 09:01:02 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQdsa-00098V-4c for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 09:00:57 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id 7C30B7C401; Tue, 14 Jul 2009 09:00:49 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 5E072760E9; Tue, 14 Jul 2009 12:00:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19036.18750.946584.937742@guava.gson.org> Date: Tue, 14 Jul 2009 12:00:46 +0300 To: namedroppers@ops.ietf.org Subject: [dnsext] draft-livingood-dns-redirect-00 X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Readers of this list may be interested in the ongoing discussion about draft-livingood-dns-redirect-00 on the dnsop mailing list. -- 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 Tue Jul 14 04:32:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F863A68E2; Tue, 14 Jul 2009 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz9r0a1Ku0VF; Tue, 14 Jul 2009 04:32:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E34763A63EC; Tue, 14 Jul 2009 04:32:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQg72-000M4V-4v for namedroppers-data0@psg.com; Tue, 14 Jul 2009 11:23:56 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQg6b-000Lyv-VV for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 11:23:41 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C0EF52FE8CA1 for ; Tue, 14 Jul 2009 11:23:28 +0000 (UTC) Date: Tue, 14 Jul 2009 07:23:26 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-livingood-dns-redirect-00 Message-ID: <20090714112326.GA4628@shinkuro.com> References: <19036.18750.946584.937742@guava.gson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19036.18750.946584.937742@guava.gson.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 14, 2009 at 12:00:46PM +0300, Andreas Gustafsson wrote: > Readers of this list may be interested in the ongoing discussion about > draft-livingood-dns-redirect-00 on the dnsop mailing list. Readers may be, yes, but as your friendly local moderator I urge you to take discussion of the draft to the DNSOP list. The draft is to be discussed in DNSOP in Stockholm, and it appears to be the position of the authors that it does not modify the DNS protocols. Unless the DNSOP chairs kick the draft to us, it would be nice to keep all the discussion about it on one list. Thanks and best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 14 07:47:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360D33A6AC3; Tue, 14 Jul 2009 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.42 X-Spam-Level: ** X-Spam-Status: No, score=2.42 tagged_above=-999 required=5 tests=[AWL=-1.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, MISSING_HEADERS=1.292, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDDyRS0KOqto; Tue, 14 Jul 2009 07:47:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A57683A6EB7; Tue, 14 Jul 2009 07:47:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQj9V-000Ay1-KQ for namedroppers-data0@psg.com; Tue, 14 Jul 2009 14:38:41 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQj9N-000A3t-Jo for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 14:38:36 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 674BC3EC13; Tue, 14 Jul 2009 18:38:30 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LhW4M1hqJpm9; Tue, 14 Jul 2009 18:38:30 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 31BB13EC10 for ; Tue, 14 Jul 2009 18:38:26 +0400 (MSD) Message-ID: <4A5C9862.3070007@cryptocom.ru> Date: Tue, 14 Jul 2009 18:38:26 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: [dnsext] draft-dolmatov-dnsext-dnssec-gost-01.txt References: <19036.18750.946584.937742@guava.gson.org> In-Reply-To: <19036.18750.946584.937742@guava.gson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Corrected version of DNSSec GOST draft is available at http://ca.cryptocom.ru/tmpfiles/draft-dolmatov-dnsext-dnssec-gost-01.txt This version will be submitted as I-D after reopening the submission window at 28th of July. dol@ -- to unsubscribe send a message to namedroppers-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 Jul 14 08:06:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E2A3A6EF9; Tue, 14 Jul 2009 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.28 X-Spam-Level: ** X-Spam-Status: No, score=2.28 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atN8n-6jZkHO; Tue, 14 Jul 2009 08:06:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5B853A6EE2; Tue, 14 Jul 2009 08:06:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQjTl-0002UQ-MD for namedroppers-data0@psg.com; Tue, 14 Jul 2009 14:59:37 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQjTd-0002SF-LE for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 14:59:33 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 4B8EC3EC13; Tue, 14 Jul 2009 18:59:28 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LDIMTy3bUbsg; Tue, 14 Jul 2009 18:59:28 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 137ED3EC10 for ; Tue, 14 Jul 2009 18:59:28 +0400 (MSD) Message-ID: <4A5C9D4F.109@cryptocom.ru> Date: Tue, 14 Jul 2009 18:59:27 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] draft-dolmatov-dnsext-dnssec-gost-01.txt References: <19036.18750.946584.937742@guava.gson.org> In-Reply-To: <19036.18750.946584.937742@guava.gson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Corrected version of DNSSec GOST draft is available at http://ca.cryptocom.ru/tmpfiles/draft-dolmatov-dnsext-dnssec-gost-01.txt This version will be submitted as I-D after reopening the submission window at 28th of July. dol@ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From deprivefi544@ireasoning.com Tue Jul 14 08:24:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8763A6945; Tue, 14 Jul 2009 08:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.034 X-Spam-Level: X-Spam-Status: No, score=-26.034 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiqLKV0pgSnh; Tue, 14 Jul 2009 08:24:34 -0700 (PDT) Received: from c-67-188-252-220.hsd1.ca.comcast.net (c-67-188-252-220.hsd1.ca.comcast.net [67.188.252.220]) by core3.amsl.com (Postfix) with ESMTP id 70A583A6EC0; Tue, 14 Jul 2009 08:23:57 -0700 (PDT) Date: Tue, 14 Jul 2009 08:23:12 -0800 From: dnsext-archive@lists.ietf.org Subject: Beneficial Berry , Acai works to help you lose wieght fast. To: Message-ID: <000d01ca0497$008e2990$6400a8c0@deprivefi544> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Vital Acai is a natural WeightL0SS product That enables people to lose Enhance your sexual desires and increase your metabolism at the same time. Enter doubtless http://aicbayko.cn From owner-namedroppers@ops.ietf.org Tue Jul 14 11:46:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAEA3A684F; Tue, 14 Jul 2009 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZRASxHTqRr1; Tue, 14 Jul 2009 11:46:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EB4D3A6778; Tue, 14 Jul 2009 11:46:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQmja-000G6P-8b for namedroppers-data0@psg.com; Tue, 14 Jul 2009 18:28:10 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQmHj-000C8T-MH for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 17:59:33 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 34C7B2FE8CA1 for ; Tue, 14 Jul 2009 17:59:22 +0000 (UTC) Date: Tue, 14 Jul 2009 13:59:20 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Message-ID: <20090714175920.GN4628@shinkuro.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907092337.n69NbOha065522@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 10, 2009 at 09:37:24AM +1000, Mark Andrews wrote: > > In message <4A55B81A.2030803@NLnetLabs.nl>, Jelte Jansen writes: > > fantastic. But IMHO it would be better implemented as either a website or a > > non-RFC publication. And it would only be useful if actually kept up-to-date. > > This sounds like a excellent plan. The above sounds like two volunteers :-) Anyone else? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From rednecks10@potisje-kanjiza.com Tue Jul 14 12:32:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26393A699F; Tue, 14 Jul 2009 12:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML8u805ynmov; Tue, 14 Jul 2009 12:32:48 -0700 (PDT) Received: from c-71-59-99-86.hsd1.pa.comcast.net (c-71-59-99-86.hsd1.pa.comcast.net [71.59.99.86]) by core3.amsl.com (Postfix) with ESMTP id 2CA9C3A69A5; Tue, 14 Jul 2009 12:32:47 -0700 (PDT) Received: from 71.59.99.86 by noise.potisje-kanjiza.com; Tue, 14 Jul 2009 15:33:17 -0500 Date: Tue, 14 Jul 2009 15:33:17 -0500 From: dix@ietf.org Subject: embrace your new confidence, try acai for free To: Message-ID: <000d01ca04b9$f0286340$6400a8c0@rednecks10> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Acai Berry your solution to losing weight quickly. Acai berry will get you to Love the skin your in and your new body effortlessly. click http://www.alundwerkrim.biz/?wasjohmscixss From owner-namedroppers@ops.ietf.org Tue Jul 14 14:45:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2A13A6826; Tue, 14 Jul 2009 14:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPOFKltwWszR; Tue, 14 Jul 2009 14:45:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AEEC3A67E1; Tue, 14 Jul 2009 14:45:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQpge-000EAl-Gk for namedroppers-data0@psg.com; Tue, 14 Jul 2009 21:37:20 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQpga-000EA9-5k for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 21:37:17 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B3D22A92B9; Tue, 14 Jul 2009 21:37:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) In-Reply-To: Your message of "Tue, 14 Jul 2009 13:59:20 -0400." <20090714175920.GN4628@shinkuro.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 14 Jul 2009 21:37:15 +0000 Message-ID: <14421.1247607435@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 14 Jul 2009 13:59:20 -0400 > From: Andrew Sullivan > > > This sounds like a excellent plan. i'm in favour of a recurring RFC, annual or biannual, vs. a website. > The above sounds like two volunteers :-) Anyone else? i'm willing to help. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From danishfk369@powlink.com.tw Tue Jul 14 16:22:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC073A6989; Tue, 14 Jul 2009 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.495 X-Spam-Level: X-Spam-Status: No, score=-17.495 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DIET_1=0.083, FB_YOUR_WEIGHT=3.531, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_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_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMQ8gO7LQhyV; Tue, 14 Jul 2009 16:22:29 -0700 (PDT) Received: from 201-13-30-48.dsl.telesp.net.br (201-13-30-48.dsl.telesp.net.br [201.13.30.48]) by core3.amsl.com (Postfix) with ESMTP id 8122A3A6890; Tue, 14 Jul 2009 16:22:26 -0700 (PDT) Received: from 201.13.30.48 by dns.powlink.com.tw; Tue, 14 Jul 2009 20:20:41 -0300 Date: Tue, 14 Jul 2009 20:20:41 -0300 Message-Id: From: crisp-request@ietf.org To: crisp-request@ietf.org Subject: Everyone noticed some weight loss only after 2 weeks and energy levels increased after 5 days See How Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Acai Slim promotes weight loss and makes you feel fantastic while doing it!
Don't waste another day dissatisfied about your weight and how you look!
You CAN and WILL change and it is possible!
The Acai Berry's natural combination of antioxidants, essential fatty acids, amino acids, phytosterols, and amino acids work together to help your body function better, process food easier, and burn fat more efficiently.
It's one of the best things you can put into your body to keep it healthy.


Our customers are saying:


"I began using this product 4 weeks ago, and I'm amazed at how well it's working for me!
So far I've lost 17 pounds and 3 inches of fat from my tummy."

Lisa D., USA, PA

"Thank you, Thank you, Thank you!!!!! Acai Power Slim is the "BOMB"!
I am a trainer at an exclusive gym here in New York City, and have been exposed to many different products over the years. There has never been a product that I have used that has rocked my world like Acai Power Slim! I thought I had tons of energy, but now I'm stoked. I have a few health issues, like colitis, and can not drink coffee, so I can not take any product with caffine in it, this is all natural, and does not have any caffine. Very Cool!"

Christina, New York City

Acai berry helps you stay thin and healthy!
Come on and click





From owner-namedroppers@ops.ietf.org Tue Jul 14 16:31:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53C73A67FA; Tue, 14 Jul 2009 16:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t3AyC7zaOWA; Tue, 14 Jul 2009 16:31:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B62073A677D; Tue, 14 Jul 2009 16:31:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQrLf-0000oT-G0 for namedroppers-data0@psg.com; Tue, 14 Jul 2009 23:23:47 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQrLX-0000nb-KO for namedroppers@ops.ietf.org; Tue, 14 Jul 2009 23:23:43 +0000 Received: from limpet.local (router-alambert.sh-58.clarityconnect.net [209.150.233.93]) by abenaki.wabanaki.net (8.14.2/8.14.2) with ESMTP id n6EMJBeS071570; Tue, 14 Jul 2009 18:19:11 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4A5D1376.3070002@abenaki.wabanaki.net> Date: Tue, 14 Jul 2009 19:23:34 -0400 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Paul Vixie CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> <14421.1247607435@nsa.vix.com> In-Reply-To: <14421.1247607435@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> Date: Tue, 14 Jul 2009 13:59:20 -0400 >> From: Andrew Sullivan >> >> >>> This sounds like a excellent plan. >>> > > i'm in favour of a recurring RFC, annual or biannual, vs. a website. > strong preference for dead tree. cites better, especially when wrong and needs fixing, than something that has vanishing blemies (and takes continuous work to maintain, and for which there is no "standard", for which i thank the rfc templates. >> The above sounds like two volunteers :-) Anyone else? >> > > i'm willing to help. > ditto. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From vole045@italvibreh.com Tue Jul 14 18:27:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BB53A694C; Tue, 14 Jul 2009 18:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.627 X-Spam-Level: X-Spam-Status: No, score=-24.627 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYuuWhLbZV5x; Tue, 14 Jul 2009 18:27:34 -0700 (PDT) Received: from cpe-173-168-168-154.tampabay.res.rr.com (cpe-173-168-168-154.tampabay.res.rr.com [173.168.168.154]) by core3.amsl.com (Postfix) with ESMTP id 54A513A6881; Tue, 14 Jul 2009 18:27:34 -0700 (PDT) Date: Tue, 14 Jul 2009 18:26:50 -0800 From: dix@ietf.org Subject: Get the body you always wanted , Try Acai Berry. To: Message-ID: <000d01ca04eb$5408f7e0$6400a8c0@vole045> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Acai your answer for losing weight fast. Acai diet will deliver results and rid you of your unwated weight. Rush to visit http://aiabncno.cn From owner-namedroppers@ops.ietf.org Tue Jul 14 19:28:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D0D3A6945; Tue, 14 Jul 2009 19:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXeQply4NbjI; Tue, 14 Jul 2009 19:28:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15E033A691E; Tue, 14 Jul 2009 19:28:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQu5d-0007Dp-UK for namedroppers-data0@psg.com; Wed, 15 Jul 2009 02:19:25 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQu5Z-0007Bl-9t for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 02:19:23 +0000 Received: from [192.168.1.4] (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0A3932FE8CA1; Wed, 15 Jul 2009 00:25:09 +0000 (UTC) From: Andrew Sullivan To: Eric Brunner-Williams In-Reply-To: <4A5D1376.3070002@abenaki.wabanaki.net> X-Mailer: iPhone Mail (7A341) Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> <14421.1247607435@nsa.vix.com> <4A5D1376.3070002@abenaki.wabanaki.net> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A341) Date: Tue, 14 Jul 2009 20:25:04 -0400 Cc: Paul Vixie , "namedroppers@ops.ietf.org" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, This sounds like another possible revision to the charter. If you want that, please say you want to take on this work item. We already have two volunteers. Andrew Sullivan ajs@shinkuro.com On 2009-07-14, at 19:23, Eric Brunner-Williams wrote: > Paul Vixie wrote: >>> Date: Tue, 14 Jul 2009 13:59:20 -0400 >>> From: Andrew Sullivan >>> >>> >>>> This sounds like a excellent plan. >>>> >> >> i'm in favour of a recurring RFC, annual or biannual, vs. a website. >> > > strong preference for dead tree. cites better, especially when wrong > and needs fixing, than something that has vanishing blemies (and > takes continuous work to maintain, and for which there is no > "standard", for which i thank the rfc templates. > >>> The above sounds like two volunteers :-) Anyone else? >>> >> >> i'm willing to help. >> > > ditto. > > -- > to 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 Jul 14 21:39:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3633A68BC; Tue, 14 Jul 2009 21:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X+rC5E9J0db; Tue, 14 Jul 2009 21:39:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD0A63A67A1; Tue, 14 Jul 2009 21:39:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQwBq-000NVm-EA for namedroppers-data0@psg.com; Wed, 15 Jul 2009 04:33:58 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQwBn-000NVF-6M for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 04:33:56 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D2294A931D for ; Wed, 15 Jul 2009 04:33:54 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) In-Reply-To: Your message of "Tue, 14 Jul 2009 19:23:34 -0400." <4A5D1376.3070002@abenaki.wabanaki.net> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> <14421.1247607435@nsa.vix.com> <4A5D1376.3070002@abenaki.wabanaki.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 15 Jul 2009 04:33:54 +0000 Message-ID: <31674.1247632434@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 14 Jul 2009 19:23:34 -0400 > From: Eric Brunner-Williams > > > i'm in favour of a recurring RFC, annual or biannual, vs. a website. > > strong preference for dead tree. cites better, especially when wrong and > needs fixing, than something that has vanishing blemies (and takes > continuous work to maintain, and for which there is no "standard", for > which i thank the rfc templates. another advantage to this approach is that if we rewrite 1033-1034-1035 to include all-that-has-come-since-then (*), then future dns-related RFC work will boil down to arguing about edits to these documents. that would make it sort of like corporate bylaws or the ARIN NRPM. otherwise the list of RFC's that an implementor has to follow is ever-changing guesswork (as now). (*) note that the rfc editor was significantly confused by the DNSSEC work and decided to reserve the 4034/4035 numbers the same way as 2821/2822 was reserved for the SMTP rewrite. 4034/4035 was additive, not a rewrite, as makes sense in the working group's historical style of acting additively: simply put, there is no single base DNS spec to rewrite at this point. -- to unsubscribe send a message to namedroppers-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 Jul 14 21:54:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B6F28C0DC; Tue, 14 Jul 2009 21:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5ZGZR727jmC; Tue, 14 Jul 2009 21:54:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C208B28C0D7; Tue, 14 Jul 2009 21:54:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQwQm-000Pse-QT for namedroppers-data0@psg.com; Wed, 15 Jul 2009 04:49:24 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQwQi-000Pqo-R8 for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 04:49:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 827ACA934B for ; Wed, 15 Jul 2009 04:49:20 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) In-Reply-To: Your message of "Tue, 14 Jul 2009 20:25:04 -0400." References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> <14421.1247607435@nsa.vix.com> <4A5D1376.3070002@abenaki.wabanaki.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 15 Jul 2009 04:49:20 +0000 Message-ID: <32243.1247633360@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Andrew Sullivan > Date: Tue, 14 Jul 2009 20:25:04 -0400 > > This sounds like another possible revision to the charter. ... my apologies for that. i don't think in terms of the charter, i think in terms of what dns needs. the updated charter is a find description of what various volunteers want to work on, but i don't actually want to work on any of this, it's more of a duty for me, so i don't think that way either. dns needs what smtp got in 2821/2822, and then that replacement will need to be replaced every year or two to pull in new ideas and new work, plus the inevitable editorial clarity improvements. i don't know how to fit that into the kind of thinking that goes into editing the charter but i hope 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 owner-namedroppers@ops.ietf.org Tue Jul 14 22:21:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35E03A6860; Tue, 14 Jul 2009 22:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.513 X-Spam-Level: X-Spam-Status: No, score=-4.513 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 zk8TbLZmdTTM; Tue, 14 Jul 2009 22:21:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D0143A67A1; Tue, 14 Jul 2009 22:21:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQwr6-0003uy-6n for namedroppers-data0@psg.com; Wed, 15 Jul 2009 05:16:36 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQwr1-0003uO-Tt for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 05:16:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n6F5ERgR017592; Wed, 15 Jul 2009 05:14:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n6F5ERw2017591; Wed, 15 Jul 2009 05:14:27 GMT Date: Wed, 15 Jul 2009 05:14:27 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Message-ID: <20090715051427.GA17410@vacation.karoshi.com.> References: <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> <14421.1247607435@nsa.vix.com> <4A5D1376.3070002@abenaki.wabanaki.net> <31674.1247632434@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31674.1247632434@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 15, 2009 at 04:33:54AM +0000, Paul Vixie wrote: > simply put, there is no single base DNS spec to rewrite at this point. > that makes it tough to argue that a reference implementation exists or even could exist. or that the IETF goal of multiple, interoperable implementations need to exist to promote on the standards path. this way lies maddness. (and no doubt profitability - but at the expense of a useful, global system.) as usual, YMMV --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 14 22:41:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840AE3A682F; Tue, 14 Jul 2009 22:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MadiBBDQmOPW; Tue, 14 Jul 2009 22:41:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 759013A6828; Tue, 14 Jul 2009 22:41:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQxAY-0006nF-4T for namedroppers-data0@psg.com; Wed, 15 Jul 2009 05:36:42 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MQxAU-0006mk-Mj for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 05:36:40 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=x9wXNAFFQiWBM7BYPpYQtw2PscreRlh4hd7Nl7+m96kz/mYOBdex4nGg uT1TrHSDFLRLxV+wjOLAB99XkE1ZOORnEhbMXoInBe/NLGLVsJ7npsvqD guvPMmT9f271GHX; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1247636198; x=1279172198; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20[dnsext]=20WG=20Review:=20Recharter=20of=20DNS =20Extensions=20(dnsext)|Date:=20Wed,=2015=20Jul=202009 =2007:36:28=20+0200|Message-ID:=20|To: =20Andrew=20Sullivan=20|Cc:=20namedropp ers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<2009 0714175920.GN4628@shinkuro.com>|References:=20<2009070721 1502.2D31E3A68A1@core3.amsl.com>=20<1247037139.3922.19184 .camel@shane-asus-laptop>=20<20090708094817.GB18180@shink uro.com>=20<1247049953.3922.20011.camel@shane-asus-laptop >=20<20090708180926.GB18387@shinkuro.com>=20<4A55B81A.203 0803@NLnetLabs.nl>=20<200907092337.n69NbOha065522@drugs.d v.isc.org>=20<20090714175920.GN4628@shinkuro.com>; bh=ck0xsRzpG/Mer2KShYVyEQhc8bhaLsuWb16CxataEC0=; b=7FhmMMGdFWD2S5IfFlNNWGrvBZtiVVTv4dtdu3XW2Htt5vzeGgDcAdR4 1BDNQpKJ91jK0B2dD/ggJLJlBzUgz9kKv+OfvfnReUUfbZAkckN2eZX2O XlRb0uasEyOz5FM; X-IronPort-AV: E=Sophos;i="4.42,402,1243810800"; d="scan'208";a="15766805" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 15 Jul 2009 06:36:32 +0100 In-Reply-To: <20090714175920.GN4628@shinkuro.com> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: "Roy Arends" Date: Wed, 15 Jul 2009 07:36:28 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/07/2009 06:36:36 AM, Serialize complete at 15/07/2009 06:36:36 AM Content-Type: multipart/alternative; boundary="=_alternative 001ECECCC12575F4_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 001ECECCC12575F4_= Content-Type: text/plain; charset="US-ASCII" Andrew Sullivan wrote on 07/14/2009 07:59:20 PM: > On Fri, Jul 10, 2009 at 09:37:24AM +1000, Mark Andrews wrote: > > > > In message <4A55B81A.2030803@NLnetLabs.nl>, Jelte Jansen writes: > > > > fantastic. But IMHO it would be better implemented as either a > website or a > > > non-RFC publication. And it would only be useful if actually > kept up-to-date. > > > > This sounds like a excellent plan. > > The above sounds like two volunteers :-) Anyone else? I prefer rfc form. Like 4033/4/5 was for 2535 and subsequent updates. I volunteer. Roy --=_alternative 001ECECCC12575F4_= Content-Type: text/html; charset="US-ASCII"
Andrew Sullivan wrote on 07/14/2009 07:59:20 PM:

> On Fri, Jul 10, 2009 at 09:37:24AM +1000, Mark Andrews wrote:
> >
> > In message <4A55B81A.2030803@NLnetLabs.nl>, Jelte Jansen writes:
>
> > > fantastic. But IMHO it would be better implemented as either a
> website or a
> > > non-RFC publication. And it would only be useful if actually
> kept up-to-date.
> >
> > This sounds like a excellent plan.
>
> The above sounds like two volunteers :-)  Anyone else?

I prefer rfc form. Like 4033/4/5 was for 2535 and subsequent updates. I volunteer.

Roy --=_alternative 001ECECCC12575F4_=-- -- to unsubscribe send a message to namedroppers-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 Jul 15 04:12:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64E83A6B20; Wed, 15 Jul 2009 04:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.372 X-Spam-Level: ** X-Spam-Status: No, score=2.372 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U53bbEwUsKx; Wed, 15 Jul 2009 04:12:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA92D3A696B; Wed, 15 Jul 2009 04:12:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR2Fm-0004Nx-5C for namedroppers-data0@psg.com; Wed, 15 Jul 2009 11:02:26 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR2Ff-0004N6-0C for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 11:02:21 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 4104A3EC1A; Wed, 15 Jul 2009 13:00:35 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jsx3avYFvb8a; Wed, 15 Jul 2009 13:00:35 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 8B4373EC14; Wed, 15 Jul 2009 13:00:31 +0400 (MSD) Message-ID: <4A5D9AAF.7020003@cryptocom.ru> Date: Wed, 15 Jul 2009 13:00:31 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-dolmatov-dnsext-dnssec-gost-01.txt References: <19036.18750.946584.937742@guava.gson.org> <4A5C9862.3070007@cryptocom.ru> <3efd34cc0907141027t538f644bx5821d26a000863d0@mail.gmail.com> In-Reply-To: <3efd34cc0907141027t538f644bx5821d26a000863d0@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert пишет: > Basil, > > I'm very naive in this, but I'd love to know more about the GOST > asymmetric algorithm and how to implement it. Is the algorithm > specified anywhere in a language I can read (Dutch, German, French in > a pinch or English)? From what I've heard, there is a Russian version > available, but sadly I have problems reading that :-) We prepared and submitted drafts with translation of GOSTs just for those who prefer English texts to Russian. ;) Quiting referencies in this draft: [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., "GOST R 34.10-2001 digital signature algorithm" draft-dolmatov-cryptocom-gost3410-2001-01.txt, work in progress [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., "GOST R 34.11-94 Hash function algorithm" draft-dolmatov-cryptocom-gost341194-00.txt, work in progress > > Is there a pointer to the russian version? > > If the 512 bit key size is strong enough, it might be interesting. > It is considered strong enough by Federal Security Service in Russia for exclusive usage in _governmental_ organisations, so I think that it is strong enough for more relaxed usage. ;) > Thanks! > > On Tue, Jul 14, 2009 at 4:38 PM, Basil Dolmatov wrote: >> Corrected version of DNSSec GOST draft is available at >> http://ca.cryptocom.ru/tmpfiles/draft-dolmatov-dnsext-dnssec-gost-01.txt >> >> This version will be submitted as I-D after reopening the submission window >> at 28th of July. >> >> >> dol@ >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 15 04:27:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45AE53A6A5E; Wed, 15 Jul 2009 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MBpDlHoXi73; Wed, 15 Jul 2009 04:27:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B4673A696B; Wed, 15 Jul 2009 04:27:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR2Yn-0006zS-H8 for namedroppers-data0@psg.com; Wed, 15 Jul 2009 11:22:05 +0000 Received: from [194.176.119.229] (helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR2Yj-0006yU-NR for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 11:22:03 +0000 Received: from core.c-l-i.net (core.c-l-i.net [204.62.249.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id 2EE051AB2FF; Wed, 15 Jul 2009 09:27:40 +0000 (UTC) Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <38401C7E-56B0-4380-B440-4922F4718054@bondis.org> From: =?ISO-8859-1?Q?Jo=E3o_Damas?= To: Roy Arends In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Date: Wed, 15 Jul 2009 11:27:40 +0200 References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 15 Jul 2009, at 07:36, Roy Arends wrote: > > > The above sounds like two volunteers :-) Anyone else? > > I prefer rfc form. Like 4033/4/5 was for 2535 and subsequent > updates. I volunteer. So do I, again. I do like the web site approach for putting this together. When it is at a stage that deserves taking a snapshot in the form of an RFC, then that can be done, but a visible web site would be a good thing. I have a feeling last time around this effort wasn't helped by the closed nature of the text repository. Joao -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From cites5@irishartrestorers.com Wed Jul 15 10:03:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E97E28C24A; Wed, 15 Jul 2009 10:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.921 X-Spam-Level: X-Spam-Status: No, score=-21.921 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_DHCP=1.295, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVuxY+6ZVl7m; Wed, 15 Jul 2009 10:03:07 -0700 (PDT) Received: from pa-67-234-101-102.dhcp.embarqhsd.net (pa-67-234-101-102.dhcp.embarqhsd.net [67.234.101.102]) by core3.amsl.com (Postfix) with ESMTP id 71F1F28C22E; Wed, 15 Jul 2009 10:03:07 -0700 (PDT) Date: Wed, 15 Jul 2009 13:02:46 -0500 From: dnsext-archive@lists.ietf.org Subject: Start your day right, Try Acai Berry. To: Message-ID: <000d01ca056e$135bdf90$6400a8c0@cites5> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Get Acai Flush working for you , Start your free trial today! A swift click http://aidnazho.cn best regards Ofelia Lucero From owner-namedroppers@ops.ietf.org Wed Jul 15 10:43:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B4928C185; Wed, 15 Jul 2009 10:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=-0.742, 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 umBxWBXvji5L; Wed, 15 Jul 2009 10:43:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4E9128C13C; Wed, 15 Jul 2009 10:43:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR8QW-000HVN-Kf for namedroppers-data0@psg.com; Wed, 15 Jul 2009 17:37:56 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR8QR-000HTT-Qb for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 17:37:54 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6FHbkjM096724; Wed, 15 Jul 2009 13:37:46 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200907151737.n6FHbkjM096724@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 13:37:38 -0400 To: Shane Kerr , Andrew Sullivan From: Olafur Gudmundsson Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Cc: namedroppers@ops.ietf.org In-Reply-To: <1247049953.3922.20011.camel@shane-asus-laptop> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 06:45 08/07/2009, Shane Kerr wrote: >Andrew, > >On Wed, 2009-07-08 at 05:48 -0400, Andrew Sullivan wrote: > > Remember that we put the WG "to sleep" some time ago, on the general > > principle that continued tinkering with a protocol as mature as DNS > > was not a great idea. That's not to say there are no refinements to > > make. But the idea was to have a high bar for additional work, in > > order to make sure that the additional work was really valuable before > > undertaking it. As it is, it seems to me we're at least somnambulent: > > we seem to be pretty busy for someone sleeping. > >I confess to zoning out during the discussion about going dormant, >because it was one of those topics that everyone can immediately >understand and form an instant opinion. So there were lots of speeches >at the microphones, huge e-mail threads with low signal-to-noise ratios, >and so on. Apologies for my lack of attention. It seemed to make sense >from a theoretical point of view though. No problem I wish I could have tuned that discussion out. But over the last addition to DNS OpCodes was Update RFC2136/Apr-1997 (we retired an Opcode in RFC3425/Nov-2002, similarly we last change to Response codes are defined in a total of 6 RFC's most in RFC1034 and RFC2136. NSEC3 is the last item that has required heavy protocol work. Thus it is fair to say "DNS is stable protocol". Ideas that require actual new protocol work or registrations have been few over the last decade thus the current draft charter seemed appropriate. Recharterning is not that difficult it only takes time :-), it seems to me that your "brilliant" idea needs a recharter due to its "brilliance" :-) >The current style of DNS standards work seems to be that we have a >number of people working full-time on DNS stuff, and occasionally they >think of something that should be standardized, so when they have a few >moments they write something down and present it to the dnsext working >group. This seems to work pretty good (except for the huge mass of >confusing RFCs, hopefully an effort to fix that will arise again some >day). > >I'm not sure if the IXFR-ONLY stuff is interesting enough for a >recharter. (I'm happy to pursue it as an individual submission, although >I heard horror stories about that process. Maybe that was only in the >past though.) Weird that we have a system designed to make it hard to >make small tweaks but easy to make major changes though! It will still land in the WG group. >Maybe we should collect small DNS work in a separate area and then >create a "dnsfix" group every now and then to push them through the >standards process? It hardly seems ideal, but... What is there to fix ? If WG thinks thinks this idea warrants a further study, then the right thing to do is to send a note to the IESG saying that following line should be added to the draft charter: "IXFR-Only standardization" With following Milestone: "20xx Mon IXFR-Only submitted to IESG" Olafur 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 Jul 15 10:46:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEF13A6A45; Wed, 15 Jul 2009 10:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-0.881, 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 8USGNKQrvQr1; Wed, 15 Jul 2009 10:46:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93F583A67A3; Wed, 15 Jul 2009 10:46:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR8Ox-000HFe-Lo for namedroppers-data0@psg.com; Wed, 15 Jul 2009 17:36:19 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR8Os-000HEY-Tk for namedroppers@ops.ietf.org; Wed, 15 Jul 2009 17:36:17 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6FHZldS096702; Wed, 15 Jul 2009 13:35:47 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200907151735.n6FHZldS096702@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 13:35:42 -0400 To: =?iso-8859-1?Q?Jo=E3o?= Damas , Roy Arends From: Olafur Gudmundsson Subject: Re: [dnsext] WG Review: Recharter of DNS Extensions (dnsext) Cc: Andrew Sullivan , namedroppers@ops.ietf.org In-Reply-To: <38401C7E-56B0-4380-B440-4922F4718054@bondis.org> References: <20090707211502.2D31E3A68A1@core3.amsl.com> <1247037139.3922.19184.camel@shane-asus-laptop> <20090708094817.GB18180@shinkuro.com> <1247049953.3922.20011.camel@shane-asus-laptop> <20090708180926.GB18387@shinkuro.com> <4A55B81A.2030803@NLnetLabs.nl> <200907092337.n69NbOha065522@drugs.dv.isc.org> <20090714175920.GN4628@shinkuro.com> <38401C7E-56B0-4380-B440-4922F4718054@bondis.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 05:27 15/07/2009, Jo=E3o Damas wrote: >On 15 Jul 2009, at 07:36, Roy Arends wrote: > >> >> > The above sounds like two volunteers :-) Anyone else? >> >>I prefer rfc form. Like 4033/4/5 was for 2535 and subsequent >>updates. I volunteer. > >So do I, again. >I do like the web site approach for putting this together. When it is >at a stage that deserves taking a snapshot in the form of an RFC, then >that can be done, but a visible web site would be a good thing. I have >a feeling last time around this effort wasn't helped by the closed >nature of the text repository. > >Joao I would like to make the suggestion that we attack this as a two phase= project the first phase is to create a web site with most of the content the second phase is to actually take the and generate RFC's. This way we can hopefully quickly get a=20 reasonable skeleton, and figure out what to argue about. I have battle-scars from dealing with large documents with many moving parts as people argue only about one section at the time. Further allowing people to edit their own sections with tracking of changes as an experiment is something we have not done but I'm curious to see what will happen. Further more web site can be more "content" rich than RFC and illustrations IMHO will help us reach consensus faster than pure text. 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 would9@istria-ltd.com Wed Jul 15 12:04:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EEA3A6BDF; Wed, 15 Jul 2009 12:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.765 X-Spam-Level: X-Spam-Status: No, score=-17.765 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwTF1L-wigZt; Wed, 15 Jul 2009 12:04:45 -0700 (PDT) Received: from 189-69-154-250.dial-up.telesp.net.br (189-69-154-250.dial-up.telesp.net.br [189.69.154.250]) by core3.amsl.com (Postfix) with ESMTP id 7AFE528C16A; Wed, 15 Jul 2009 12:04:03 -0700 (PDT) Date: Wed, 15 Jul 2009 16:03:20 -0300 From: dnsext-archive@lists.ietf.org Subject: Lose 40lbs in 3 months To: Message-ID: <000d01ca057e$eb43fcc0$6400a8c0@would9> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Our Acai diet plan has proven results boost your immune system. Enter instantly http://aimckgwo.cn best regards Michele Neff From owner-namedroppers@ops.ietf.org Thu Jul 16 10:35:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C453A6C7F; Thu, 16 Jul 2009 10:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.775 X-Spam-Level: **** X-Spam-Status: No, score=4.775 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNbsOOEaUpMM; Thu, 16 Jul 2009 10:35:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 369263A67AE; Thu, 16 Jul 2009 10:34:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MRUjl-0003uj-Tf for namedroppers-data0@psg.com; Thu, 16 Jul 2009 17:27:17 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MRUjh-0003uE-4v for namedroppers@ops.ietf.org; Thu, 16 Jul 2009 17:27:15 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1MRUjf-0000Ev-Tf for namedroppers@ops.ietf.org; Thu, 16 Jul 2009 18:27:11 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MRUjf-0005gA-DN for namedroppers@ops.ietf.org; Thu, 16 Jul 2009 18:27:11 +0100 Message-ID: <38FBA98C22BA4ABA805BA6176CC0C900@localhost> From: "George Barwood" To: Subject: [dnsext] Notes on the DNS standard Date: Thu, 16 Jul 2009 18:27:06 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have put together a web page documenting areas when I feel the existing DNS standard is problematic, or where the proper or best way to implement DNS is unclear from the standard, etc. I intend to maintain it until a better resource is available that renders it redundant. The page is at http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/NotesOnDNS_Standard.htm It is intended to be public domain, you may freely copy part or all of it. Regards, 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 distensionk@ipropertynet.com Thu Jul 16 12:39:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1183A67E9; Thu, 16 Jul 2009 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.696 X-Spam-Level: X-Spam-Status: No, score=-9.696 tagged_above=-999 required=5 tests=[AWL=5.605, BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4FlOiHOhsOM; Thu, 16 Jul 2009 12:39:45 -0700 (PDT) Received: from cpe-74-69-226-252.maine.res.rr.com (cpe-74-69-226-252.maine.res.rr.com [74.69.226.252]) by core3.amsl.com (Postfix) with ESMTP id 29AA13A6DAE; Thu, 16 Jul 2009 12:39:13 -0700 (PDT) Date: Thu, 16 Jul 2009 15:38:43 -0500 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: energize , shed pounds rapidly with Acai Berry. Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Get your stock of acaiberry at superbly discounted prices
 
Do you have 14 days to take part in our weight loss trial?
Acai Berry will help you score in life , Get your trial now.


best regards Harland Tobin
From tackleduq3@isi-net.net Thu Jul 16 15:19:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDCF3A6D94; Thu, 16 Jul 2009 15:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.983 X-Spam-Level: X-Spam-Status: No, score=-23.983 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FS_WEIGHT_LOSS=2.134, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNs9dnFiLuyc; Thu, 16 Jul 2009 15:19:26 -0700 (PDT) Received: from l187.dkm.cz (l187.dkm.cz [62.24.77.187]) by core3.amsl.com (Postfix) with ESMTP id E7C703A6C06; Thu, 16 Jul 2009 15:19:25 -0700 (PDT) Date: Fri, 17 Jul 2009 00:19:45 +0100 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Rachel Ray's weight loss solution , Try Acai Berry. Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Losing weight is an amazing feeling.
 
Loose weight without hunger. Free Acai Berry Tiral.
If you are struggling and looking for effective ways to drop weight fast Try Acai Berry


best regards Rayna Hickey
From troubadours53@isana-ad.com Thu Jul 16 19:57:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CF23A6805; Thu, 16 Jul 2009 19:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.475 X-Spam-Level: X-Spam-Status: No, score=-28.475 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SXLIFE=1.07, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbXDiaLoTOhh; Thu, 16 Jul 2009 19:57:11 -0700 (PDT) Received: from pool-71-163-206-45.washdc.east.verizon.net (pool-71-163-206-45.washdc.east.verizon.net [71.163.206.45]) by core3.amsl.com (Postfix) with ESMTP id 340453A67E7; Thu, 16 Jul 2009 19:57:10 -0700 (PDT) Message-ID: <000d01ca068a$417b17c0$6400a8c0@troubadours53> From: To: Subject: Want a BetterSex Life use AcaiBerry Date: Thu, 16 Jul 2009 21:57:00 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA068A.417B17C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA068A.417B17C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you experience difficulty viewing=20 this message, you can view it in your browser. =20 =20 =20 eNews July=20 2009 =20 =20 =20 =20 =20 Fast and effective wieght loss solution Acai Flush.Visit our site =20   =20 =20 =20 Update your details | Unsubscribe or edit=20 optionsPlease forward this eNewsletter to a=20 friends ------=_NextPart_000_0007_01CA068A.417B17C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you experience difficulty view= ing=20 this message, you can view it in your browse= r.

eNews J= uly=20 2009


Fast and effective wieght loss solution Acai F= lush.

Visit our site<= /STRONG>
  Update your details | Unsubscribe or edit=20 options
Please forward this eNewsletter to a=20 friends

------=_NextPart_000_0007_01CA068A.417B17C0-- From everydayo@sexyshare.net Thu Jul 16 20:05:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510193A6805; Thu, 16 Jul 2009 20:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.058 X-Spam-Level: X-Spam-Status: No, score=-5.058 tagged_above=-999 required=5 tests=[BAYES_60=1, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FS_WEIGHT_LOSS=2.134, GB_I_LETTER=-2, GB_OPRAH=2, GB_PHARMACY=1, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyXg6OIVx8xS; Thu, 16 Jul 2009 20:05:51 -0700 (PDT) Received: from euz116.neoplus.adsl.tpnet.pl (euz116.neoplus.adsl.tpnet.pl [83.20.197.116]) by core3.amsl.com (Postfix) with ESMTP id AD3903A6E26; Thu, 16 Jul 2009 20:05:49 -0700 (PDT) Received: from 83.20.197.116 by mail.sexyshare.net; Fri, 17 Jul 2009 05:04:46 +0100 Date: Fri, 17 Jul 2009 05:04:46 +0100 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Oprah Weight Loss Solution , Try Anitrim with Acai Berries. Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0

Trouble viewing this e-mail? Click here.

Hot Pharmacy news
 
                    Lose weight fast and best of all keep it off.
           
            More Info

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

Click here to change your subscription format from HTML to text.

This message was sent to dnsext-archive@lists.ietf.org because you previously subscribed to the Kidod newsletter. If you would no longer like to receive future editions of this educatonal series, you can unsubscribe by clicking here.

Your privacy matters to us. Click here to read our privacy pledge. | Terms of Use

¿ Copyright 2004-2009 Udi. All rights reserved.
No part of this newsletter may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or any other information storage and retrieval system, without our written permission.
From futonszm@iranmatin.com Thu Jul 16 20:27:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC3C3A6A05; Thu, 16 Jul 2009 20:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.622 X-Spam-Level: X-Spam-Status: No, score=-10.622 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, GB_OPRAH=2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRqApwg6te8A; Thu, 16 Jul 2009 20:26:59 -0700 (PDT) Received: from cpe-075-181-010-205.carolina.res.rr.com (cpe-075-181-010-205.carolina.res.rr.com [75.181.10.205]) by core3.amsl.com (Postfix) with ESMTP id B1D7E3A68F4; Thu, 16 Jul 2009 20:26:58 -0700 (PDT) Message-ID: <000d01ca068e$82c67f90$6400a8c0@futonszm> From: To: Subject: Oprah's choice for staying healthy Date: Thu, 16 Jul 2009 20:27:28 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA068E.82C67F90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA068E.82C67F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Email=20 not displaying correctly? View=20 it in your browser. =20 =20 =20 =20 =20 =20 =20 Official=20 Daily newsletter =20 It works for Oprah and is endorsed by Rachel Ray. Make the flab disappear Press the button =20 =20 You=20 are subscribed as :action@ietf.org. Username:=20 action Unsubscribe=20 from this list. Manage=20 your subscriptions. View=20 the newsletter=20 archives. ¿=20 Copyright 2008 whfrrd. All rights reserved. ------=_NextPart_000_0007_01CA068E.82C67F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Email=20 not displaying correctly? View=20 it in your browser.
Official=20 Daily newsletter

It works for Oprah and is endorsed by = Rachel Ray.

Make the flab disappear

Press the button

You=20 are subscribed as :action@ietf.org. Username:=20 action Unsubscribe=20 from this list.

Manage=20 your subscriptions.

View=20 the newsletter=20 archives.

¿=20 Copyright 2008 whfrrd. All rights reserved.
------=_NextPart_000_0007_01CA068E.82C67F90-- From horseradish87@iranfrp.com Thu Jul 16 21:08:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87A63A67E7; Thu, 16 Jul 2009 21:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.729 X-Spam-Level: X-Spam-Status: No, score=-20.729 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2JeqWqFolkC; Thu, 16 Jul 2009 21:08:22 -0700 (PDT) Received: from 94-241-231-201.fibertel.com.ar (94-241-231-201.fibertel.com.ar [201.231.241.94]) by core3.amsl.com (Postfix) with ESMTP id 7EF853A657C; Thu, 16 Jul 2009 21:08:19 -0700 (PDT) Message-ID: <000d01ca0694$47312510$6400a8c0@horseradish87> From: To: Subject: Acai Berry , Oprah endorsed wieght loss solution. Date: Fri, 17 Jul 2009 01:08:45 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0694.47312510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0694.47312510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Email=20 not displaying correctly? View=20 it in your browser. =20 =20 =20 =20 =20 =20 =20 Official=20 Daily newsletter =20 Regulate your metabolism and lose weight fast. Acai Berry , lose unwanted weight fast. Pay a visit =20 =20 You=20 are subscribed as :emu-request@ietf.org. Username:=20 emu-request Unsubscribe=20 from this list. Manage=20 your subscriptions. View=20 the newsletter=20 archives. ¿=20 Copyright 2008 giezlt. All rights reserved. ------=_NextPart_000_0007_01CA0694.47312510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Email=20 not displaying correctly? View=20 it in your browser.
Official=20 Daily newsletter

Regulate your metabolism and lose weig= ht fast.

Acai Berry , lose unwanted weight fast=

Pay a visit

You=20 are subscribed as :emu-request@ietf.org. Username:=20 emu-request Unsubscribe=20 from this list.

Manage=20 your subscriptions.

View=20 the newsletter=20 archives.

¿=20 Copyright 2008 giezlt. All rights reserved.
------=_NextPart_000_0007_01CA0694.47312510-- From robuster1526@isonal.com Fri Jul 17 06:56:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A49128C1F6; Fri, 17 Jul 2009 06:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.096 X-Spam-Level: X-Spam-Status: No, score=-25.096 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+KGngfrIWjB; Fri, 17 Jul 2009 06:56:05 -0700 (PDT) Received: from host209.201-252-252.telecom.net.ar (host209.201-252-252.telecom.net.ar [201.252.252.209]) by core3.amsl.com (Postfix) with ESMTP id C625A28C2C9; Fri, 17 Jul 2009 06:56:04 -0700 (PDT) Received: from 201.252.252.209 by queue.iae.nl; Fri, 17 Jul 2009 15:56:13 +0100 Date: Fri, 17 Jul 2009 15:56:13 +0100 From: aaa-archive@lists.ietf.org Subject: Live long , healthy and happy with your new body, get your trial of Acai Berry now ! To: Message-ID: <000d01ca06e6$58d06ea0$6400a8c0@robuster1526> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal The product that everyone is talking about - acaiberry Push the button now http://aibyeywo.cn best regards Rudolph Parrish From aldrin4@islamicmedia.com.au Fri Jul 17 06:56:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B0E28C206; Fri, 17 Jul 2009 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HGyxQoVhHOm; Fri, 17 Jul 2009 06:56:45 -0700 (PDT) Received: from 201-92-60-14.dsl.telesp.net.br (201-92-60-14.dsl.telesp.net.br [201.92.60.14]) by core3.amsl.com (Postfix) with ESMTP id A6D3628C2CC; Fri, 17 Jul 2009 06:56:44 -0700 (PDT) Received: from 201.92.60.14 by islamicmedia.com.au; Fri, 17 Jul 2009 10:56:18 -0300 Date: Fri, 17 Jul 2009 10:56:18 -0300 From: action@ietf.org Subject: Highly nutricious Acai Berry available now! get your trial now. To: Message-ID: <000d01ca06e6$5b96e1a0$6400a8c0@aldrin4> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Lose weight feel great with Acai Berry. Click everybody http://aibyeywo.cn best regards Debi Trevino From february1@isodope.net Fri Jul 17 09:20:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC8B3A6896; Fri, 17 Jul 2009 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.488 X-Spam-Level: X-Spam-Status: No, score=-28.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17ttCxowPCam; Fri, 17 Jul 2009 09:20:40 -0700 (PDT) Received: from 127.230.85-79.rev.gaoland.net (127.230.85-79.rev.gaoland.net [79.85.230.127]) by core3.amsl.com (Postfix) with ESMTP id E14093A6972; Fri, 17 Jul 2009 09:20:39 -0700 (PDT) Received: from 79.85.230.127 by eforwardct.name-services.com; Fri, 17 Jul 2009 18:21:12 +0100 Message-ID: <000d01ca06fa$997f06f0$6400a8c0@february1> From: To: Subject: Make the fat disappear Date: Fri, 17 Jul 2009 18:21:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA06FA.997F06F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA06FA.997F06F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable natural powers will rejuvinate your health and looks, no cost trial Super tasty and Super Healthy , Try Acai FLush Now!   More Info =A0 =A0 Thank You!=20 best regards Deidre=20 Rowland ------=_NextPart_000_0007_01CA06FA.997F06F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
natural powers will rejuvinate your health and looks, no cost tria= l
Super tasty and Super Healthy , Try Acai FLush Now!<= /STRONG>
 
More Info
=A0
=A0
Thank You!
best regards Deidre=20 Rowland
------=_NextPart_000_0007_01CA06FA.997F06F0-- From rubinstein930@isdesignlab.com Fri Jul 17 09:22:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453E33A68E3; Fri, 17 Jul 2009 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.956 X-Spam-Level: X-Spam-Status: No, score=-19.956 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ebykche4LTC2; Fri, 17 Jul 2009 09:22:16 -0700 (PDT) Received: from 201-13-35-121.dsl.telesp.net.br (201-13-35-121.dsl.telesp.net.br [201.13.35.121]) by core3.amsl.com (Postfix) with ESMTP id 147AD3A68DE; Fri, 17 Jul 2009 09:22:15 -0700 (PDT) Received: from 201.13.35.121 by isdesignlab.com; Fri, 17 Jul 2009 13:22:29 -0300 Message-ID: <000d01ca06fa$c780d420$6400a8c0@rubinstein930> From: To: Subject: Get Your Free Acai Berry Trial Now Date: Fri, 17 Jul 2009 13:22:29 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA06FA.C780D420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA06FA.C780D420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Safely Boost your energy with Acai Slim, Endorsed by Rachel Ray.=20 Hollywoods hottest diet is now available to you.   More... =A0 =A0 Thank You!=20 best regards Alida=20 Patrick ------=_NextPart_000_0007_01CA06FA.C780D420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Safely Boost your energy with Acai Slim, Endorsed by Rachel Ray. <= /FONT>
Hollywoods hottest diet is now available to you.
 
More...<= /DIV>
=A0
=A0
Thank You!
best regards Alida=20 Patrick
------=_NextPart_000_0007_01CA06FA.C780D420-- From elizabethawzk50@italianfortoddlers.com Fri Jul 17 10:36:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2BB3A6EB1; Fri, 17 Jul 2009 10:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.076 X-Spam-Level: X-Spam-Status: No, score=-43.076 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_WEB=0.619, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhnyq1rMv+PH; Fri, 17 Jul 2009 10:36:34 -0700 (PDT) Received: from static-215-82.is.net.pl (static-215-82.is.net.pl [217.144.215.82]) by core3.amsl.com (Postfix) with ESMTP id 83A593A6EAC; Fri, 17 Jul 2009 10:36:33 -0700 (PDT) Received: from 217.144.215.82 by hood.cnchost.com; Fri, 17 Jul 2009 19:36:57 +0100 Message-ID: <000d01ca0705$2ee1a090$6400a8c0@elizabethawzk50> From: To: Subject: Get hit on more often with Acai Berry Date: Fri, 17 Jul 2009 19:36:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0705.2EE1A090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0705.2EE1A090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Email=20 not displaying correctly? View=20 it in your browser. =20 =20 =20 =20 =20 =20 =20 Official=20 Daily newsletter =20 Boost energy levels by adding Acai berry to your diet. Rachel Ray's weight loss solution , Try Acai Berry. Asking you to click =20 =20 You=20 are subscribed as :cosmogol-request@ietf.org. Username:=20 cosmogol-request Unsubscribe=20 from this list. Manage=20 your subscriptions. View=20 the newsletter=20 archives. ¿=20 Copyright 2008 qqtnmx. All rights reserved. ------=_NextPart_000_0007_01CA0705.2EE1A090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Email=20 not displaying correctly? View=20 it in your browser.
Official=20 Daily newsletter

Boost energy levels by adding Acai ber= ry to your diet.

Rachel Ray's weight loss solution , T= ry Acai Berry.

Asking you to click

<= /DIV>
You=20 are subscribed as :cosmogol-request@ietf.org. Username:=20 cosmogol-request Unsubscribe=20 from this list.

Manage=20 your subscriptions.

View=20 the newsletter=20 archives.

¿=20 Copyright 2008 qqtnmx. All rights reserved.
------=_NextPart_000_0007_01CA0705.2EE1A090-- From unbosomingsdz9@ip-domo.net Fri Jul 17 10:39:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88873A6956; Fri, 17 Jul 2009 10:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.846 X-Spam-Level: X-Spam-Status: No, score=-35.846 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MX=0.535, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_DSL_3=1.022, SARE_UNI=0.591, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaMRKHNapTqC; Fri, 17 Jul 2009 10:39:14 -0700 (PDT) Received: from dsl-200-67-68-68.prod-empresarial.com.mx (dsl-200-67-68-68.prod-empresarial.com.mx [200.67.68.68]) by core3.amsl.com (Postfix) with ESMTP id 719B43A6886; Fri, 17 Jul 2009 10:38:47 -0700 (PDT) Received: from 200.67.68.68 by polifemo.ip-domo.net; Fri, 17 Jul 2009 12:40:56 -0600 Message-ID: <000d01ca0705$bd4e0bc0$6400a8c0@unbosomingsdz9> From: To: Subject: Acai Slim, lose weight without starving yourself. Date: Fri, 17 Jul 2009 12:40:56 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0705.BD4E0BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0705.BD4E0BC0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Email=20 not displaying correctly? View=20 it in your browser. =20 =20 =20 =20 =20 =20 =20 Official=20 Daily newsletter =20 Get your Free trial today! learn how to look great without hard work, try it free Just press the button =20 =20 You=20 are subscribed as :dnsext-archive@lists.ietf.org. Username:=20 dnsext-archive Unsubscribe=20 from this list. Manage=20 your subscriptions. View=20 the newsletter=20 archives. ¿=20 Copyright 2008 ibwu. All rights reserved. ------=_NextPart_000_0007_01CA0705.BD4E0BC0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Email=20 not displaying correctly? View=20 it in your browser.
Official=20 Daily newsletter

Get your Free trial today!

learn how to look great without hard w= ork, try it free

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

Manage=20 your subscriptions.

View=20 the newsletter=20 archives.

¿=20 Copyright 2008 ibwu. All rights reserved.
------=_NextPart_000_0007_01CA0705.BD4E0BC0-- From dowdiness0@isleptthroughclass.com Fri Jul 17 12:08:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217D328C331; Fri, 17 Jul 2009 12:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.553 X-Spam-Level: X-Spam-Status: No, score=-16.553 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, UNPARSEABLE_RELAY=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2FKf68oE9LU; Fri, 17 Jul 2009 12:08:01 -0700 (PDT) Received: from static-host119-30-121-4.link.net.pk (static-host119-30-121-4.link.net.pk [119.30.121.4]) by core3.amsl.com (Postfix) with ESMTP id E9E7B3A6E8C; Fri, 17 Jul 2009 12:08:00 -0700 (PDT) Received: from 119.30.121.4 by mail.isleptthroughclass.com Date: Fri, 17 Jul 2009 12:08:15 -0800 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Acai diet will lead to incredible weight loss. Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Acai Berry trial Availabel now!
 
Lose that fat fast
Lose Weight without the effort it takes


best regards Karrie Pacheco
From tracker227@rkcenters.com Fri Jul 17 12:32:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8153A68EF; Fri, 17 Jul 2009 12:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.764 X-Spam-Level: X-Spam-Status: No, score=-19.764 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2zKgMZ6gEWU; Fri, 17 Jul 2009 12:32:33 -0700 (PDT) Received: from 200-207-227-148.dial-up.telesp.net.br (200-207-227-148.dial-up.telesp.net.br [200.207.227.148]) by core3.amsl.com (Postfix) with ESMTP id F1DDC3A6AF8; Fri, 17 Jul 2009 12:32:32 -0700 (PDT) Received: from 200.207.227.148 by server504.appriver.com; Fri, 17 Jul 2009 16:32:44 -0300 Date: Fri, 17 Jul 2009 16:32:44 -0300 Message-Id: <5MEMW53964.VA2YQ6I77215@200.207.227.148> From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Anitrim with Acai Berries your answer for losing weight fast. Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Click here to view as a web page.

Lose weight without starving yourself Anitrim with Acai Berries, get your trial Now.
Unsubscribe |  Change e-mail address |  Privacy Policy |  About Us

Copyright (c) 2009 wasjm Inc. All rights reserved.
 
From paradigmatic816@isginfrared.com Fri Jul 17 15:35:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DC93A6A97; Fri, 17 Jul 2009 15:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo8-H-0U6Gxv; Fri, 17 Jul 2009 15:35:32 -0700 (PDT) Received: from 173-29-250-23.client.mchsi.com (173-29-250-23.client.mchsi.com [173.29.250.23]) by core3.amsl.com (Postfix) with ESMTP id 6A0313A6781; Fri, 17 Jul 2009 15:35:32 -0700 (PDT) Received: from 173.29.250.23 by mail.east.cbeyond.com; Fri, 17 Jul 2009 17:35:30 -0600 Message-ID: <000d01ca072e$e4134a80$6400a8c0@paradigmatic816> From: To: Subject: Tight and sexy body in weeks, try acai for free Date: Fri, 17 Jul 2009 17:35:30 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA072E.E4134A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA072E.E4134A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Acai Berry is your ticket to a slim sexy new you.   conquer the impossible, look great today =20 Hurry to come =20 best regards Tamara=20 Valle =20 =20 ------=_NextPart_000_0007_01CA072E.E4134A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Aca= i Berry is your ticket to a slim sexy new you.
&n= bsp;
conquer the impossible, look great today
<= A=20 href=3D"http://ihxly60.aivwjjso.cn/">Hurry to come
best regards Tamara=20 Valle
------=_NextPart_000_0007_01CA072E.E4134A80-- From kirchhoff4@italy-exclusive.com Fri Jul 17 20:23:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1769F3A6F76; Fri, 17 Jul 2009 20:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.236 X-Spam-Level: X-Spam-Status: No, score=-20.236 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGfue-kLg151; Fri, 17 Jul 2009 20:23:23 -0700 (PDT) Received: from cpe-173-170-97-23.tampabay.res.rr.com (cpe-173-170-97-23.tampabay.res.rr.com [173.170.97.23]) by core3.amsl.com (Postfix) with ESMTP id 194A93A6F5F; Fri, 17 Jul 2009 20:22:52 -0700 (PDT) Received: from 173.170.97.23 by pop.italy-exclusive.com; Fri, 17 Jul 2009 23:23:00 -0500 Date: Fri, 17 Jul 2009 23:23:00 -0500 From: dix@ietf.org Subject: Get The Edge Over Everyone Else click Here for your Weight loss Trial To: Message-ID: <000d01ca0757$0dddf680$6400a8c0@kirchhoff4> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Lose fat painlessly Acai Berry Get your free trial. Just one move to visit http://aifhfuoo.cn From thoraxbq78@isfentertainment.com Fri Jul 17 21:22:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8133A6893; Fri, 17 Jul 2009 21:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.814 X-Spam-Level: X-Spam-Status: No, score=-14.814 tagged_above=-999 required=5 tests=[FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_DHCP=1.52, HELO_DYNAMIC_IPADDR=2.935, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttd6qxVScg3f; Fri, 17 Jul 2009 21:22:33 -0700 (PDT) Received: from cpe-72-224-248-138.maine.res.rr.com (cpe-72-224-248-138.maine.res.rr.com [72.224.248.138]) by core3.amsl.com (Postfix) with ESMTP id BDD263A677E; Fri, 17 Jul 2009 21:22:17 -0700 (PDT) Received: from 72.224.248.138 by mail.isfentertainment.com; Sat, 18 Jul 2009 00:21:40 -0500 Date: Sat, 18 Jul 2009 00:21:40 -0500 From: dcpel-bounces@ietf.org Subject: Lose 5 pds a day , with accai berry. To: Message-ID: <000d01ca075f$3fec2a90$6400a8c0@thoraxbq78> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Promotes Increased Energy Levels and Decreased Fatigue Hollywood stars use it, You should try it. Click at the moment http://aifhfuoo.cn From delawarean78@retailwestinc.com Sun Jul 19 12:53:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2383A69C1; Sun, 19 Jul 2009 12:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt-yhd68IHLU; Sun, 19 Jul 2009 12:53:46 -0700 (PDT) Received: from ip13b.wilan.pl (ip13b.wilan.pl [83.1.165.13]) by core3.amsl.com (Postfix) with ESMTP id 6E5733A69A5; Sun, 19 Jul 2009 12:53:46 -0700 (PDT) Message-ID: <000d01ca08aa$7d7543a0$6400a8c0@delawarean78> From: To: Subject: You've received a greeting ecard Date: Sun, 19 Jul 2009 21:52:47 +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.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam: Not detected Good day. You have received an eCard To pick up your eCard, choose from any of the following options: Click on the following link (or copy & paste it into your web browser): http://sensecost.com/ Your card will be aviailable for pick-up beginning for the next 30 days. Please be sure to view your eCard before the days are up! We hope you enjoy you eCard. Thank You! From magicn89@shkp.ru Sun Jul 19 19:25:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34AC28C10A; Sun, 19 Jul 2009 19:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUqA+Rxb3gMO; Sun, 19 Jul 2009 19:25:31 -0700 (PDT) Received: from cpe-76-187-166-72.tx.res.rr.com (cpe-76-187-166-72.tx.res.rr.com [76.187.166.72]) by core3.amsl.com (Postfix) with ESMTP id 98EAA28C0F5; Sun, 19 Jul 2009 19:25:31 -0700 (PDT) Date: Sun, 19 Jul 2009 21:25:17 -0600 From: Subject: You've received a greeting ecard To: Message-ID: <000d01ca08e1$522cc510$6400a8c0@magicn89> MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Mailer: Microsoft Windows Mail 6.0.6001.18000 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Good day. You have received an eCard To pick up your eCard, choose from any of the following options: Click on the following link (or copy & paste it into your web browser): http://sensecost.com/ Your card will be aviailable for pick-up beginning for the next 30 days. Please be sure to view your eCard before the days are up! We hope you enjoy you eCard. Thank You! From waldov8250@sisco.e.telefonica.net Sun Jul 19 22:53:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379AE3A6894; Sun, 19 Jul 2009 22:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHOUJ33497y8; Sun, 19 Jul 2009 22:53:19 -0700 (PDT) Received: from 143.Red-80-35-205.staticIP.rima-tde.net (143.Red-80-35-205.staticIP.rima-tde.net [80.35.205.143]) by core3.amsl.com (Postfix) with ESMTP id 825453A67B8; Sun, 19 Jul 2009 22:53:18 -0700 (PDT) Date: Mon, 20 Jul 2009 07:53:16 +0100 From: Subject: You've received a greeting ecard To: Message-ID: <000d01ca08fe$602c45b0$6400a8c0@waldov8250> MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Mailer: Microsoft Windows Mail 6.0.6001.18000 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Good day. You have received an eCard To pick up your eCard, choose from any of the following options: Click on the following link (or copy & paste it into your web browser): http://sensecost.com/ Your card will be aviailable for pick-up beginning for the next 30 days. Please be sure to view your eCard before the days are up! We hope you enjoy you eCard. Thank You! From owner-namedroppers@ops.ietf.org Mon Jul 20 03:53:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAE13A69E8; Mon, 20 Jul 2009 03:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.784 X-Spam-Level: X-Spam-Status: No, score=-105.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftVF7Gd9n69P; Mon, 20 Jul 2009 03:53:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 426CA3A659B; Mon, 20 Jul 2009 03:53:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MSqNA-00021d-0R for namedroppers-data0@psg.com; Mon, 20 Jul 2009 10:45:32 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MSqN6-00021H-DU for namedroppers@ops.ietf.org; Mon, 20 Jul 2009 10:45:30 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 33BBE1C00D9; Mon, 20 Jul 2009 12:45:27 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 2E6941C0092; Mon, 20 Jul 2009 12:45:27 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 2C7ECA1D981; Mon, 20 Jul 2009 12:45:27 +0200 (CEST) Date: Mon, 20 Jul 2009 12:46:45 +0200 From: Stephane Bortzmeyer To: George Barwood Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Notes on the DNS standard Message-ID: <20090720104645.GA13148@nic.fr> References: <38FBA98C22BA4ABA805BA6176CC0C900@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38FBA98C22BA4ABA805BA6176CC0C900@localhost> X-Operating-System: Debian GNU/Linux 5.0.2 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 16, 2009 at 06:27:06PM +0100, George Barwood wrote a message of 24 lines which said: > the proper or best way to implement DNS is unclear from the > standard, etc. The majority of your notes are for areas where there is not one right behaviour, when a compliant name server can choose among several solutions. This is not always a mistake from the standard, it can be a good thing to let things unspecified, to allow name servers to make different trade-offs, for instance. I'm not convinced by some of your notes because you never explain clearly why this freedom left by the standard is a bad thing and why it hurts interoperability and/or security. Also, it seems that several of the changes you advocate (such as stronger bailiwick checking) require the resolver to discover the zone cuts. This is, in itself, a difficult subproblem, worth of its own discussion. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From uncouplesesv34@ritter1.com Mon Jul 20 06:11:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6B63A6D57; Mon, 20 Jul 2009 06:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.745 X-Spam-Level: X-Spam-Status: No, score=-40.745 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134, TVD_RCVD_IP=1.931, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeOtpgmWlV5I; Mon, 20 Jul 2009 06:11:08 -0700 (PDT) Received: from host90.190-229-18.telecom.net.ar (host90.190-229-18.telecom.net.ar [190.229.18.90]) by core3.amsl.com (Postfix) with ESMTP id BDC783A6BD5; Mon, 20 Jul 2009 06:11:07 -0700 (PDT) Message-ID: <000d01ca093b$21ee3460$6400a8c0@uncouplesesv34> From: To: Subject: You've received a greeting ecard Date: Mon, 20 Jul 2009 10:08:11 -0300 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.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam: Not detected Good day. You have received an eCard To pick up your eCard, choose from any of the following options: Click on the following link (or copy & paste it into your web browser): http://softokors.com/ Your card will be aviailable for pick-up beginning for the next 30 days. Please be sure to view your eCard before the days are up! We hope you enjoy you eCard. Thank You! From dumpierx@irenesnautical.com Mon Jul 20 07:36:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63CC3A6C7B; Mon, 20 Jul 2009 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.132 X-Spam-Level: X-Spam-Status: No, score=-20.132 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe0Y7IaVzgoK; Mon, 20 Jul 2009 07:36:43 -0700 (PDT) Received: from 201-27-183-206.dsl.telesp.net.br (201-95-112-227.dsl.telesp.net.br [201.95.112.227]) by core3.amsl.com (Postfix) with ESMTP id 4C7AF3A67EF; Mon, 20 Jul 2009 07:36:39 -0700 (PDT) Received: from 201.95.112.227 by irenesnautical.com; Mon, 20 Jul 2009 11:36:32 -0300 Date: Mon, 20 Jul 2009 11:36:32 -0300 From: Subject: Acai Burns your fat away look and feel great. To: Message-ID: <000d01ca0947$79e61410$6400a8c0@dumpierx> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Rich in antioxidants , Acai Berry is your answer to unwanted weight. start your new life today with a a free trial of Acai FLush. Hurry to click http://aivsvxwo.cn From leathersvxbb546@isdtech.com Mon Jul 20 07:40:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BB63A6D97; Mon, 20 Jul 2009 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -60.914 X-Spam-Level: X-Spam-Status: No, score=-60.914 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FS_START_LOSE=1.493, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SUBJECT_DIET=1.466, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99mKougWtui0; Mon, 20 Jul 2009 07:40:02 -0700 (PDT) Received: from acuz226.neoplus.adsl.tpnet.pl (acuz226.neoplus.adsl.tpnet.pl [83.11.105.226]) by core3.amsl.com (Postfix) with ESMTP id 774DE3A6D92; Mon, 20 Jul 2009 07:40:01 -0700 (PDT) Received: from 83.11.105.226 by isdtech.com; Mon, 20 Jul 2009 16:39:53 +0100 Content-type: text/html; charset="iso-8859-2" MIME-Version: 1.0 Message-ID: Date: Mon, 20 Jul 2009 16:39:53 +0100 From: "Reagan Shearer" To: dcpel-owner@ietf.org Subject: Lose weight fast with the world's #1 acai berry Free Trial All natural Weight Loss Solution , Try Acai Berry. You can be another on the long lish of Acai Success stories. A straight click http://aiclbkto.cn From rearranged3@isntmedia.com Mon Jul 20 07:43:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBB03A6941; Mon, 20 Jul 2009 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.41 X-Spam-Level: X-Spam-Status: No, score=-53.41 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_RELAY_NODNS=1.451, FS_WEIGHT_LOSS=2.134, GB_OPRAH=2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxUUiN6yMUcA; Mon, 20 Jul 2009 07:43:11 -0700 (PDT) Received: from adsl-pool2-18.metrotel.net.co (unknown [190.182.8.18]) by core3.amsl.com (Postfix) with ESMTP id 745AA3A6D9D; Mon, 20 Jul 2009 07:43:09 -0700 (PDT) Received: from 190.182.8.18 by mail.isntmedia.com; Mon, 20 Jul 2009 09:43:06 -0500 Date: Mon, 20 Jul 2009 09:43:06 -0500 From: Subject: Oprah Endorsed weight loss , Try Acai Berry. To: Message-ID: <000d01ca0948$649ebb60$6400a8c0@rearranged3> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal LoseWeight Natural SuperFood endorsed by Oprah Winfrey, FREE TRIAL 1 bottle, only pay $5.95 for shipping This all natuaral wieght loss soltion leads to effective weightloss. Visit this site http://aiclbkto.cn From mayflowersqll@islandia.com Mon Jul 20 08:41:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E994428C18B; Mon, 20 Jul 2009 08:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.728 X-Spam-Level: X-Spam-Status: No, score=-16.728 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbR5jTy-2Iq7; Mon, 20 Jul 2009 08:41:33 -0700 (PDT) Received: from 196-210-156-203-wblv-esr-4.dynamic.isadsl.co.za (196-210-156-203-wblv-esr-4.dynamic.isadsl.co.za [196.210.156.203]) by core3.amsl.com (Postfix) with ESMTP id 6C8353A6C79; Mon, 20 Jul 2009 08:41:32 -0700 (PDT) Received: from 196.210.156.203 by nullmx.islandia.com; Mon, 20 Jul 2009 17:41:27 +0200 Message-ID: <000d01ca0950$8b504e10$6400a8c0@mayflowersqll> From: To: Subject: LoseWeight Natural SuperFood endorsed by Oprah Winfrey, FREE TRIAL 1 bottle, only pay $5.95 for shipping Date: Mon, 20 Jul 2009 17:41:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0950.8B504E10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0950.8B504E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The simple solution to weight loss, Acai Berry . Get your healthy lifetyle now.   Press this button =20 =20 Thank You!=20 best regards Randolph=20 Grove ------=_NextPart_000_0007_01CA0950.8B504E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The simple solution to weight loss, Acai Berry .
Get your healthy lifetyle now.
 
Press this button=
Thank You!
best regards Randolph=20 Grove
------=_NextPart_000_0007_01CA0950.8B504E10-- From owner-namedroppers@ops.ietf.org Mon Jul 20 09:20:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2603528C197; Mon, 20 Jul 2009 09:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BMa7zinczEy; Mon, 20 Jul 2009 09:20:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 350503A6A0C; Mon, 20 Jul 2009 09:20:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MSvR9-000EBw-Jo for namedroppers-data0@psg.com; Mon, 20 Jul 2009 16:09:59 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MSvR2-000EAo-OA for namedroppers@ops.ietf.org; Mon, 20 Jul 2009 16:09:56 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MSvR0-0008GF-Mm; Mon, 20 Jul 2009 17:09:51 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MSvR0-0007fA-7Z; Mon, 20 Jul 2009 17:09:50 +0100 Message-ID: <786FCF6554AE4888AF6D5975235B6436@localhost> From: "George Barwood" To: "Stephane Bortzmeyer" Cc: References: <38FBA98C22BA4ABA805BA6176CC0C900@localhost> <20090720104645.GA13148@nic.fr> Subject: [dnsext] Re: Notes on the DNS standard Date: Mon, 20 Jul 2009 17:09:49 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Stephane Bortzmeyer" To: "George Barwood" Cc: Sent: Monday, July 20, 2009 11:46 AM Subject: Re: Notes on the DNS standard > On Thu, Jul 16, 2009 at 06:27:06PM +0100, > George Barwood wrote > a message of 24 lines which said: > >> the proper or best way to implement DNS is unclear from the >> standard, etc. > > The majority of your notes are for areas where there is not one right > behaviour, when a compliant name server can choose among several > solutions. This is not always a mistake from the standard, it can be a > good thing to let things unspecified, to allow name servers to make > different trade-offs, for instance. I agree with your point in principle, but I believe that in each case an addition or change to the standard is worthy of consideration. > I'm not convinced by some of your notes because you never explain > clearly why this freedom left by the standard is a bad thing and why > it hurts interoperability and/or security. Such explanations could be added, but I think in most cases it's fairly self-evident. Some of the problems are quite minor, such as [6. Truncation], where it's a case of mild inefficiency. On the other hand the ramifications of [8. Spoofing] are very complex indeed. > Also, it seems that several of the changes you advocate (such as > stronger bailiwick checking) require the resolver to discover the zone > cuts. This is, in itself, a difficult subproblem, worth of its own > discussion. I think it's well known that Bailiwick checking is essential, to prevent malicious servers issuing DNS records for which they have no authority. The main point I raise is that this is not, as far as I know, mentioned anywhere in the RFCs, which seems a significant omission. The secondary point is how the checking should be described if it were to be added - in fact I believe my suggestion is actually weaker (and thus better) than standard practice - although nevertheless secure. I don't however see that bailiwick checking requires the resolver to discover zone cuts. That would seem more applicable to [1. Partial delegation], but maybe I'm missing something. Regards, 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 graduationskmr@islandgrace.com Mon Jul 20 15:12:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DEA28C25E; Mon, 20 Jul 2009 15:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.566 X-Spam-Level: X-Spam-Status: No, score=-27.566 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_INCREASE_YOUR=10.357, FH_FAKE_RCVD_LINE_B=5.777, GB_I_INVITATION=-2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le6Cw7+gSBw0; Mon, 20 Jul 2009 15:12:54 -0700 (PDT) Received: from bl10-86-190.dsl.telepac.pt (bl10-86-190.dsl.telepac.pt [85.243.86.190]) by core3.amsl.com (Postfix) with ESMTP id C2A2928C20A; Mon, 20 Jul 2009 15:12:53 -0700 (PDT) Received: from 85.243.86.190 by mail.islandgrace.com; Mon, 20 Jul 2009 23:11:46 +0000 Message-ID: <000d01ca0987$1275deb0$6400a8c0@graduationskmr> From: To: Subject: You want more energy , Acai Berry will increase your energy levels. Date: Mon, 20 Jul 2009 23:11:46 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0987.1275DEB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0987.1275DEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Overcome your obstacles with the help of Acai Berry.   Get Acai Berry working for you with your Free Trial of Acai Flush. =20 Accept our invitation =20 best regards Aleah=20 Kimble =20 =20 ------=_NextPart_000_0007_01CA0987.1275DEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ove= rcome your obstacles with the help of Acai Berry.
&n= bsp;
Get Acai Berry working for you with your Free Trial = of Acai Flush.
<= A=20 href=3D"http://vizgquh844.ainkvpuo.cn/">Accept our invitation
best regards Aleah=20 Kimble
------=_NextPart_000_0007_01CA0987.1275DEB0-- From lozengem46@isfirsati.com Mon Jul 20 19:52:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC2A28C1AE; Mon, 20 Jul 2009 19:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.807 X-Spam-Level: X-Spam-Status: No, score=-12.807 tagged_above=-999 required=5 tests=[BAYES_80=2, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, UNPARSEABLE_RELAY=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeehcNL9QwmF; Mon, 20 Jul 2009 19:52:11 -0700 (PDT) Received: from 97-119-183-227.albq.qwest.net (97-119-183-227.albq.qwest.net [97.119.183.227]) by core3.amsl.com (Postfix) with ESMTP id 953593A6E05; Mon, 20 Jul 2009 19:52:10 -0700 (PDT) Received: from 97.119.183.227 by mail.isfirsati.com Date: Mon, 20 Jul 2009 20:51:51 -0700 Message-Id: <2TN3JZ111597.8ROCY0N1JH1680@97.119.183.227.isfirsati.com> From: dix@ietf.org To: dix@ietf.org Subject: Lose weight with this Trial Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
It is easy to get started on your new life.
 
Boost Energy Levels, Try Acai Berry.
Acai Slim, get the body you always wanted.


best regards Gwen Starks
From extinguishercf3@rivamed.com.ar Mon Jul 20 21:16:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2CB3A6E07; Mon, 20 Jul 2009 21:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.405 X-Spam-Level: X-Spam-Status: No, score=-36.405 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HOST_EQ_DHCP=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocrhdwPrK9ZR; Mon, 20 Jul 2009 21:16:05 -0700 (PDT) Received: from hss1-dhcp-18.kaist.ac.kr (hss1-dhcp-18.kaist.ac.kr [143.248.248.202]) by core3.amsl.com (Postfix) with ESMTP id E50E23A6AA0; Mon, 20 Jul 2009 21:16:04 -0700 (PDT) Received: from 143.248.248.202 by rivamed.com.ar; Tue, 21 Jul 2009 13:14:23 +0900 From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Always dream to be large? DrMaxMan. Date: Tue, 21 Jul 2009 13:14:23 +0900 Message-ID: MIME-version: 1.0 Content-type: text/html; charset="utf-8"
 Trouble viewing this e-mail? Click here.
Subscribe | Manage My Account
 


Quickly click

 
¿ 2009 Ejxoxobjnyo Inc.
All Rights reserved. Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.

You are currently subscribed as: dnsext-archive@lists.ietf.org.
Send this eNewsletter to a friend: Click here
Unsubscribe from this mailing list: Click here
Update your Profile: Click here

 
From shinniedh5@ioraid.com Tue Jul 21 09:12:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E702A3A6E68; Tue, 21 Jul 2009 09:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.527 X-Spam-Level: X-Spam-Status: No, score=-26.527 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, GB_OPRAH=2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWBgtgA9zhJt; Tue, 21 Jul 2009 09:12:59 -0700 (PDT) Received: from ip-88-153-205-128.unitymediagroup.de (ip-88-153-205-128.unitymediagroup.de [88.153.205.128]) by core3.amsl.com (Postfix) with ESMTP id E641C3A684C; Tue, 21 Jul 2009 09:12:58 -0700 (PDT) Received: from 88.153.205.128 by mail.macrepublic.co.uk; Tue, 21 Jul 2009 18:11:46 +0100 Message-ID: <000d01ca0a1d$f20e6740$6400a8c0@shinniedh5> From: To: Subject: Lose weight safely with Acai diet , endorsed by Oprah. Date: Tue, 21 Jul 2009 18:11:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0A1D.F20E6740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0A1D.F20E6740 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Get in on the secret with your free trial.   Fat Burning Secret Try Acai Berry. =20 Quickly click =20 best regards Hana=20 Wray =20 =20 ------=_NextPart_000_0007_01CA0A1D.F20E6740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Get= in on the secret with your free trial.
&n= bsp;
Fat Burning Secret Try Acai Berry.
<= A=20 href=3D"http://njara66.aipwktyo.cn/">Quickly click
best regards Hana=20 Wray
------=_NextPart_000_0007_01CA0A1D.F20E6740-- From gistxzq4@islandclubresorts.com Tue Jul 21 09:34:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F009D3A6B01; Tue, 21 Jul 2009 09:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.437 X-Spam-Level: X-Spam-Status: No, score=-28.437 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_WEIGHT_LOSS=2.134, GB_OPRAH=2, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdLKsn+Ajbcb; Tue, 21 Jul 2009 09:34:51 -0700 (PDT) Received: from static.207-5-122-180.microlnk.com (static.207-5-122-180.microlnk.com [207.5.122.180]) by core3.amsl.com (Postfix) with ESMTP id 150F73A6A93; Tue, 21 Jul 2009 09:34:50 -0700 (PDT) Received: from 207.5.122.180 by islandclubresorts.com; Tue, 21 Jul 2009 11:34:41 -0600 Message-ID: <000d01ca0a21$25c27560$6400a8c0@gistxzq4> From: To: Subject: Oprah Weight loss soloution , Learn about Acai Berry. Date: Tue, 21 Jul 2009 11:34:41 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0A21.25C27560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0A21.25C27560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Slow down your aging process , Try Acai Berry.=20 Get Noticed with Acai Berry.   Visit this site =20 =20 Thank You!=20 best regards Geo=20 Esparza ------=_NextPart_000_0007_01CA0A21.25C27560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Slow down your aging process , Try Acai Berry.
Get Noticed with Acai Berry.
 
Visit this site
Thank You!
best regards Geo=20 Esparza
------=_NextPart_000_0007_01CA0A21.25C27560-- From owner-namedroppers@ops.ietf.org Tue Jul 21 14:09:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A373A6EAA; Tue, 21 Jul 2009 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0TBYGiExNeV; Tue, 21 Jul 2009 14:09:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8958B3A6EA3; Tue, 21 Jul 2009 14:09:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTMTE-000Ab4-J6 for namedroppers-data0@psg.com; Tue, 21 Jul 2009 21:01:56 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTMT7-000AaQ-Rm for namedroppers@ops.ietf.org; Tue, 21 Jul 2009 21:01:51 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4F78C2FE8ED6 for ; Tue, 21 Jul 2009 21:01:48 +0000 (UTC) Date: Tue, 21 Jul 2009 17:01:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] DNSEXT agenda updated Message-ID: <20090721210146.GO2837@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, I've updated the DNSEXT agenda. Because of remarks that the times weren't clear because of the notation I used last time, this has explicit begin and end times for segments. Note that we plan to be ruthless about the schedule, so if you are planning remarks on any of these items, please plan to be brief. If you have items that you wish to have considered in the meeting, and your topic is not already somehow reflected on the agenda, you really need to tell me now. As you can see, this agenda is pretty full. We will be providing the usual administrative detail that often takes up portions of meetings by email; look for that soon. Best regards, Andrew (for the Chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 22 05:53:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250B13A685E; Wed, 22 Jul 2009 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YtpATsTWsa4; Wed, 22 Jul 2009 05:53:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F37AC3A6821; Wed, 22 Jul 2009 05:53:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTbDN-000FMV-I8 for namedroppers-data0@psg.com; Wed, 22 Jul 2009 12:46:33 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTbDH-000FLx-V8 for namedroppers@ops.ietf.org; Wed, 22 Jul 2009 12:46:31 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Subject:To:X-Mailer:Message-ID: From:Date:X-MIMETrack:MIME-Version:Content-type; b=wHZjdyu3fdgcFN320D+WIUzFmdbEwMjTNqgFTrJYUPCIEN7bWRxNYipH 0t/fF3p7fhYzvxBOgXaGf/sp+L+w29JDqKdMzgRDncZKKgPBUZQyMdUWy YCZ1/lxOpMh0rE7; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1248266788; x=1279802788; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20roy@nominet.org.uk|Subject:=20TALINK=20RRTYPE=20 review.=20Start=20of=20three=20week=20comment=20period |Date:=20Wed,=2022=20Jul=202009=2014:46:21=20+0200 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0; bh=PPjkwr3rJphRNqmimDR125sxhK9Xe8M/AdECT6cb5sU=; b=pDZB6ycm1+ISLPtvK0NHZMqOVhgP2Tpifq/1ry9KW49S4ylx/E1v23oA RkECRxUycT9ccYpHm9Yp+MWlnxGDRC4mlumj+LzyylVQPkeog6k/wjjO6 vYOnUaPsB2L3rC/; X-IronPort-AV: E=Sophos;i="4.43,247,1246834800"; d="scan'208";a="11645914" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Jul 2009 13:46:23 +0100 Subject: [dnsext] TALINK RRTYPE review. Start of three week comment period To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: roy@nominet.org.uk Date: Wed, 22 Jul 2009 14:46:21 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 22/07/2009 01:46:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, I have been assigned with the task of coordinating an expert-review of the DNS RRTYPE parameter allocation for TALINK, present in http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 . Attached is a completed template requesting an RRTYPE assignment under the procedures of draft-ietf-dnsext-2929bis. This request will be evaluated by expert review. This mail initiates a three week comment period on the RRTYPE request. If you have comments on the request, please post them to this list. Kind regards, Roy Arends --- Template from http://tools.ietf.org/html/rfc5395 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE A. Submission Date: 30, June 2009 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter: Name: Wouter Wijngaards Email Address: wouter@nlnetlabs.nl International telephone number: +31 20 888 4551 Other contact handles: - (Note: This information will be publicly posted.) D. Motivation for the new RRTYPE application? Please keep this part at a high level to inform the Expert and reviewers about uses of the RRTYPE. Remember most reviewers will be DNS experts that may have limited knowledge of your application space. A double linked list of names that contain specific DNSKEY data at those names. The type is to be used by applications that maintain trust anchors for DNS validators. The DNSKEY data is used to rollover trust anchors to the current key. Therefore they must know the start and end of the list, and be able to move forwards and backwards through the list. E. Description of the proposed RR type. This description can be provided in-line in the template, as an attachment, or with a publicly available URL: The RR is a data type, can be handled as an RFC3597 unknown record. No additional section processing. The rdata is two domain names, presentation format is the two domain names, wireformat the two domain names in uncompressed form. The type is used to link domain names. TALINK _start_ _end_ for the list head and TALINK _prev_ _next_ for linking the elements. To end the list, the root label '.' is used to denote the endpoints. Thus, the root can be the list head, but not a list element. This is fine, saves space and is less complex than other solutions for flagging list endpoints or an empty list. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? RP has two domain names but it means 'Responsible Person'. MINFO has two domain names but means 'Machine Information'. These types are compressed, which is nice. The PTR type is the right concept, but has only one domain name in its rdata, and I need two. If I use two PTRs then the validator cannot distinguish the previous and next pointer, because the ordering of RRs in an RRset is not fixed. Another alternative is using PTR records at _start, _end, _prev and _next prefixes for disambiguation. Prefixes limit the domains that can be used because of the max domain name length. This is the alternative I would consider if this application is denied. G. What mnemonic is requested for the new RRTYPE (optional)? Note: This can be left blank and the mnemonic decided after the template is accepted. TALINK (Trust Anchor LINK). H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new sub-registry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. No. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? no changes. J. Comments: - -- to unsubscribe send a message to namedroppers-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 Jul 22 07:27:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101C43A6A95; Wed, 22 Jul 2009 07:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGnr6IxqvDBp; Wed, 22 Jul 2009 07:27:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDAEA3A69C6; Wed, 22 Jul 2009 07:27:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTcgV-0005Q7-Kf for namedroppers-data0@psg.com; Wed, 22 Jul 2009 14:20:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTcgI-0005M7-Ql for namedroppers@ops.ietf.org; Wed, 22 Jul 2009 14:20:33 +0000 Received: from [10.31.200.128] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6MEKKcn009531; Wed, 22 Jul 2009 10:20:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 22 Jul 2009 10:16:41 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-963850075==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-963850075==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I have an extreme distaste for this proposal. RRSIG includes inception and expiration times to limit the window of opportunity for replay attacks as well as the lack of a revocation mechanism in DNSSEC. They shouldn't be ignored at all, when a spec says "Ignore date changes in the RRSIG" there ought to be a security impact analysis attached. The draft does not address the security issue of PFS (http://en.wikipedia.org/wiki/Perfect_forward_secrecy). I am concerned that if (say) a 3-year old KSK is finally "broken", it can be used to construct a new KSK chain to a false key. Maintaining a history of keys re-balances of key management in DNSSEC. If a KSK is effective for one year, it only has to meet the strength requirements for a year. If it will be used "forever" to lead through a chain of keys to the current key, the original KSK has to be stronger. For example, NIST is recommending 80 bits of strength until 2011 or so (in some cases) but 112 bits after that for some time. Keeping the KSK around in a history means 80 bits is no good even now. And then there's the issue of key disposal. The NIST recommendations I refer to are highlighted here: http://csrc.nist.gov/groups/ST/key_mgmt/documents/June09_Presentations/Elaine_Barker_Transitions_KMWS_June2009.pdf (to the best of my understanding). If a KSK is in use for 2010 it can be managed for a one-year effectivity. If there's history involved, we switch gears so that the KSK has an eternal effectivity. Given my uneasiness with the reason for the record type, I am against allocating a position in the registry. At 14:46 +0200 7/22/09, roy@nominet.org.uk wrote: >Dear colleagues, > >I have been assigned with the task of coordinating an expert-review of the >DNS RRTYPE parameter allocation for TALINK, present in >http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 . > >Attached is a completed template requesting an RRTYPE assignment under the >procedures of draft-ietf-dnsext-2929bis. > >This request will be evaluated by expert review. This mail initiates a >three week comment period on the RRTYPE request. If you have comments on >the request, please post them to this list. > >Kind regards, > >Roy Arends > > >--- > > > >Template from http://tools.ietf.org/html/rfc5395 > > > >DNS RRTYPE PARAMETER ALLOCATION TEMPLATE > > >A. Submission Date: > 30, June 2009 > >B. Submission Type: > [X] New RRTYPE > [ ] Modification to existing RRTYPE > >C. Contact Information for submitter: > Name: Wouter Wijngaards > Email Address: wouter@nlnetlabs.nl > International telephone number: +31 20 888 4551 > Other contact handles: - > (Note: This information will be publicly posted.) > >D. Motivation for the new RRTYPE application? > Please keep this part at a high level to inform the Expert and > reviewers about uses of the RRTYPE. Remember most reviewers > will be DNS experts that may have limited knowledge of your > application space. > >A double linked list of names that contain specific DNSKEY data at >those names. The type is to be used by applications that maintain trust >anchors for DNS validators. The DNSKEY data is used to rollover trust >anchors to the current key. Therefore they must know the start and end >of the list, and be able to move forwards and backwards through the list. > >E. Description of the proposed RR type. > This description can be provided in-line in the template, as an > attachment, or with a publicly available URL: > >The RR is a data type, can be handled as an RFC3597 unknown record. >No additional section processing. > >The rdata is two domain names, presentation format is the two >domain names, wireformat the two domain names in uncompressed form. > >The type is used to link domain names. >TALINK _start_ _end_ for the list head and >TALINK _prev_ _next_ for linking the elements. >To end the list, the root label '.' is used to denote the endpoints. > >Thus, the root can be the list head, but not a list element. >This is fine, saves space and is less complex than other solutions >for flagging list endpoints or an empty list. > >F. What existing RRTYPE or RRTYPEs come closest to filling that > need and why are they unsatisfactory? > >RP has two domain names but it means 'Responsible Person'. >MINFO has two domain names but means 'Machine Information'. >These types are compressed, which is nice. > >The PTR type is the right concept, but has only one domain >name in its rdata, and I need two. If I use two PTRs then >the validator cannot distinguish the previous and next pointer, >because the ordering of RRs in an RRset is not fixed. > >Another alternative is using PTR records at _start, _end, _prev and >_next prefixes for disambiguation. Prefixes limit the domains that >can be used because of the max domain name length. This is >the alternative I would consider if this application is denied. > >G. What mnemonic is requested for the new RRTYPE (optional)? > Note: This can be left blank and the mnemonic decided after the > template is accepted. > >TALINK (Trust Anchor LINK). > >H. Does the requested RRTYPE make use of any existing IANA > Registry or require the creation of a new IANA sub-registry in > DNS Parameters? > If so, please indicate which registry is to be used or created. > If a new sub-registry is needed, specify the allocation policy > for it and its initial contents. Also include what the > modification procedures will be. > >No. > >I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being > processed as an unknown RRTYPE (see [RFC3597])? > >no changes. > >J. Comments: > >- > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-963850075==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] TALINK RRTYPE review. Start of three week com
I have an extreme distaste for this proposal.

RRSIG includes inception and expiration times to limit the window of opportunity for replay attacks as well as the lack of a revocation mechanism in DNSSEC.  They shouldn't be ignored at all, when a spec says "Ignore date changes in the RRSIG" there ought to be a security impact analysis attached.

The draft does not address the security issue of PFS (http://en.wikipedia.org/wiki/Perfect_forward_secrecy).  I am concerned that if (say) a 3-year old KSK is finally "broken", it can be used to construct a new KSK chain to a false key.

Maintaining a history of keys re-balances of key management in DNSSEC.  If a KSK is effective for one year, it only has to meet the strength requirements for a year.  If it will be used "forever" to lead through a chain of keys to the current key, the original KSK has to be stronger.  For example, NIST is recommending 80 bits of strength until 2011 or so (in some cases) but 112 bits after that for some time.  Keeping the KSK around in a history means 80 bits is no good even now.  And then there's the issue of key disposal.

The NIST recommendations I refer to are highlighted here:
http://csrc.nist.gov/groups/ST/key_mgmt/documents/June09_Presentations/Elaine_Barker_Transitions_KMWS_June2009.pdf
(to the best of my understanding).

If a KSK is in use for 2010 it can be managed for a one-year effectivity.  If there's history involved, we switch gears so that the KSK has an eternal effectivity.

Given my uneasiness with the reason for the record type, I am against allocating a position in the registry.

At 14:46 +0200 7/22/09, roy@nominet.org.uk wrote:
>Dear colleagues,
>
>I have been assigned with the task of coordinating an expert-review of the
>DNS RRTYPE parameter allocation for TALINK, present in
>http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 .
>
>Attached is a completed template requesting an RRTYPE assignment under the
>procedures of draft-ietf-dnsext-2929bis.
>
>This request will be evaluated by expert review.  This mail initiates a
>three week comment period on the RRTYPE request.  If you have comments on
>the request, please post them to this list.
>
>Kind regards,
>
>Roy Arends
>
>
>---
>
>
>
>Template from http://tools.ietf.org/html/rfc5395
>
>
>
>DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
>
>
>A.    Submission Date:
>      30, June 2009
>
>B.    Submission Type:
>      [X] New RRTYPE
>      [ ] Modification to existing RRTYPE
>
>C.    Contact Information for submitter:
>      Name: Wouter Wijngaards
>      Email Address: wouter@nlnetlabs.nl
>      International telephone number: +31 20 888 4551
>      Other contact handles: -
>      (Note: This information will be publicly posted.)
>
>D.    Motivation for the new RRTYPE application?
>      Please keep this part at a high level to inform the Expert and
>      reviewers about uses of the RRTYPE.  Remember most reviewers
>      will be DNS experts that may have limited knowledge of your
>      application space.
>
>A double linked list of names that contain specific DNSKEY data at
>those names.  The type is to be used by applications that maintain trust
>anchors for DNS validators.  The DNSKEY data is used to rollover trust
>anchors to the current key.  Therefore they must know the start and end
>of the list, and be able to move forwards and backwards through the list.
>
>E.    Description of the proposed RR type.
>      This description can be provided in-line in the template, as an
>      attachment, or with a publicly available URL:
>
>The RR is a data type, can be handled as an RFC3597 unknown record.
>No additional section processing.
>
>The rdata is two domain names, presentation format is the two
>domain names, wireformat the two domain names in uncompressed form.
>
>The type is used to link domain names.
>TALINK _start_ _end_ for the list head and
>TALINK _prev_ _next_ for linking the elements.
>To end the list, the root label '.' is used to denote the endpoints.
>
>Thus, the root can be the list head, but not a list element.
>This is fine, saves space and is less complex than other solutions
>for flagging list endpoints or an empty list.
>
>F.    What existing RRTYPE or RRTYPEs come closest to filling that
>      need and why are they unsatisfactory?
>
>RP has two domain names but it means 'Responsible Person'.
>MINFO has two domain names but means 'Machine Information'.
>These types are compressed, which is nice.
>
>The PTR type is the right concept, but has only one domain
>name in its rdata, and I need two.  If I use two PTRs then
>the validator cannot distinguish the previous and next pointer,
>because the ordering of RRs in an RRset is not fixed.
>
>Another alternative is using PTR records at _start, _end, _prev and
>_next prefixes for disambiguation.  Prefixes limit the domains that
>can be used because of the max domain name length.  This is
>the alternative I would consider if this application is denied.
>
>G.    What mnemonic is requested for the new RRTYPE (optional)?
>      Note: This can be left blank and the mnemonic decided after the
>      template is accepted.
>
>TALINK (Trust Anchor LINK).
>
>H.    Does the requested RRTYPE make use of any existing IANA
>      Registry or require the creation of a new IANA sub-registry in
>      DNS Parameters?
>      If so, please indicate which registry is to be used or created.
>      If a new sub-registry is needed, specify the allocation policy
>      for it and its initial contents.  Also include what the
>      modification procedures will be.
>
>No.
>
>I.    Does the proposal require/expect any changes in DNS
>      servers/resolvers that prevent the new type from being
>      processed as an unknown RRTYPE (see [RFC3597])?
>
>no changes.
>
>J.    Comments:
>
>-
>
>
>--
>to unsubscribe send a message to namedroppers-request@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-963850075==_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 Wed Jul 22 09:30:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812EB3A6B80; Wed, 22 Jul 2009 09:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 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, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ab11lC2uVV2; Wed, 22 Jul 2009 09:30:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 724FC3A676A; Wed, 22 Jul 2009 09:30:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTebJ-000PM8-HC for namedroppers-data0@psg.com; Wed, 22 Jul 2009 16:23:29 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTebD-000PLS-Uh for namedroppers@ops.ietf.org; Wed, 22 Jul 2009 16:23:26 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 72ABB58008; Wed, 22 Jul 2009 18:23:22 +0200 (CEST) Received: from [192.168.254.8] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTP id 9B7DE57FE3; Wed, 22 Jul 2009 18:23:16 +0200 (CEST) Message-ID: <4A673CF4.8010807@nlnetlabs.nl> Date: Wed, 22 Jul 2009 18:23:16 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi Ed, This is about the (dnsop) draft more than the TALINK type, but I'll respond to your criticism here. On 07/22/2009 04:16 PM, Edward Lewis wrote: > I have an extreme distaste for this proposal. ok > RRSIG includes inception and expiration times to limit the window of > opportunity for replay attacks as well as the lack of a revocation > mechanism in DNSSEC. They shouldn't be ignored at all, when a spec says > "Ignore date changes in the RRSIG" there ought to be a security impact > analysis attached. Well the analysis is this * The data is not claimed to be 'current' despite the expiration. It is claimed to be historical. Therefore, current data still has to obey the inception and expiration dates. * The DNSKEY data is still a valid statement. It says that at that particular date, KSK1 signed KSK2 in the rollover process. That statement, once it has been made, is indeed a timeless fact. It happened, and the rollover has been done. * So to rephrase the previous point: history is a truth. Saying that something happened in the past is a correct statement. It is not a security problem. In fact given the public nature of the DNS this was publicly visible to everyone (in the past). * So the expiration date is not applicable for someone trying to follow what the rollover scheme has been. What is applicable is KSK1 signed KSK2, KSK2 signed KSK3, ... * As a sidenote, 5011 of MofN did not allow a rollover to be un-done. There is no undo for DNSSEC rollover. Hence repeating and observation MUST have been part of the correct rollover. > The draft does not address the security issue of PFS > (http://en.wikipedia.org/wiki/Perfect_forward_secrecy). I am concerned > that if (say) a 3-year old KSK is finally "broken", it can be used to > construct a new KSK chain to a false key. So what? You are citing short periods, for say SSL keys very long lifetimes are apparantly possible. If someone breaks a 3year old KSK, it could only be used on someone who is using that 3year old KSK. (Again, for SSL certificates, aparrantely 10-years is fine for 2048bit keys). So, it boils down to you having a dislike because the 'control' over how long a DNSKEY remains valid goes from the publisher to the validator ? It is that validator that according to the draft can opt to say that '3 years is too much, I will not do historical key rollover'. > Maintaining a history of keys re-balances of key management in DNSSEC. > If a KSK is effective for one year, it only has to meet the strength > requirements for a year. If it will be used "forever" to lead through a Well, the publisher cannot force it, but the validator user can configure locally that he thinks - say - that 1024 bit keys can only be trusted for 2 years at most. And he has his own clock and nobody can tell him otherwise. > chain of keys to the current key, the original KSK has to be stronger. > For example, NIST is recommending 80 bits of strength until 2011 or so > (in some cases) but 112 bits after that for some time. Keeping the KSK > around in a history means 80 bits is no good even now. And then there's > the issue of key disposal. Well no problem private keys can be deleted just fine. This just tracks history, what happened. Of course, if you are distributing trust anchors and your rollover is once per year and you use 80 bits, well then you cannot support end-users perhaps. If you think people with 3 year old keys should be able to use your service securely, you should choose keys that stay secure for 3 years? Am I missing something in your argument here? > > The NIST recommendations I refer to are highlighted here: > http://csrc.nist.gov/groups/ST/key_mgmt/documents/June09_Presentations/Elaine_Barker_Transitions_KMWS_June2009.pdf > (to the best of my understanding). > > If a KSK is in use for 2010 it can be managed for a one-year > effectivity. If there's history involved, we switch gears so that the > KSK has an eternal effectivity. Again, the choice for how long a KSK is effective is in the validators hands. This (could be) configured. The zone operator, yes, has to publish. Because, say, some end user may make a different analysis of the lifetime of that key than you do. And of his risks, say, some low risk organisation may think a key that is older is sufficient (since even if the key is very very old, the algorithm I give turns into a leap of faith). And a high risk organisation could put a maximum lifetime in that validator for the trust anchor (and really high risk organisations are always online right? so they do not need it and only need 5011). > Given my uneasiness with the reason for the record type, I am against > allocating a position in the registry. That reasoning makes sense. But I do not agree with the arguments you give against the reason for the record type. Best regards, Wouter > > At 14:46 +0200 7/22/09, roy@nominet.org.uk wrote: > >Dear colleagues, > > > >I have been assigned with the task of coordinating an expert-review of the > >DNS RRTYPE parameter allocation for TALINK, present in > >http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 . > > > >Attached is a completed template requesting an RRTYPE assignment under the > >procedures of draft-ietf-dnsext-2929bis. > > > >This request will be evaluated by expert review. This mail initiates a > >three week comment period on the RRTYPE request. If you have comments on > >the request, please post them to this list. > > > >Kind regards, > > > >Roy Arends > > > > > >--- > > > > > > > >Template from http://tools.ietf.org/html/rfc5395 > > > > > > > >DNS RRTYPE PARAMETER ALLOCATION TEMPLATE > > > > > >A. Submission Date: > > 30, June 2009 > > > >B. Submission Type: > > [X] New RRTYPE > > [ ] Modification to existing RRTYPE > > > >C. Contact Information for submitter: > > Name: Wouter Wijngaards > > Email Address: wouter@nlnetlabs.nl > > International telephone number: +31 20 888 4551 > > Other contact handles: - > > (Note: This information will be publicly posted.) > > > >D. Motivation for the new RRTYPE application? > > Please keep this part at a high level to inform the Expert and > > reviewers about uses of the RRTYPE. Remember most reviewers > > will be DNS experts that may have limited knowledge of your > > application space. > > > >A double linked list of names that contain specific DNSKEY data at > >those names. The type is to be used by applications that maintain trust > >anchors for DNS validators. The DNSKEY data is used to rollover trust > >anchors to the current key. Therefore they must know the start and end > >of the list, and be able to move forwards and backwards through the list. > > > >E. Description of the proposed RR type. > > This description can be provided in-line in the template, as an > > attachment, or with a publicly available URL: > > > >The RR is a data type, can be handled as an RFC3597 unknown record. > >No additional section processing. > > > >The rdata is two domain names, presentation format is the two > >domain names, wireformat the two domain names in uncompressed form. > > > >The type is used to link domain names. > >TALINK _start_ _end_ for the list head and > >TALINK _prev_ _next_ for linking the elements. > >To end the list, the root label '.' is used to denote the endpoints. > > > >Thus, the root can be the list head, but not a list element. > >This is fine, saves space and is less complex than other solutions > >for flagging list endpoints or an empty list. > > > >F. What existing RRTYPE or RRTYPEs come closest to filling that > > need and why are they unsatisfactory? > > > >RP has two domain names but it means 'Responsible Person'. > >MINFO has two domain names but means 'Machine Information'. > >These types are compressed, which is nice. > > > >The PTR type is the right concept, but has only one domain > >name in its rdata, and I need two. If I use two PTRs then > >the validator cannot distinguish the previous and next pointer, > >because the ordering of RRs in an RRset is not fixed. > > > >Another alternative is using PTR records at _start, _end, _prev and > >_next prefixes for disambiguation. Prefixes limit the domains that > >can be used because of the max domain name length. This is > >the alternative I would consider if this application is denied. > > > >G. What mnemonic is requested for the new RRTYPE (optional)? > > Note: This can be left blank and the mnemonic decided after the > > template is accepted. > > > >TALINK (Trust Anchor LINK). > > > >H. Does the requested RRTYPE make use of any existing IANA > > Registry or require the creation of a new IANA sub-registry in > > DNS Parameters? > > If so, please indicate which registry is to be used or created. > > If a new sub-registry is needed, specify the allocation policy > > for it and its initial contents. Also include what the > > modification procedures will be. > > > >No. > > > >I. Does the proposal require/expect any changes in DNS > > servers/resolvers that prevent the new type from being > > processed as an unknown RRTYPE (see [RFC3597])? > > > >no changes. > > > >J. Comments: > > > >- > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless surfaces is > that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From bedouintj840@stema-r.no Wed Jul 22 11:50:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1A93A69F3; Wed, 22 Jul 2009 11:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.634 X-Spam-Level: X-Spam-Status: No, score=-66.634 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_CHARTER=2.175, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eIlhz8-RkLt; Wed, 22 Jul 2009 11:50:46 -0700 (PDT) Received: from 71-90-0-226.dhcp.ftbg.wi.charter.com (71-90-0-226.dhcp.ftbg.wi.charter.com [71.90.0.226]) by core3.amsl.com (Postfix) with ESMTP id C22473A699A; Wed, 22 Jul 2009 11:50:45 -0700 (PDT) Received: from 71.90.0.226 by mx1.dataguard.no; Wed, 22 Jul 2009 13:48:45 -0600 Date: Wed, 22 Jul 2009 13:48:45 -0600 From: X-Mailer: The Bat! (v2.00.9) Educational Reply-To: bedouintj840@stema-r.no X-Priority: 3 (Normal) Message-ID: <369400880.11273678035778@stema-r.no> To: nea@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
 

July 21, 2009


Dear Reader:

Click right here to unblock the image


Kozee Ester

General Editor

From irregularlyo754@ipcounselor.com Wed Jul 22 13:40:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1323A6858; Wed, 22 Jul 2009 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.728 X-Spam-Level: X-Spam-Status: No, score=-43.728 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_MX=0.535, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K9i2hqnMiJe; Wed, 22 Jul 2009 13:40:02 -0700 (PDT) Received: from 200-53-245-42-cable.cybercable.net.mx (200-53-245-42-cable.cybercable.net.mx [200.53.245.42]) by core3.amsl.com (Postfix) with ESMTP id 876103A6800; Wed, 22 Jul 2009 13:40:02 -0700 (PDT) Received: from 200.53.245.42 by aspmx.l.google.com; Wed, 22 Jul 2009 15:37:53 -0600 Message-ID: <000d01ca0b0c$496e5100$6400a8c0@irregularlyo754> From: To: Subject: Lose Weight Fast with Acai Berry Date: Wed, 22 Jul 2009 15:37:53 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0B0C.496E5100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0B0C.496E5100 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hollywoods fat burning secret is out.   natural powers will rejuvinate your health and looks, no cost trial =20 best choice =20 best regards Bethany=20 Mercer =20 =20 ------=_NextPart_000_0007_01CA0B0C.496E5100 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Hol= lywoods fat burning secret is out.
&n= bsp;
natural powers will rejuvinate your health and looks= , no cost trial
<= A=20 href=3D"http://sre6167.aixjvaao.cn/">best choice
best regards Bethany=20 Mercer
------=_NextPart_000_0007_01CA0B0C.496E5100-- From owner-namedroppers@ops.ietf.org Wed Jul 22 16:40:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FF33A6C58; Wed, 22 Jul 2009 16:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RzglnuHlbua; Wed, 22 Jul 2009 16:40:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD1333A6C4F; Wed, 22 Jul 2009 16:40:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTlJv-000KVQ-Ho for namedroppers-data0@psg.com; Wed, 22 Jul 2009 23:33:59 +0000 Received: from [209.85.216.171] (helo=mail-px0-f171.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTlJs-000KV0-2v for namedroppers@ops.ietf.org; Wed, 22 Jul 2009 23:33:57 +0000 Received: by pxi1 with SMTP id 1so368963pxi.5 for ; Wed, 22 Jul 2009 16:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=SrtKuxiUMXhdL2bdEIERXLNxNEx5/Mes0/ukMpbuoIY=; b=SL3mRlReMm1XYM9iV3DqVUcDd5OcOskq2VxByiFIvhNuDfRSgQPw5asgyjm1aNUwOG OYSlIeokhRw5jVTqjgn7OImclTRE57bwGtqH7qT2Xy4ZIpqCVSaYrr/fwKujdHZ1xTkI Qw///IhVVInQ3jugVLvSS6yUB1K4lCDJEGUEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Zjq915uG9givQTozueNHCGlHMa1w45Fjbn+6OnPjhiPEaCC8VMn0C+N7qK4Q2Jr46K sxX3UG6NjbXvqP2gwwbZMyacKUiMo0u7XDnJaGO/Y0rvN7ZSVAYZ5upcGIBUdGonOHKi smTXrvyOzlqV8S6TtJs65wTIW4l3oa1MIDUmc= Received: by 10.114.180.20 with SMTP id c20mr1375373waf.160.1248305635025; Wed, 22 Jul 2009 16:33:55 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id n6sm2050925wag.4.2009.07.22.16.33.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 16:33:54 -0700 (PDT) Message-ID: <4A67A1DF.3080005@gmail.com> Date: Wed, 22 Jul 2009 19:33:51 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] WikiNameDroppers? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Noting the recent discussion about recharter, and the more recent Subject: "Notes on the DNS standard", perhaps IETF ops area could setup a Wiki, and the edit login could be exported from (restricted to) membership of this list. Each section of the many existing standards could be on a separate page, as having each document on a page would be too much. That way, edits could be compared to the base (that is, existing RFC), and each other. Once the knowledge has accumulated to a particular version, that could be published as another RFC. I'm pretty sure that MediaWiki even has a "flagged revisions" extension that would allow checkpoints in the discussion for each publication. Or, start a new set of pages.... We really don't *have* to continue using nrchbar (nroff change bar, for the uninitiated).... -- to unsubscribe send a message to namedroppers-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 Jul 22 17:19:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7633A6C86; Wed, 22 Jul 2009 17:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqhMZufrWzQs; Wed, 22 Jul 2009 17:19:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19BC23A6A45; Wed, 22 Jul 2009 17:19:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTlup-000Pe6-D1 for namedroppers-data0@psg.com; Thu, 23 Jul 2009 00:12:07 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTluk-000Pd3-Am for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 00:12:05 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 2182BE608C; Thu, 23 Jul 2009 00:12:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6N0BuC8014275; Thu, 23 Jul 2009 10:11:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907230011.n6N0BuC8014275@drugs.dv.isc.org> To: "W.C.A. Wijngaards" Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews References: <4A673CF4.8010807@nlnetlabs.nl> Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period In-reply-to: Your message of "Wed, 22 Jul 2009 18:23:16 +0200." <4A673CF4.8010807@nlnetlabs.nl> Date: Thu, 23 Jul 2009 10:11:56 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: People who have published keys today expect that validators that are turned on in three years time with old keys to FAIL to validate using them. This changes this expectation retroactively. I can remember having discussions like this years ago. Keeping the chain of trust forever was not a good idea then and it still isn't now. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 22 18:35:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4AD3A6AF2; Wed, 22 Jul 2009 18:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U80TozRmSlkS; Wed, 22 Jul 2009 18:35:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0841C3A6A0A; Wed, 22 Jul 2009 18:35:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTn90-000B1B-00 for namedroppers-data0@psg.com; Thu, 23 Jul 2009 01:30:50 +0000 Received: from [209.86.89.64] (helo=elasmtp-curtail.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTn8w-000AzX-54 for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 01:30:48 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=UeIDDZ9xk8i/5nwYIarzRJRnTvsIQZsZ3Bf11aZH5IeK9U6mzHLVatRx8kVJLuq6; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.215] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MTn8p-0003a5-Sa; Wed, 22 Jul 2009 21:30:40 -0400 Message-ID: <4A67D946.90169F71@ix.netcom.com> Date: Wed, 22 Jul 2009 20:30:14 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Andrews CC: "W.C.A. Wijngaards" , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period References: <4A673CF4.8010807@nlnetlabs.nl> <200907230011.n6N0BuC8014275@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068845cea83ff1fcd267b98a153f0b840089350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.215 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark and all, I recall as well. From my perspective and if memory serves me right, there really was no "Chain of Trust" and really isn't now. I also doubt that a "Chain of Trust" will be fully established or solidify at any point in time. Governments may be an exception. Mark Andrews wrote: > People who have published keys today expect that validators that > are turned on in three years time with old keys to FAIL to validate > using them. This changes this expectation retroactively. > > I can remember having discussions like this years ago. Keeping the > chain of trust forever was not a good idea then and it still isn't > now. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From spoliationo90@ipermedia.com.au Wed Jul 22 18:52:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299263A6B86; Wed, 22 Jul 2009 18:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.718 X-Spam-Level: X-Spam-Status: No, score=-17.718 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuyW6S8eTeyN; Wed, 22 Jul 2009 18:52:47 -0700 (PDT) Received: from 189-19-139-195.dsl.telesp.net.br (189-19-139-195.dsl.telesp.net.br [189.19.139.195]) by core3.amsl.com (Postfix) with ESMTP id 0C6D63A6CA7; Wed, 22 Jul 2009 18:52:46 -0700 (PDT) Received: from 189.19.139.195 by ipermedia.com.au; Wed, 22 Jul 2009 22:51:28 -0300 Message-ID: <000d01ca0b38$17f88ec0$6400a8c0@spoliationo90> From: To: Subject: Get Your Free Acai Berry Trial Now Date: Wed, 22 Jul 2009 22:51:28 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0B38.17F88EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0B38.17F88EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Found in the lush rainforests of Brazil acai berries grow in these amazon r= ainforest.   Studies show that the acai berry may fight cancer, increase energy, aid in = weight loss and more clck here =20 Site for everybody =20 best regards Matilde=20 Walters =20 =20 ------=_NextPart_000_0007_01CA0B38.17F88EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Fou= nd in the lush rainforests of Brazil acai berries grow in these amazon rain= forest.
&n= bsp;
Studies show that the acai berry may fight cancer, i= ncrease energy, aid in weight loss and more clck here
<= A=20 href=3D"http://drjikc0373.aixgtbxo.cn/">Site for everybody
best regards Matilde=20 Walters
------=_NextPart_000_0007_01CA0B38.17F88EC0-- From owner-namedroppers@ops.ietf.org Wed Jul 22 19:07:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E5E28C0FF; Wed, 22 Jul 2009 19:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbgEV2zOU7ZP; Wed, 22 Jul 2009 19:07:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC79A3A6A0E; Wed, 22 Jul 2009 19:07:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTnea-000FIt-CW for namedroppers-data0@psg.com; Thu, 23 Jul 2009 02:03:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTneU-000FHM-Jx for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 02:03:25 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 86636E601C; Thu, 23 Jul 2009 02:03:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6N23H9C016180; Thu, 23 Jul 2009 12:03:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907230203.n6N23H9C016180@drugs.dv.isc.org> To: "Jeffrey A. Williams" Cc: "W.C.A. Wijngaards" , Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews References: <4A673CF4.8010807@nlnetlabs.nl> <200907230011.n6N0BuC8014275@drugs.dv.isc.org> <4A67D946.90169F71@ix.netcom.com> Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period In-reply-to: Your message of "Wed, 22 Jul 2009 20:30:14 MST." <4A67D946.90169F71@ix.netcom.com> Date: Thu, 23 Jul 2009 12:03:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <4A67D946.90169F71@ix.netcom.com>, "Jeffrey A. Williams" writes: > Mark and all, > > I recall as well. From my perspective and if memory serves me > right, there really was no "Chain of Trust" and really isn't now. > I also doubt that a "Chain of Trust" will be fully established or > solidify at any point in time. Governments may be an exception. This proposal creates chains of trust through time. Once a key is rolled it should not be used for any further cryptographic operations. It should be treated as if the private part of the key has been exposed. The only cryptographic operation that should be done with a rolled key is to revoke itself. Mark > Mark Andrews wrote: > > > People who have published keys today expect that validators that > > are turned on in three years time with old keys to FAIL to validate > > using them. This changes this expectation retroactively. > > > > I can remember having discussions like this years ago. Keeping the > > chain of trust forever was not a good idea then and it still isn't > > now. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > Regards, > > Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > "YES WE CAN!" Barack ( Berry ) Obama > > "Credit should go with the performance of duty and not with what is > very often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > My Phone: 214-244-4827 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From rebellionsm6@iqnetworks.ca Wed Jul 22 19:15:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDA43A6C38; Wed, 22 Jul 2009 19:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.526 X-Spam-Level: X-Spam-Status: No, score=-16.526 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wufv+nSrEDE4; Wed, 22 Jul 2009 19:15:54 -0700 (PDT) Received: from 81-75.127-70.tampabay.res.rr.com (81-75.127-70.tampabay.res.rr.com [70.127.75.81]) by core3.amsl.com (Postfix) with ESMTP id EC28D3A6B86; Wed, 22 Jul 2009 19:15:53 -0700 (PDT) Received: from 70.127.75.81 by mail.iqnetworks.ca; Wed, 22 Jul 2009 22:15:54 -0500 Message-ID: <000d01ca0b3b$81c29730$6400a8c0@rebellionsm6> From: To: Subject: Oprah certified wieght loss solution Acai.Berri. Date: Wed, 22 Jul 2009 22:15:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0B3B.81C29730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0B3B.81C29730 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Fast and effective wieght loss solution Acai Flush.   Acai Berry has saved lives , let it help yours get your trial Now.=20 =20 Haste to visit =20 best regards Angeline=20 Driscoll =20 =20 ------=_NextPart_000_0007_01CA0B3B.81C29730 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Fas= t and effective wieght loss solution Acai Flush.
&n= bsp;
Acai Berry has saved lives , let it help yours get y= our trial Now.
<= A=20 href=3D"http://cxai1324.aixgtbxo.cn/">Haste to visit
best regards Angeline=20 Driscoll
------=_NextPart_000_0007_01CA0B3B.81C29730-- From lhasal15@sg.panasonic.com Wed Jul 22 22:40:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE11528B56A for ; Wed, 22 Jul 2009 22:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.697 X-Spam-Level: X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SPOOF_NET2COM=1.586, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MPGBOIJYW1D for ; Wed, 22 Jul 2009 22:40:16 -0700 (PDT) Received: from ip72-3-211-87.adsl2.static.versatel.nl (ip72-3-211-87.adsl2.static.versatel.nl [87.211.3.72]) by core3.amsl.com (Postfix) with ESMTP id 41C0628C0DE for ; Wed, 22 Jul 2009 22:40:09 -0700 (PDT) Message-ID: <000d01ca0b57$e2e43f70$6400a8c0@lhasal15> From: "dnsext-archive@ietf.org" To: Subject: Katie Griffin sent you a postcard from 1001 Postcards! Date: Thu, 23 Jul 2009 07:39:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0B57.E2E43F70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0B57.E2E43F70 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Oh happy day! Katie Griffin sent you a postcard from 1001 Postcards! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Pickup your card safely and securely: 1. Go directly to your card at this address: http://www.postcards.org/cards/cardreceive.php?id=3D84581103420694618034305= 895844063265325443531069934034&email=3Ddnsext-archive@ietf.org&from=3DKatie= Griffin 2. Please wait while postcard is loading. Your pickup code is: 30863-22164-7669-52 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Your postcard will be available for 60 days. We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! Regards, Marty & Alice at 1001 Postcards http://www.postcards.org ---------------------------------------------------------------------------= - ------=_NextPart_000_0007_01CA0B57.E2E43F70 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Oh happy day! Katie Griffin = sent you a postcard from 1001 Postcards!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pickup your card safely and securely:

1. Go directly to your card = at this address:
http://www.postcards.org/cards/cardreceive.= php?id=3D84581103420694618034305895844063265325443531069934034&email=3Ddnse= xt-archive@ietf.org&from=3DKatie Griffin

2. Please wait while postcard is loading.

Your pickup code is: 30863-= 22164-7669-52
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Your postcard will be availa= ble for 60 days.

We hope you enjoy your postc= ard, and if you do, please take a moment
to send a few yourself!

Regards,
Marty & Alice at 1001 Postcards
http://www.postcards.org

----------------------------= ------------------------------------------------

------=_NextPart_000_0007_01CA0B57.E2E43F70-- From owner-namedroppers@ops.ietf.org Wed Jul 22 23:12:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110A83A6823; Wed, 22 Jul 2009 23:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+9QV07H1ESj; Wed, 22 Jul 2009 23:12:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 268BC3A681A; Wed, 22 Jul 2009 23:12:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTrQo-000KwD-5Q for namedroppers-data0@psg.com; Thu, 23 Jul 2009 06:05:30 +0000 Received: from [74.125.78.25] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTrQj-000Kvf-Kq for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 06:05:27 +0000 Received: by ey-out-2122.google.com with SMTP id 22so220430eye.65 for ; Wed, 22 Jul 2009 23:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=RZLwwrlSfcpcCQ+ttM16q/qoNFG5tDf9yTfowXxgw4Q=; b=TDx2DamPnTr6K4E/TRYdwW2pHckw/USGSsxXFB/6H0BX0vw9wlkDLlCTwYOHJDHkAx 34QviD8zaDaThqBof+2le2nC1vYPhs/fQMycLFPGtbi18dKbNfPiCwOTtb4+BFA1ghdg EnGyulFk9zm5NY8NMYgXeSEDts1TqpusafhBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Ii5FdlU82nGbRMJoBwFrX7qhheaIojR8i/lg0kpmH5AE0/TQ8wXReXetCNq2LcAdx9 izXuRtPKuKAo5bjy6H1h1j8ZTYULqVvy6O2yWrBvFrlVmb0nF1HY65+Q+rezpqwfIlIm 6wy5cvgwqp5FJdhrpfg8k9/E+D0+XY63Ukl7A= MIME-Version: 1.0 Received: by 10.210.131.6 with SMTP id e6mr7711463ebd.29.1248329124098; Wed, 22 Jul 2009 23:05:24 -0700 (PDT) In-Reply-To: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> References: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> From: bert hubert Date: Thu, 23 Jul 2009 08:05:04 +0200 Message-ID: <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> Subject: Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: forgot to CC the list. ---------- Forwarded message ---------- From: bert hubert Date: Thu, Jul 23, 2009 at 8:04 AM Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment per= iod To: roy@nominet.org.uk On Wed, Jul 22, 2009 at 2:46 PM, wrote: > I have been assigned with the task of coordinating an expert-review of th= e > DNS RRTYPE parameter allocation for TALINK, present in > http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 . I have read this, and I think I understand what it says. Here goes. So we have a trust anchor, which is hardcoded in the configuration file. However, a rollover has occurred, and we didn't see it happen, so we could not update our trust anchor. (Just wondering, does this currently happen already in validating resolvers? I got the impression trust anchors were rather static.) Now the validator is back in business, possibly because it was only turned on for the first time after being installed on the PC in the factory from a 2 year old master, and it finds it can't validate anything based on the trust anchor it has, because it has since rolled over. However, it finds a chain described by TALINK records which say 'this key is my successor, and I've signed it using the anchor you know, please trust it'. And things are good. Is this description correct? If so, how can we be sure that the original anchor (which may have been rolled over because it was compromised), cant' be "resurrected" by a third party using an appropriate TALINK chain? In other words, doesn't TALINK negate the utility of doing KSK rollovers in the first place? Also, DNSSEC is already straining with complexity - I know for sure since I started implementing it for a prototype on www.powerdnssec.org. I wonder if we shouldn't simply tell people to do this kind of thing out of band. Say, using 'windows update'. On the TALINK record per se, if it turns out that having a 'rolled-over key' resurrection ability is a good idea, we surely need a "TALINK" rrtype. =A0 =A0 =A0 =A0 =A0 Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 22 23:38:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABDE3A6AA7; Wed, 22 Jul 2009 23:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eawsabz4AdSh; Wed, 22 Jul 2009 23:38:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 673AD3A6953; Wed, 22 Jul 2009 23:38:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTrsa-000Nng-Bv for namedroppers-data0@psg.com; Thu, 23 Jul 2009 06:34:12 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTrsW-000NnD-KT for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 06:34:10 +0000 Received: from [192.168.100.80] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 21231C2DA3; Thu, 23 Jul 2009 07:34:05 +0100 (BST) Date: Thu, 23 Jul 2009 07:34:03 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert , "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" cc: Alex Bligh Subject: Re: Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period Message-ID: In-Reply-To: <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> References: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 23 July 2009 08:05:04 +0200 bert hubert wrote: > However, a rollover has occurred, and we didn't see it happen, so we > could not update our trust anchor. ... > Now the validator is back in business, possibly because it was only > turned on for the first time after being installed on the PC in the > factory from a 2 year old master, and it finds it can't validate > anything based on the trust anchor it has, because it has since rolled > over. > > However, it finds a chain described by TALINK records which say 'this > key is my successor, and I've signed it using the anchor you know, > please trust it'. ... > Is this description correct? If so, how can we be sure that the > original anchor (which may have been rolled over because it was > compromised), cant' be "resurrected" by a third party using an > appropriate TALINK chain? > In other words, doesn't TALINK negate the utility of doing KSK > rollovers in the first place? ... > I wonder if we shouldn't simply tell people to do > this kind of thing out of band. Say, using 'windows update'. I agree. I think for similar reasons it fails where there are other reasons for the rollover (e.g. algorithmic weakness). I'm struggling to think of any scenario where you would go to the effort of rolling keys, but want the old ones to remain valid for future signings. Moreover, in Bert's use case at least, the two year old PC is going to need to have the /code/ for its DNSSEC validator updated, as in the two year period which elapsed since the factory master was made, the usual selection of horrible bugs and algorithmic weaknesses will be found. There needs to be a mechanism of doing this securely (probably not using DNSSEC), and whatever it is can also update the trust anchor. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 23 00:15:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAFF3A6894; Thu, 23 Jul 2009 00:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38N9Sjd2lR+w; Thu, 23 Jul 2009 00:15:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F16323A6870; Thu, 23 Jul 2009 00:15:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTsRG-00027F-Gu for namedroppers-data0@psg.com; Thu, 23 Jul 2009 07:10:02 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTsRB-00026X-DB for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 07:09:59 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6N79hR8009889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 09:09:46 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A680CB7.8020709@nlnetlabs.nl> Date: Thu, 23 Jul 2009 09:09:43 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period References: <4A673CF4.8010807@nlnetlabs.nl> <200907230011.n6N0BuC8014275@drugs.dv.isc.org> In-Reply-To: <200907230011.n6N0BuC8014275@drugs.dv.isc.org> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 23 Jul 2009 09:09:46 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, On 07/23/2009 02:11 AM, Mark Andrews wrote: > People who have published keys today expect that validators that > are turned on in three years time with old keys to FAIL to validate > using them. This changes this expectation retroactively. Well, if the zone owner wants to support it, then he can set his expectations. Otherwise, people can already do this? > I can remember having discussions like this years ago. Keeping the > chain of trust forever was not a good idea then and it still isn't > now. Can you tell me why it was considered not a good idea? It is of course not 'forever', but until the time that the validator thinks the key can be trusted for. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpoDLYACgkQkDLqNwOhpPjP2QCeMfFie8SGR3akE1Zg+gu3iy0q v+cAn2aB5P3USLHQR5Tbl3llT1RV7TW+ =nRIh -----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 Jul 23 01:31:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEE53A6903; Thu, 23 Jul 2009 01:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUHdiNwWiBST; Thu, 23 Jul 2009 01:31:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C22D3A68ED; Thu, 23 Jul 2009 01:31:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTtdO-000BLf-Vt for namedroppers-data0@psg.com; Thu, 23 Jul 2009 08:26:38 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTtdJ-000BJZ-Ub for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 08:26:36 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6N8QH7X039277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 10:26:18 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A681EA9.3070502@nlnetlabs.nl> Date: Thu, 23 Jul 2009 10:26:17 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Alex Bligh CC: bert hubert , "namedroppers@ops.ietf.org" Subject: Re: Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period References: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 23 Jul 2009 10:26:18 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alex, Bert, On 07/23/2009 08:34 AM, Alex Bligh wrote: > --On 23 July 2009 08:05:04 +0200 bert hubert wrote: >> Is this description correct? If so, how can we be sure that the Yes >> original anchor (which may have been rolled over because it was >> compromised), cant' be "resurrected" by a third party using an >> appropriate TALINK chain? >> In other words, doesn't TALINK negate the utility of doing KSK >> rollovers in the first place? That is a very good point. The best way to stop someone putting the rollover sequence in reverse is to look at the RRSIG dates. The middle (of inception, expiration), must then increase over time. Therefore the TALINK chain is going forwards. > ... >> I wonder if we shouldn't simply tell people to do >> this kind of thing out of band. Say, using 'windows update'. Well, because of the TALINK type the discussion seems to be in dnsext, but I really put this draft to dnsop, as an aid to validator configuration. Which is outside of the DNSSEC protocol. > I agree. I think for similar reasons it fails where there > are other reasons for the rollover (e.g. algorithmic Can you explain the failure with algorithmic weaknesses? > weakness). I'm struggling to think of any scenario where > you would go to the effort of rolling keys, but want the > old ones to remain valid for future signings. Because most people are online 'pretty often', if you roll once per year, then most people will use your latest trust anchor. With exceptions, for software out of boxes, ... > Moreover, in Bert's use case at least, the two year old > PC is going to need to have the /code/ for its DNSSEC > validator updated, as in the two year period which elapsed > since the factory master was made, the usual selection > of horrible bugs and algorithmic weaknesses will be found. > There needs to be a mechanism of doing this securely (probably > not using DNSSEC), and whatever it is can also update the > trust anchor. So, is it allowed to have an alternative to this 'windows update' ? Not everything has 'windows update'. Vendor dependence. ServicePackN may not work. Not all software can be updated (devices, livecd). You assume the update is secure. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpoHqkACgkQkDLqNwOhpPht/ACfaLJpLbaalHs3k5yD58RqfF5t te4AnjUmdVMMYJgluh5oBuOfKy1Q/bwZ =/FOl -----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 Jul 23 02:26:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41A73A68BE; Thu, 23 Jul 2009 02:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRE+zxyYiVUk; Thu, 23 Jul 2009 02:26:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD01C3A685F; Thu, 23 Jul 2009 02:26:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTuVF-000HUy-TL for namedroppers-data0@psg.com; Thu, 23 Jul 2009 09:22:17 +0000 Received: from [209.85.219.213] (helo=mail-ew0-f213.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTuVC-000HUR-GP for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 09:22:16 +0000 Received: by ewy9 with SMTP id 9so814894ewy.41 for ; Thu, 23 Jul 2009 02:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Tps6aEniIDB0XqEPETc/JNTQyvfQxeEylLyqwR7ThyQ=; b=b5OuPHS71NcaZiaRPdMKvjolQ36RBYvsfJkmUfJUbSYZMRvVjv047G4BaISYRPTiRZ r+xsOo3HPCRsmpbN9c9O9cKhp3YFzNEssU2Owzr3nFnQCJEGvxm0vA03Rii6i6l0b6hH 91ThgzAzTDhFdrI3FFC2f3nZIXDiIqsH7XXFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=EBcknsxKhdVP8lzbWsA8JUzV6ij6dwRGfTGmLPDlWWKhByoAcIfh/O5dSXHvt2OfWR kYc9rAh4aeGco+rAR495FM3k1EGY0aAeeS8hRiFURPy7xHZo8o/UF7d1xBS36tv3fsVe IsAlh9QpYLCA6KFt/auNbYz7ug2Rjg3vmM9Yo= MIME-Version: 1.0 Received: by 10.216.11.207 with SMTP id 57mr538142wex.154.1248340933109; Thu, 23 Jul 2009 02:22:13 -0700 (PDT) In-Reply-To: <4A681EA9.3070502@nlnetlabs.nl> References: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> <4A681EA9.3070502@nlnetlabs.nl> From: bert hubert Date: Thu, 23 Jul 2009 11:21:53 +0200 Message-ID: <3efd34cc0907230221r31bcc8f0l660440317ea29885@mail.gmail.com> Subject: Re: Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period To: "W.C.A. Wijngaards" Cc: Alex Bligh , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 23, 2009 at 10:26 AM, W.C.A. Wijngaards wrote: > Not everything has 'windows update'. Vendor dependence. > ServicePackN may not work. Not all software can be updated > (devices, livecd). You assume the update is secure. We have to assume the update is secure, because such updates will also typically install new revisions of the software. If we can't trust the authenticity of the software update, who cares about the keying material? I know of no major OS that does not implement signed updates. And of course we can solve this problem in DNSSEC too - but I'm reminded of Scotty in Star Trek "Captain, I cannot give her any more or she'll blow!". Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From ribbona32@irsme.com Thu Jul 23 06:34:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643393A6A11; Thu, 23 Jul 2009 06:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.161 X-Spam-Level: X-Spam-Status: No, score=-44.161 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_ALC=1.405, SARE_SUB_IMPROVE=0.641, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Dgwx4nC4hc; Thu, 23 Jul 2009 06:34:28 -0700 (PDT) Received: from host86-170-31-143.range86-170.btcentralplus.com (host86-170-31-143.range86-170.btcentralplus.com [86.170.31.143]) by core3.amsl.com (Postfix) with ESMTP id 82F773A672F; Thu, 23 Jul 2009 06:34:20 -0700 (PDT) Received: from 86.170.31.143 by irsme.com; Thu, 23 Jul 2009 15:31:53 +0100 Message-ID: <000d01ca0b99$f12d2550$6400a8c0@ribbona32> From: To: Subject: Improve your health with Acain Berry. Date: Thu, 23 Jul 2009 15:31:53 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0B99.F12D2550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0B99.F12D2550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get your Free trial today!   Stay healthy with acaiberry =20 Welcoming you =20 best regards Raynard=20 Guidry =20 =20 ------=_NextPart_000_0007_01CA0B99.F12D2550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Get= your Free trial today!
&n= bsp;
Stay healthy with acaiberry
<= A=20 href=3D"http://zwiky2119.aiptyato.cn/">Welcoming you
best regards Raynard=20 Guidry
------=_NextPart_000_0007_01CA0B99.F12D2550-- From yaquiot3@rothrist.com Thu Jul 23 06:59:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D833A6A86; Thu, 23 Jul 2009 06:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.4 X-Spam-Level: X-Spam-Status: No, score=-43.4 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgz0Ajogqrqt; Thu, 23 Jul 2009 06:59:38 -0700 (PDT) Received: from HSI-KBW-091-089-031-251.hsi2.kabelbw.de (HSI-KBW-091-089-031-251.hsi2.kabelbw.de [91.89.31.251]) by core3.amsl.com (Postfix) with ESMTP id B894928C124; Thu, 23 Jul 2009 06:59:36 -0700 (PDT) Received: from 91.89.31.251 by hol-smtp01.benteler.de; Thu, 23 Jul 2009 15:57:50 +0100 Date: Thu, 23 Jul 2009 15:57:50 +0100 From: X-Mailer: The Bat! (v2.00) Business Reply-To: yaquiot3@rothrist.com X-Priority: 3 (Normal) Message-ID: <627132552.56325923865372@rothrist.com> To: agentx-request@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear agentx-request@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Rigoberto Mims

Subscribe | Privacy Statement | Unsu bscribe
© 2009 iPharmacy Ltd, All rights reserved.
From carinajy9@ros.com Thu Jul 23 09:37:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A513A67A4; Thu, 23 Jul 2009 09:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.633 X-Spam-Level: X-Spam-Status: No, score=-59.633 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_PHARMACY=1, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_OBFU_SPLIT_HR2=0.183, SARE_UNI=0.591, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIZR+mDu2B76; Thu, 23 Jul 2009 09:37:53 -0700 (PDT) Received: from 201.22.136.170.dynamic.adsl.gvt.net.br (201.22.136.170.dynamic.adsl.gvt.net.br [201.22.136.170]) by core3.amsl.com (Postfix) with ESMTP id 821B23A6856; Thu, 23 Jul 2009 09:37:52 -0700 (PDT) Received: from 201.22.136.170 by mail.global.sprint.com; Thu, 23 Jul 2009 13:36:54 -0300 Date: Thu, 23 Jul 2009 13:36:54 -0300 From: X-Mailer: The Bat! (v3.81.14 Beta) Educational Reply-To: carinajy9@ros.com X-Priority: 3 (Normal) Message-ID: <875638665.46652079692110@ros.com> To: agentx-request@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear agentx-request@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Lowell Wise

Subscribe | Privacy Statement | Unsubscribe
© 2009 iPharmacy Ltd, All rights reserved.
From blurt13@rockandrepublic.com Thu Jul 23 18:50:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237F63A6C7B; Thu, 23 Jul 2009 18:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.743 X-Spam-Level: X-Spam-Status: No, score=-15.743 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FORGED_MUA_OUTLOOK=3.116, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, 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, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_CAC8F=0.417] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxljY6-E-BxB; Thu, 23 Jul 2009 18:50:07 -0700 (PDT) Received: from green.ch (zux221-168-189.adsl.green.ch [81.221.168.189]) by core3.amsl.com (Postfix) with ESMTP id A32323A6C35; Thu, 23 Jul 2009 18:50:06 -0700 (PDT) Received: from [70.140.225.90] (account blurt13@rockandrepublic.com HELO rwunrdzkpuzzpfk.shejwephomvles.ru) by green.ch (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 304385907 for dnsext-archive@lists.ietf.org; Fri, 24 Jul 2009 02:50:07 +0100 Message-ID: <5031054707.ENIFQE84943157@ewxophyoie.sakhcimkfuah.va> From: dnsext-archive@lists.ietf.org To: Subject: Lovyeou Date: Fri, 24 Jul 2009 02:50:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 http://evenguide.com From insolublesuje9@irantec.com Fri Jul 24 07:34:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0761F3A6778; Fri, 24 Jul 2009 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.306 X-Spam-Level: X-Spam-Status: No, score=-24.306 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG2Wkfv+rAHc; Fri, 24 Jul 2009 07:34:40 -0700 (PDT) Received: from 201.86.109.176.dynamic.adsl.gvt.net.br (201.86.109.176.dynamic.adsl.gvt.net.br [201.86.109.176]) by core3.amsl.com (Postfix) with ESMTP id F25943A6A7B; Fri, 24 Jul 2009 07:34:39 -0700 (PDT) Received: from 201.86.109.176 by irantec.com; Fri, 24 Jul 2009 11:32:57 -0300 Message-ID: <000d01ca0c6b$a31cd450$6400a8c0@insolublesuje9> From: To: Subject: America's # 1 Diet , Try Acai Berry. Date: Fri, 24 Jul 2009 11:32:57 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0C6B.A31CD450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0C6B.A31CD450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lose weight without stuggling.   Natural WeightL0SS Solution=20 =20 Quickly click =20 best regards Maria=20 Castle =20 =20 ------=_NextPart_000_0007_01CA0C6B.A31CD450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Los= e weight without stuggling.
&n= bsp;
Natural WeightL0SS Solution
<= A=20 href=3D"http://tri271.aipvyoao.cn/">Quickly click
best regards Maria=20 Castle
------=_NextPart_000_0007_01CA0C6B.A31CD450-- From owner-namedroppers@ops.ietf.org Fri Jul 24 09:04:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52ACA3A6B74; Fri, 24 Jul 2009 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNuSyVJRJ7Mn; Fri, 24 Jul 2009 09:04:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75EDC3A69CB; Fri, 24 Jul 2009 09:04:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUN8d-000Hck-LV for namedroppers-data0@psg.com; Fri, 24 Jul 2009 15:56:51 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUN8Z-000HcF-Nc for namedroppers@ops.ietf.org; Fri, 24 Jul 2009 15:56:49 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6OFuidY034238; Fri, 24 Jul 2009 11:56:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200907241556.n6OFuidY034238@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Jul 2009 11:56:43 -0400 To: bert hubert , From: Olafur Gudmundsson Subject: Re: Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period In-Reply-To: <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.co m> References: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 03:58 23/07/2009, bert hubert wrote: >Also, DNSSEC is already straining with complexity - I know for sure >since I started implementing it for a prototype on >www.powerdnssec.org. I wonder if we shouldn't simply tell people to do >this kind of thing out of band. Say, using 'windows update'. There are two cases to consider here. One the root key I'm quite sure we can figure out a way to get that key into OS-update distributions. For keys lower in the tree inside tld's that are not signed I'm not sure any OS vendor wants to put these keys into their updates. For them TAR's and Trust history are the only viable options to tell validator about the changed keys. (of course not rolling keys will also help). Olafur PS: do not forget about the Wireless router/withDNSSEC that you found in your closet and you need to power up because the one you have been using for the last 3 years died. -- to unsubscribe send a message to namedroppers-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 Jul 24 09:50:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EE73A6881; Fri, 24 Jul 2009 09:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB0z5qkoP-kn; Fri, 24 Jul 2009 09:50:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03E3A3A680C; Fri, 24 Jul 2009 09:50:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUNsz-000PDR-NZ for namedroppers-data0@psg.com; Fri, 24 Jul 2009 16:44:45 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUNsw-000PCp-If for namedroppers@ops.ietf.org; Fri, 24 Jul 2009 16:44:44 +0000 Received: from [10.140.182.102] (unknown [24.114.232.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 53F742FE8ED5; Fri, 24 Jul 2009 16:44:40 +0000 (UTC) From: Andrew Sullivan To: Olafur Gudmundsson In-Reply-To: <200907241556.n6OFuidY034238@stora.ogud.com> X-Mailer: iPhone Mail (7A341) Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period References: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com> <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com> <200907241556.n6OFuidY034238@stora.ogud.com> Message-Id: <1DC4239F-0818-4512-AA2C-C86527F75BF0@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A341) Date: Fri, 24 Jul 2009 12:44:23 -0400 Cc: bert hubert , "" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Without wishing to discourage the substantive comments being made about TALINK, I thought it might be a good idea to remind ourselves that the RRTYPE request is being handled according to our expert review procedures. It's important therefore if you have objections to note the cases where they are especially relevant to the expert review rules, as opposed to more general objections to the technique. Many messages have already made the distinction, but I just want to be certain everyone understands ways different kinds of feedback affect the expert's evaluation. Andrew (as panel of experts chair) Andrew Sullivan ajs@shinkuro.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 deadboltt41@savagedesign.com Fri Jul 24 10:24:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3041D3A6881 for ; Fri, 24 Jul 2009 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.683 X-Spam-Level: X-Spam-Status: No, score=-37.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_NJABL_PROXY=1.643, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcqTX6w51FGH for ; Fri, 24 Jul 2009 10:24:23 -0700 (PDT) Received: from 216.49.251-IP-227.ckt.net (216.49.251-IP-227.ckt.net [216.49.251.227]) by core3.amsl.com (Postfix) with ESMTP id BCDD528C1CB for ; Fri, 24 Jul 2009 10:24:17 -0700 (PDT) Received: from 216.49.251.227 by aspmx3.googlemail.com; Fri, 24 Jul 2009 12:23:58 -0600 From: "dnsext-archive@ietf.org" To: Subject: Jeffry Langford sent you a postcard from 1001 Postcards! Date: Fri, 24 Jul 2009 12:23:58 -0600 Message-ID: <000d01ca0c83$87469780$6400a8c0@deadboltt41> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA0C83.87469780" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA0C83.87469780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Oh happy day! Jeffry Langford sent you a postcard from 1001 Postcards! ============================================================================ Pickup your card safely and securely: 1. Go directly to your card at this address: http://www.postcards.org/cards/cardreceive.php?id=4927607891923133912398789302516138612525791555141061442638245164509580010541&email=dnsext-archive@ietf.org&from=Jeffry Langford 2. Please wait while postcard is loading. Your pickup code is: 8186-26634-25583-2735 ============================================================================ Your postcard will be available for 60 days. We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! Regards, Marty & Alice at 1001 Postcards http://www.postcards.org ---------------------------------------------------------------------------- ------=_NextPart_000_0006_01CA0C83.87469780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Oh happy day! Jeffry Langfor= d sent you a postcard from 1001 Postcards!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pickup your card safely and securely:

1. Go directly to your card = at this address:
http://www.postcard= s.org/cards/cardreceive.php?id=3D492760789192313391239878930251613861252579= 1555141061442638245164509580010541&email=3Ddnsext-archive@ietf.org&from=3DJ= effry Langford

2. Please wait while postcard is loading.

Your pickup code is: 8186-2= 6634-25583-2735
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Your postcard will be availa= ble for 60 days.

We hope you enjoy your postc= ard, and if you do, please take a moment
to send a few yourself!

Regards,
Marty & Alice at 1001 Postcards
http://www.postcards.org

----------------------------= ------------------------------------------------

------=_NextPart_000_0006_01CA0C83.87469780-- From scarifiedsb98@istek-kilims.com Fri Jul 24 14:59:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398A53A68D9; Fri, 24 Jul 2009 14:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.423 X-Spam-Level: X-Spam-Status: No, score=-16.423 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DSL=1.129, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4IRYbxtHeQe; Fri, 24 Jul 2009 14:59:18 -0700 (PDT) Received: from 201.170.214.27.dsl.dyn.telnor.net (201.170.214.27.dsl.dyn.telnor.net [201.170.214.27]) by core3.amsl.com (Postfix) with ESMTP id C770C3A68B4; Fri, 24 Jul 2009 14:59:02 -0700 (PDT) Received: from 201.170.214.27 by mxlb.ispgateway.de; Fri, 24 Jul 2009 14:58:56 -0800 Message-ID: <000d01ca0ca9$f0fd5120$6400a8c0@scarifiedsb98> From: To: Subject: Acai Slim, you will love your new life. Date: Fri, 24 Jul 2009 14:58:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0CA9.F0FD5120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0CA9.F0FD5120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lose 5 pds a week without the stress of diet or exercise.   Fast and effective , Try Acai Berry. =20 Please visit =20 best regards Declan=20 Myers =20 =20 ------=_NextPart_000_0007_01CA0CA9.F0FD5120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Los= e 5 pds a week without the stress of diet or exercise.
&n= bsp;
Fast and effective , Try Acai Berry.
<= A=20 href=3D"http://jqurm340.aiqjqfpo.cn/">Please visit
best regards Declan=20 Myers
------=_NextPart_000_0007_01CA0CA9.F0FD5120-- From pesteringk4@ipo-sa.com Fri Jul 24 23:07:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8532628C16F; Fri, 24 Jul 2009 23:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.891 X-Spam-Level: X-Spam-Status: No, score=-33.891 tagged_above=-999 required=5 tests=[BAYES_80=2, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, UNPARSEABLE_RELAY=0.001, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMqlQU4YF+V2; Fri, 24 Jul 2009 23:07:28 -0700 (PDT) Received: from dslc-082-082-074-141.pools.arcor-ip.net (dslc-082-082-074-141.pools.arcor-ip.net [82.82.74.141]) by core3.amsl.com (Postfix) with ESMTP id 3134E28C11D; Fri, 24 Jul 2009 23:07:27 -0700 (PDT) Received: from 82.82.74.141 by mailhost.ipo-sa.com Date: Sat, 25 Jul 2009 08:07:07 +0100 Message-Id: <88F74L6825187.40RZ81O6V8705@82.82.74.141.ipo-sa.com> From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Join the millions who use Acai Berry Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Get Healthy and stay healthy its easy WIth Acai Berry.
 
It's never been easier , Lose weight with acai berry formula.
The simple solution to weight loss, Acai Berry .


best regards Jenna Nixon
From rosaliecvk5@sportservicezaanstad.nl Sat Jul 25 00:44:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EDF28C0F9 for ; Sat, 25 Jul 2009 00:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.052 X-Spam-Level: X-Spam-Status: No, score=-45.052 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dot0cUhSUO7K for ; Sat, 25 Jul 2009 00:44:05 -0700 (PDT) Received: from pool-72-84-156-78.slsbmd.east.verizon.net (pool-72-84-156-78.slsbmd.east.verizon.net [72.84.156.78]) by core3.amsl.com (Postfix) with ESMTP id 183F128C0F3 for ; Sat, 25 Jul 2009 00:44:03 -0700 (PDT) Message-ID: <000d01ca0cfb$9eb09e20$6400a8c0@rosaliecvk5> From: "dnsext-archive@lists.ietf.org" To: Subject: Blair Moreno sent you a postcard from 1001 Postcards! Date: Sat, 25 Jul 2009 03:43:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0CFB.9EB09E20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0CFB.9EB09E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oh happy day! Blair Moreno sent you a postcard from 1001 Postcards! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Pickup your card safely and securely: 1. Go directly to your card at this address: http://www.postcards.org/cards/cardreceive.php?id=3D46051354057038717068292= 95693438536409915445912235087919042259273541809586693&email=3Ddnsext-archiv= e@lists.ietf.org&from=3DBlair Moreno 2. Please wait while postcard is loading. Your pickup code is: 24869-200-6600-27258 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Your postcard will be available for 60 days. We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! Regards, Marty & Alice at 1001 Postcards http://www.postcards.org ---------------------------------------------------------------------------= - ------=_NextPart_000_0007_01CA0CFB.9EB09E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Oh happy day! Blair Moreno s= ent you a postcard from 1001 Postcards!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pickup your card safely and securely:

1. Go directly to your card = at this address:
http://www.postc= ards.org/cards/cardreceive.php?id=3D460513540570387170682929569343853640991= 5445912235087919042259273541809586693&email=3Ddnsext-archive@lists.ietf.org= &from=3DBlair Moreno

2. Please wait while postcard is loading.

Your pickup code is: 24869-= 200-6600-27258
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Your postcard will be availa= ble for 60 days.

We hope you enjoy your postc= ard, and if you do, please take a moment
to send a few yourself!

Regards,
Marty & Alice at 1001 Postcards
http://www.postcards.org

----------------------------= ------------------------------------------------

------=_NextPart_000_0007_01CA0CFB.9EB09E20-- From messy6@recruitmentstore.com Sat Jul 25 10:35:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8C93A67DA; Sat, 25 Jul 2009 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.141 X-Spam-Level: ** X-Spam-Status: No, score=2.141 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOGH-gxxFupj; Sat, 25 Jul 2009 10:35:20 -0700 (PDT) Received: from cable-89-216-243-183.dynamic.sbb.rs (cable-89-216-243-183.dynamic.sbb.rs [89.216.243.183]) by core3.amsl.com (Postfix) with ESMTP id 2E32D3A6359; Sat, 25 Jul 2009 10:35:20 -0700 (PDT) Received: from 89.216.243.183 by office.recruitmentstore.com; Sat, 25 Jul 2009 19:33:12 +0100 Date: Sat, 25 Jul 2009 19:33:12 +0100 From: X-Mailer: The Bat! (v2.11) Educational Reply-To: messy6@recruitmentstore.com X-Priority: 3 (Normal) Message-ID: <727327863.59655580465631@recruitmentstore.com> To: dccp-owner@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear dccp-owner@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Jame Crenshaw

Subscribe | Privacy Statement | Un subscribe
© 2009 iPharmacy Ltd, All rights reserved.
From owner-namedroppers@ops.ietf.org Sat Jul 25 11:59:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BF43A68B3; Sat, 25 Jul 2009 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT9v7J9jMV0p; Sat, 25 Jul 2009 11:59:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C16153A6A4B; Sat, 25 Jul 2009 11:58:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUmJD-0009Up-MG for namedroppers-data0@psg.com; Sat, 25 Jul 2009 18:49:27 +0000 Received: from [2001:4f8:0:1::23:2] (helo=afribone.trstech.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUmJ7-0009U9-BX for namedroppers@ops.ietf.org; Sat, 25 Jul 2009 18:49:24 +0000 Received: from [207.98.72.113] (helo=[10.111.176.119]) by afribone.trstech.net with esmtpa (Exim 4.69) (envelope-from ) id 1MUmFZ-0006RO-Gb; Sat, 25 Jul 2009 18:45:45 +0000 Cc: "namedroppers@ops.ietf.org" Message-Id: From: ALAIN AINA To: "Rose, Scott W." In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-109--342420791 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 25 Jul 2009 18:48:38 +0000 References: X-Mailer: Apple Mail (2.935.3) X-SA-Exim-Connect-IP: 207.98.72.113 X-SA-Exim-Mail-From: aalain@afribone.trstech.net Subject: Re: [dnsext] -03 version of algo-signal posted X-SA-Exim-Version: 4.2.1 (built Tue, 15 Jul 2008 18:57:52 +0000) X-SA-Exim-Scanned: Yes (on afribone.trstech.net) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-109--342420791 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 7, 2009, at 2:42 PM, Rose, Scott W. wrote: > "Official" -03 version of algo-signal posted: > http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.txt > > This is different that the working version Steve sent to the list > recently. > It goes back to the original (-00) version in that the algorithms > are a list > in the OPT RR, not a single value with assumptions. > > Please refer to this version for future discussions. > Scott some comments of the document: The draft does not discuss these points: 1- The DNSKEY RRset selection in response to match the AU of the clients: - a zone has: A dnskey with alg 1 and another dnskey with alg2 The signed zone will have RRSIGs on the keyset with alg1 and alg2 If the client says that it only understands alg1, should the key with alg2 be removed to the keyset when returning the answer to the client ? if not what should be the behavior the client regarding the key with alg2 (unknown) ?? [keyset] example. DNSKEY 256 3 3 ....... example. DNSKEY 256 3 5 ...... example. DNSKEY 257 3 5 ........... [RRSIG on the keyset ] example. RRSIG DNSKEY 3 1 .... example. RRSIG DNSKEY 5 1 .... example. RRSIG DNSKEY 5 1...... ......... 2- DS selection to match the AU of the client. as above should the parent NS remove the DS RR with unknown alg when answering query with a certain understood alg ? if not what should the behavior of the client with a DS RR with unknown alg? To be able to alter dnskey and DS RR, there is a need to have separate RRSIGs of keyset and DSset per alg. Not obvious. All of these get simplified if we change the wordings "understood algorithms" to "preferred algorithms", which mean that the client understand at least all mandatory algorithms but prefer one or more. But in the case part of the objectives of the draft can't be achieved. Other issues: 3- The server considerations says : "If the zone containing the QNAME is signed with a cryptographic algorithm(s) that are not present in the ALG-CODE value in the client query the authoritative server SHOULD include any or all RRSIGs in the response regardless of algorithm used to generate them." Shouldn't server respond in such situation with a RCODE 21 (BADALG) and set the available alg(s) in AU ? 4- And for compatibility with client which won't implement the AU and so won't sent the OPT RR, i see servers acting as describe above. --alain --Apple-Mail-109--342420791 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 7, 2009, = at 2:42 PM, Rose, Scott W. wrote:

"Official" -03 version of algo-signal posted:
http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-s= ignal-03.txt

This is different that the working version Steve = sent to the list recently.
It goes back to the original (-00) version = in that the algorithms are a list
in the OPT RR, not a single value = with assumptions.

Please refer to this version for future = discussions.
Scott


=
some comments of the = document:



The = draft does not discuss these points:

1- =  The DNSKEY RRset selection in  response to match the AU of = the clients:

- a zone = has:

  A dnskey with alg 1 and = another dnskey with alg2
  The signed zone will have = RRSIGs on the keyset with alg1 and alg2

If the = client says that it only understands alg1, should the key with alg2 be = removed to the keyset when returning the answer to the client ? if not = what should be the behavior the client regarding the  key with alg2 = (unknown) = ??

[keyset]

example. = DNSKEY = DNSKEY RRSIG DNSKEY 3 1 =  ....
example. RRSIG DNSKEY 5 1 = ....
example.        RRSIG   DNSKEY 5 = 1......
.........


2- =  DS  selection to match the AU of the = client.

as above should the parent NS remove = the DS RR  with unknown alg when answering query with a certain = understood alg ? if not what should the behavior of the client with a DS = RR with unknown alg?


To be able = to alter dnskey and DS RR, there is a need to  have separate RRSIGs = of keyset and DSset per alg. Not = obvious. 


All of these get = simplified if we change the wordings "understood algorithms" to = "preferred algorithms", which mean that the client understand at least = all mandatory algorithms but prefer one or more. But in the case part of = the objectives of the draft can't be = achieved.



Other = issues:

3-  The server considerations says = :

"If the zone containing the QNAME is signed with a cryptographic = algorithm(s) that are not present in the ALG-CODE value in the client = query

the authoritative server = SHOULD include any or all RRSIGs in the response regardless of algorithm = used to generate them."



 S= houldn't server respond in such situation with a  RCODE 21 (BADALG) = and set  the available alg(s) in  AU = ? 


4- And for compatibility = with client which won't implement the AU and so won't sent the  OPT = RR,  i see  servers  acting as describe =  above.



--alai= n

= --Apple-Mail-109--342420791-- -- to unsubscribe send a message to namedroppers-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 Jul 25 12:59:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB593A69FA; Sat, 25 Jul 2009 12:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i6RtfB8Np+s; Sat, 25 Jul 2009 12:59:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E3D83A69F7; Sat, 25 Jul 2009 12:59:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUnIa-000Ges-4C for namedroppers-data0@psg.com; Sat, 25 Jul 2009 19:52:52 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUnIW-000GeU-Pd for namedroppers@ops.ietf.org; Sat, 25 Jul 2009 19:52:50 +0000 Received: from crankycanuck.ca (unknown [74.198.148.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6D1962FE8ED5 for ; Sat, 25 Jul 2009 19:52:45 +0000 (UTC) Date: Sat, 25 Jul 2009 15:52:41 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Meeting agenda updated; please send materials Message-ID: <20090725195240.GB681@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, I have just updated the meeting agenda to include a request to speak about draft-li-dnsext-ipv4-ipv6-01. We will have to deal with that draft as time permits; please read it before the meeting. If you are expecting to speak in the meeting and have supporting materials, please send them to me as soon as possible. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From eccentricallyw561@skisrossignol.fr Sat Jul 25 23:24:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13FF3A67D1 for ; Sat, 25 Jul 2009 23:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.158 X-Spam-Level: X-Spam-Status: No, score=-56.158 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q72qQ1ZDttSs for ; Sat, 25 Jul 2009 23:24:57 -0700 (PDT) Received: from cpe-71-72-232-243.cinci.res.rr.com (cpe-71-72-232-243.cinci.res.rr.com [71.72.232.243]) by core3.amsl.com (Postfix) with ESMTP id 9AA9D3A680D for ; Sat, 25 Jul 2009 23:24:57 -0700 (PDT) Received: from 71.72.232.243 by smtp1.skisrossignol.fr; Sun, 26 Jul 2009 02:24:44 -0500 Message-ID: <000d01ca0db9$c40d7e90$6400a8c0@eccentricallyw561> From: "dnsext-archive@lists.ietf.org" To: Subject: Shannon Reeder sent you a postcard from 1001 Postcards! Date: Sun, 26 Jul 2009 02:24:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0DB9.C40D7E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0DB9.C40D7E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oh happy day! Shannon Reeder sent you a postcard from 1001 Postcards! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Pickup your card safely and securely: 1. Go directly to your card at this address: http://www.postcards.org/cards/cardreceive.php?id=3D43941435752746466076752= 6255645911084118654747312697195491257&email=3Ddnsext-archive@lists.ietf.org= &from=3DShannon Reeder 2. Please wait while postcard is loading. Your pickup code is: 7058-15004-32520-22618 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Your postcard will be available for 60 days. We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! Regards, Marty & Alice at 1001 Postcards http://www.postcards.org ---------------------------------------------------------------------------= - ------=_NextPart_000_0007_01CA0DB9.C40D7E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Oh happy day! Shannon Reeder= sent you a postcard from 1001 Postcards!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pickup your card safely and securely:

1. Go directly to your card = at this address:
http://www.postcards.org/card= s/cardreceive.php?id=3D4394143575274646607675262556459110841186547473126971= 95491257&email=3Ddnsext-archive@lists.ietf.org&from=3DShannon Reeder
2. Please wait while postcard is loading.

Your pickup code is: 7058-1= 5004-32520-22618
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Your postcard will be availa= ble for 60 days.

We hope you enjoy your postc= ard, and if you do, please take a moment
to send a few yourself!

Regards,
Marty & Alice at 1001 Postcards
http://www.postcards.org

----------------------------= ------------------------------------------------

------=_NextPart_000_0007_01CA0DB9.C40D7E90-- From bistrog5@rabco.com Sun Jul 26 04:23:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D954828C11D; Sun, 26 Jul 2009 04:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.387 X-Spam-Level: **** X-Spam-Status: No, score=4.387 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1MhRQZHAhkS; Sun, 26 Jul 2009 04:23:14 -0700 (PDT) Received: from 88-122-105-188.rev.libertysurf.net (88-122-105-188.rev.libertysurf.net [88.122.105.188]) by core3.amsl.com (Postfix) with ESMTP id CEEAB28C122; Sun, 26 Jul 2009 04:23:13 -0700 (PDT) Received: from 88.122.105.188 by inbound.rabco.com.netsolmail.net; Sun, 26 Jul 2009 13:22:24 +0100 Date: Sun, 26 Jul 2009 13:22:24 +0100 From: X-Mailer: The Bat! (v2.00.3) Educational Reply-To: bistrog5@rabco.com X-Priority: 3 (Normal) Message-ID: <951544302.32782636210593@rabco.com> To: agentx-request@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear agentx-request@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Lora Dow

Subscribe | Privacy Statement | Unsubsc ribe
© 2009 iPharmacy Ltd, All rights reserved.
From implausibilitiesw54@searchmarketing.com Sun Jul 26 13:23:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A466F3A6AF3 for ; Sun, 26 Jul 2009 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.174 X-Spam-Level: X-Spam-Status: No, score=-19.174 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HELO_DYNAMIC_DHCP=1.398, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05JAoK2bomuI for ; Sun, 26 Jul 2009 13:23:25 -0700 (PDT) Received: from cm89.gamma155.maxonline.com.sg (cm89.gamma155.maxonline.com.sg [202.156.155.89]) by core3.amsl.com (Postfix) with ESMTP id 927263A68C2 for ; Sun, 26 Jul 2009 13:23:23 -0700 (PDT) Message-ID: <000d01ca0e2e$eb3cdf40$6400a8c0@implausibilitiesw54> From: "dnsext-archive@lists.ietf.org" To: Subject: Anibal Erickson sent you a postcard from 1001 Postcards! Date: Mon, 27 Jul 2009 04:23:21 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0E2E.EB3CDF40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0E2E.EB3CDF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oh happy day! Anibal Erickson sent you a postcard from 1001 Postcards! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Pickup your card safely and securely: 1. Go directly to your card at this address: http://www.postcards.org/cards/cardreceive.php?id=3D13671748669785390955884= 38504830068111072820218434702934770337696503372164951263&email=3Ddnsext-arc= hive@lists.ietf.org&from=3DAnibal Erickson 2. Please wait while postcard is loading. Your pickup code is: 21468-31621-25262-20278 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Your postcard will be available for 60 days. We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! Regards, Marty & Alice at 1001 Postcards http://www.postcards.org ---------------------------------------------------------------------------= - ------=_NextPart_000_0007_01CA0E2E.EB3CDF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Oh happy day! Anibal Erickso= n sent you a postcard from 1001 Postcards!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pickup your card safely and securely:

1. Go directly to your card = at this address:
http://www= postcards.org/cards/cardreceive.php?id=3D136717486697853909558843850483006= 8111072820218434702934770337696503372164951263&email=3Ddnsext-archive@lists= ietf.org&from=3DAnibal Erickson

2. Please wait while postcard is loading.

Your pickup code is: 21468-= 31621-25262-20278
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Your postcard will be availa= ble for 60 days.

We hope you enjoy your postc= ard, and if you do, please take a moment
to send a few yourself!

Regards,
Marty & Alice at 1001 Postcards
http://www.postcards.org

----------------------------= ------------------------------------------------

------=_NextPart_000_0007_01CA0E2E.EB3CDF40-- From lousesnq81@irie-yard.com Sun Jul 26 14:10:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C911C3A6767; Sun, 26 Jul 2009 14:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.666 X-Spam-Level: X-Spam-Status: No, score=-9.666 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K48-cPViV4xM; Sun, 26 Jul 2009 14:10:05 -0700 (PDT) Received: from user-38lm5ru.cable.mindspring.com (user-38lm5ru.cable.mindspring.com [209.91.23.126]) by core3.amsl.com (Postfix) with ESMTP id 7CC643A68DD; Sun, 26 Jul 2009 14:10:03 -0700 (PDT) Date: Sun, 26 Jul 2009 16:10:18 -0600 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Stay trim and fit with our product Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0

Having trouble reading this newsletter? Click here to see it in your browser.
You are receiving this newsletter because you signed up from our web site. Click here to unsubscribe.
If you would like to send this email to a friend click here.


NEW DISCOUNTS SEASON ANNOUNCED!

Hello kvachdmitry and welcome to our latest issue!

Lose Weight without moving a muscle

Enter without the key



This email was sent to dnsext-archive@lists.ietf.org
Click here to instantly unsubscribe.

(c) 2009 gmjxdq


Send to a friend
From teaspoonsful6@it2u.net Sun Jul 26 14:14:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1593A68C2; Sun, 26 Jul 2009 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -55.944 X-Spam-Level: X-Spam-Status: No, score=-55.944 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp84NvwYz1IR; Sun, 26 Jul 2009 14:14:51 -0700 (PDT) Received: from pool-96-251-175-156.lsanca.dsl-w.verizon.net (pool-96-251-175-156.lsanca.dsl-w.verizon.net [96.251.175.156]) by core3.amsl.com (Postfix) with ESMTP id C6AE73A67C0; Sun, 26 Jul 2009 14:14:49 -0700 (PDT) Date: Sun, 26 Jul 2009 14:14:33 -0800 Message-Id: From: dcpel-bounces@ietf.org To: dcpel-bounces@ietf.org Subject: Acai Berry supplement has helped me lose 30 pounds Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0

Having trouble reading this newsletter? Click here to see it in your browser.
You are receiving this newsletter because you signed up from our web site. Click here to unsubscribe.
If you would like to send this email to a friend click here.


NEW DISCOUNTS SEASON ANNOUNCED!

Hello kvachdmitry and welcome to our latest issue!

Enhance sexual desires , with Acai Berry.

Invitation to enter



This email was sent to dcpel-bounces@ietf.org
Click here to instantly unsubscribe.

(c) 2009 dwyry


Send to a friend
From owner-namedroppers@ops.ietf.org Sun Jul 26 14:48:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08B53A6BEB; Sun, 26 Jul 2009 14:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL2D+gHZKya4; Sun, 26 Jul 2009 14:48:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A5043A6AF3; Sun, 26 Jul 2009 14:48:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVBSb-000FL6-NS for namedroppers-data0@psg.com; Sun, 26 Jul 2009 21:40:49 +0000 Received: from [209.85.219.226] (helo=mail-ew0-f226.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVBSX-000FKM-K5 for namedroppers@ops.ietf.org; Sun, 26 Jul 2009 21:40:47 +0000 Received: by ewy26 with SMTP id 26so1579480ewy.41 for ; Sun, 26 Jul 2009 14:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=Gao5nADcHAX9LTutWplMe2mR15Z2CzbFgjOcI+jweH4=; b=LbE10N5DyEcGiP1vxjqs79xbm1lGO5Fg66ssPu+8yRfH5KQbRnjI8N5hms+mhTj7Nx 3dnH2Hk37hSrjdQ+aTu1PIVeXLg8adtkS67z5WPPOQuINNd8t/tVtjTL7oHufoYYUbfA hy8pRBU8ouCY6wWwe5OWJ09cO9iojpjk6w1X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=XjC/ZvKaI48OYN+Dc7N6jq+ie2JDr6vGsWImJ2VNRI/N43o1RslqfI45S3Deh4jQbY +wQzT+1FpgfpbPCGtkmE6/j2+WAbJSx0jhZO1QHCx4rSeW/Em9UjfubOQSfj5dHtjm2D ViG6CF4cWZuzActOimzh6zrs8DUeQRHjco97E= MIME-Version: 1.0 Received: by 10.211.148.3 with SMTP id a3mr1369486ebo.26.1248644444087; Sun, 26 Jul 2009 14:40:44 -0700 (PDT) From: bert hubert Date: Sun, 26 Jul 2009 23:40:24 +0200 Message-ID: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> Subject: [dnsext] some NSEC confusion on cname wildcards To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi everybody, I now have my prototype live-signing PowerDNS-with-DNSSEC working well enough that I know of no further protocol related issues with it, except for one discrepancy where I am not sure that what I am doing is wrong. Everyone is cordially invited to compare the results of powerdnssec.org as served by the PowerDNS experimental code with those served by more established servers. A version of the zone signed by dnssec-signzone can be found on http://www.powerdnssec.org. (non-do queries to this PowerDNS code may still miss some DNSSEC data). Now for the discrepancy, if we query PowerDNS for www.belgium.powerdnssec.org AAAA, we find that BIND and PowerDNS agree on the answer section: www.belgium.powerdnssec.org. 3600 IN CNAME powerdnssec.org. www.belgium.powerdnssec.org. 3600 IN RRSIG CNAME 5 3 3600 20090806000000 20090723000000 44332 powerdnssec.org. d3y5gxVaE7otS7eZjKtlVwmEq1EpmgqcFQD+V2qyrzxtoAxcZ/g65ucf A+az7TmxFCs2ZU6Lga1ZnibUK1RmjAXvsqg4uWy9sxxgN66QA7BHEF65 ME62tuldrePIggUDYjswpDbQGcXgr0NN0p/yLVALqUlEcBJe+WCFa7Pq BKM= (in the zone, there is: *.belgium.powerdnssec.org. 3600 IN CNAME powerdnssec.org.) However, PowerDNS then adds; *.belgium.powerdnssec.org. 3600 IN NSEC server.belgium.powerdnssec.org. CNAME RRSIG NSEC *.belgium.powerdnssec.org. 3600 IN RRSIG NSEC 5 3 3600 20090806000000 20090723000000 44332 powerdnssec.org. j/e4XDJYJOh1oGlawMMpPCDQuW8//+yYrlTCmzld+86NujpJOXRgelsT Fu6w867UcIMHqICqdP2nefkTFO9g0K/FTCO+qzmlPe8CcQNPrLpil/1h TpSE7E+b/Ph9e9DJQAUBwJvq1yaN7prPL8S08hrlb3Tg1wNFqZGwhmBw r8Y= Whereas BIND emits the 'next' NSEC: server.belgium.powerdnssec.org. 3600 IN NSEC france.powerdnssec.org. A RRSIG NSEC server.belgium.powerdnssec.org. 3600 IN RRSIG NSEC 5 4 3600 20090806000000 20090723000000 44332 powerdnssec.org. T92UcTDqG8FVwIw+XL2rzdzhhKUEKpaD2uw7WFLx+gcQry/xJ9eL+nRH OPXRhmsFsu+mpDuwlWcXYQq2PtnjUxXIPEA9eu2IDkJhIg+ePOfmrLNs plrVO2RsXOGPbQ2KXs8ZnT1nGVfu1RobL1y+aKLPdtW4WmTHbx1zQoOI Jec= Bind & PowerDNS then both add the powerdnssec.org SOA and NSEC records, and signatures. I've been scanning the various RFCs, but perhaps my eyes are a bit tired after all this coding, and I can't find elucidation. I'm assuming BIND is right, but I can't see why yet. If I'm missing the obvious, my apologies. If I've discovered a bug in BIND "9.5.0.dfsg.P2-1ubuntu3.1", I again apologise for not having used the right list to report it. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 26 15:24:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE9C3A6A0D; Sun, 26 Jul 2009 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXi61lwTHuDq; Sun, 26 Jul 2009 15:24:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEDBA3A69DE; Sun, 26 Jul 2009 15:23:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVC4H-000IIL-MR for namedroppers-data0@psg.com; Sun, 26 Jul 2009 22:19:45 +0000 Received: from [209.85.219.226] (helo=mail-ew0-f226.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVC48-000IHT-Fh for namedroppers@ops.ietf.org; Sun, 26 Jul 2009 22:19:43 +0000 Received: by ewy26 with SMTP id 26so1592323ewy.41 for ; Sun, 26 Jul 2009 15:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=zLReyH/rcEbf+8uJWT/b/uXh/SeCYPNLQkg+ro+Y35U=; b=m9g6/28Cz83kBfaRrGv+mpDc7gVBUfklaH1g1tfufM+i7rOKepLrDUtPLrzppr0lDu 7mFWjJKf4UTDzPNdniiNbFEXQX85q0zqRqkkTGtcf2cRmU2vD7lycUgxqsPpyMc3Hdcb SMiXFDiN5fD+vMGMbC/6dIzqiQ/v2irslhs1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=unuDIroFQl0MawOP+8PlGtSwlBoK6dUvByH7Vaws9ECJq9nSl+AhW52jqwITnBZ/Xt W/dBW2w8vQ34Ob5BmAqJ0t/OxnDMEE58C4h3/5YO84zpPuTLFzstYTvP+IfgZ//TXfXF /SZHS1C2idgr+1BvkigXwnP6lZ5McTcTk3wI8= MIME-Version: 1.0 Received: by 10.210.65.16 with SMTP id n16mr7395437eba.87.1248646774125; Sun, 26 Jul 2009 15:19:34 -0700 (PDT) In-Reply-To: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> References: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> From: bert hubert Date: Mon, 27 Jul 2009 00:19:14 +0200 Message-ID: <3efd34cc0907261519o3c376adft7a992fabcbef5a5d@mail.gmail.com> Subject: [dnsext] Re: some NSEC confusion on cname wildcards To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thanks to a quick off-list tip (thanks!), it turns out the covering NSEC in such cases should be generated from the original query name, and not from the wildcard name that matched it. I expect the rationale of supplying both an RRSIG for the wildcard-synthesised record, together with a 'covering' NSEC, is that the first proves the presence of a wildcard, the second one proves there was no non-wildcard data that would have trumped the wildcard? Both powerdnssec.org nameservers have been updated with this fix. I hope in the future only to bother you with real protocol questions, and not misunderstandings. Bert On Sun, Jul 26, 2009 at 11:40 PM, bert hubert wrote: > Hi everybody, > > I now have my prototype live-signing PowerDNS-with-DNSSEC working well > enough that I know of no further protocol related issues with it, > except for one discrepancy where I am not sure that what I am doing is > wrong. > > Everyone is cordially invited to compare the results of > powerdnssec.org as served by the PowerDNS experimental code with those > served by more established servers. A version of the zone signed by > dnssec-signzone can be found on http://www.powerdnssec.org. > (non-do queries to this PowerDNS code may still miss some DNSSEC data). > > Now for the discrepancy, if we query PowerDNS for > www.belgium.powerdnssec.org AAAA, we find that BIND and PowerDNS agree > on the answer section: > www.belgium.powerdnssec.org. 3600 IN =A0 =A0CNAME =A0 powerdnssec.org. > www.belgium.powerdnssec.org. 3600 IN =A0 =A0RRSIG =A0 CNAME 5 3 3600 > 20090806000000 20090723000000 44332 powerdnssec.org. > d3y5gxVaE7otS7eZjKtlVwmEq1EpmgqcFQD+V2qyrzxtoAxcZ/g65ucf > A+az7TmxFCs2ZU6Lga1ZnibUK1RmjAXvsqg4uWy9sxxgN66QA7BHEF65 > ME62tuldrePIggUDYjswpDbQGcXgr0NN0p/yLVALqUlEcBJe+WCFa7Pq BKM=3D > > (in the zone, there is: *.belgium.powerdnssec.org. 3600 IN CNAME > powerdnssec.org.) > > However, PowerDNS then adds; > *.belgium.powerdnssec.org. > 3600 =A0 =A0IN =A0 =A0 =A0NSEC =A0 =A0server.belgium.powerdnssec.org. CNA= ME RRSIG NSEC > *.belgium.powerdnssec.org. 3600 IN =A0 =A0 =A0RRSIG =A0 NSEC 5 3 3600 200= 90806000000 > 20090723000000 44332 powerdnssec.org. > j/e4XDJYJOh1oGlawMMpPCDQuW8//+yYrlTCmzld+86NujpJOXRgelsT > Fu6w867UcIMHqICqdP2nefkTFO9g0K/FTCO+qzmlPe8CcQNPrLpil/1h > TpSE7E+b/Ph9e9DJQAUBwJvq1yaN7prPL8S08hrlb3Tg1wNFqZGwhmBw r8Y=3D > > Whereas BIND emits the 'next' NSEC: > server.belgium.powerdnssec.org. 3600 IN NSEC =A0 =A0france.powerdnssec.or= g. A > RRSIG NSEC > server.belgium.powerdnssec.org. 3600 IN RRSIG =A0 NSEC 5 4 3600 > 20090806000000 20090723000000 44332 powerdnssec.org. > T92UcTDqG8FVwIw+XL2rzdzhhKUEKpaD2uw7WFLx+gcQry/xJ9eL+nRH > OPXRhmsFsu+mpDuwlWcXYQq2PtnjUxXIPEA9eu2IDkJhIg+ePOfmrLNs > plrVO2RsXOGPbQ2KXs8ZnT1nGVfu1RobL1y+aKLPdtW4WmTHbx1zQoOI Jec=3D > > Bind & PowerDNS then both add the powerdnssec.org SOA and NSEC > records, and signatures. > > I've been scanning the various RFCs, but perhaps my eyes are a bit > tired after all this coding, and I can't find elucidation. I'm > assuming BIND is right, but I can't see why yet. > > If I'm missing the obvious, my apologies. If I've discovered a bug in > BIND "9.5.0.dfsg.P2-1ubuntu3.1", I again apologise for not having used > the right list to report it. > > > =A0Bert > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 26 16:44:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A813A683C; Sun, 26 Jul 2009 16:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0itw-5RFCrLP; Sun, 26 Jul 2009 16:44:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19E013A6765; Sun, 26 Jul 2009 16:44:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVDK3-000OrV-KG for namedroppers-data0@psg.com; Sun, 26 Jul 2009 23:40:07 +0000 Received: from [209.86.89.67] (helo=elasmtp-scoter.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVDJx-000Or1-Cj for namedroppers@ops.ietf.org; Sun, 26 Jul 2009 23:40:05 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=rCohSGkwQiehuMCc0MxcimJurwqmt7r0s8WUr+rBa3v0zSr+9xKRPeo2xiEKyH3l; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.103.118] (helo=ix.netcom.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MVDJv-0004tl-51; Sun, 26 Jul 2009 19:40:00 -0400 Message-ID: <4A6D045C.C8F3AB89@ix.netcom.com> Date: Sun, 26 Jul 2009 18:35:25 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bert hubert CC: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Subject: Re: [dnsext] Re: some NSEC confusion on cname wildcards References: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> <3efd34cc0907261519o3c376adft7a992fabcbef5a5d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c0260b890255e342a66ec937c1bebdc0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.118 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bert and all, Your welcome. I didn't think I helped that much though... Also I am sure your correct that the covering NSEC generated by the original query name is what should happen, not the wildcard. That could be manipulated however if you desire to allow signed wildcards... bert hubert wrote: > Thanks to a quick off-list tip (thanks!), it turns out the covering > NSEC in such cases should be generated from the original query name, > and not from the wildcard name that matched it. > > I expect the rationale of supplying both an RRSIG for the > wildcard-synthesised record, together with a 'covering' NSEC, is that > the first proves the presence of a wildcard, the second one proves > there was no non-wildcard data that would have trumped the wildcard? > > Both powerdnssec.org nameservers have been updated with this fix. > > I hope in the future only to bother you with real protocol questions, > and not misunderstandings. > > Bert > > On Sun, Jul 26, 2009 at 11:40 PM, bert hubert wrote: > > Hi everybody, > > > > I now have my prototype live-signing PowerDNS-with-DNSSEC working well > > enough that I know of no further protocol related issues with it, > > except for one discrepancy where I am not sure that what I am doing is > > wrong. > > > > Everyone is cordially invited to compare the results of > > powerdnssec.org as served by the PowerDNS experimental code with those > > served by more established servers. A version of the zone signed by > > dnssec-signzone can be found on http://www.powerdnssec.org. > > (non-do queries to this PowerDNS code may still miss some DNSSEC data). > > > > Now for the discrepancy, if we query PowerDNS for > > www.belgium.powerdnssec.org AAAA, we find that BIND and PowerDNS agree > > on the answer section: > > www.belgium.powerdnssec.org. 3600 IN CNAME powerdnssec.org. > > www.belgium.powerdnssec.org. 3600 IN RRSIG CNAME 5 3 3600 > > 20090806000000 20090723000000 44332 powerdnssec.org. > > d3y5gxVaE7otS7eZjKtlVwmEq1EpmgqcFQD+V2qyrzxtoAxcZ/g65ucf > > A+az7TmxFCs2ZU6Lga1ZnibUK1RmjAXvsqg4uWy9sxxgN66QA7BHEF65 > > ME62tuldrePIggUDYjswpDbQGcXgr0NN0p/yLVALqUlEcBJe+WCFa7Pq BKM= > > > > (in the zone, there is: *.belgium.powerdnssec.org. 3600 IN CNAME > > powerdnssec.org.) > > > > However, PowerDNS then adds; > > *.belgium.powerdnssec.org. > > 3600 IN NSEC server.belgium.powerdnssec.org. CNAME RRSIG NSEC > > *.belgium.powerdnssec.org. 3600 IN RRSIG NSEC 5 3 3600 20090806000000 > > 20090723000000 44332 powerdnssec.org. > > j/e4XDJYJOh1oGlawMMpPCDQuW8//+yYrlTCmzld+86NujpJOXRgelsT > > Fu6w867UcIMHqICqdP2nefkTFO9g0K/FTCO+qzmlPe8CcQNPrLpil/1h > > TpSE7E+b/Ph9e9DJQAUBwJvq1yaN7prPL8S08hrlb3Tg1wNFqZGwhmBw r8Y= > > > > Whereas BIND emits the 'next' NSEC: > > server.belgium.powerdnssec.org. 3600 IN NSEC france.powerdnssec.org. A > > RRSIG NSEC > > server.belgium.powerdnssec.org. 3600 IN RRSIG NSEC 5 4 3600 > > 20090806000000 20090723000000 44332 powerdnssec.org. > > T92UcTDqG8FVwIw+XL2rzdzhhKUEKpaD2uw7WFLx+gcQry/xJ9eL+nRH > > OPXRhmsFsu+mpDuwlWcXYQq2PtnjUxXIPEA9eu2IDkJhIg+ePOfmrLNs > > plrVO2RsXOGPbQ2KXs8ZnT1nGVfu1RobL1y+aKLPdtW4WmTHbx1zQoOI Jec= > > > > Bind & PowerDNS then both add the powerdnssec.org SOA and NSEC > > records, and signatures. > > > > I've been scanning the various RFCs, but perhaps my eyes are a bit > > tired after all this coding, and I can't find elucidation. I'm > > assuming BIND is right, but I can't see why yet. > > > > If I'm missing the obvious, my apologies. If I've discovered a bug in > > BIND "9.5.0.dfsg.P2-1ubuntu3.1", I again apologise for not having used > > the right list to report it. > > > > > > Bert > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From carnot50@studies.it Sun Jul 26 17:51:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425F23A67DF; Sun, 26 Jul 2009 17:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.583 X-Spam-Level: *** X-Spam-Status: No, score=3.583 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W29zpTY5AQJK; Sun, 26 Jul 2009 17:51:27 -0700 (PDT) Received: from 201-1-125-118.dsl.telesp.net.br (201-1-125-118.dsl.telesp.net.br [201.1.125.118]) by core3.amsl.com (Postfix) with ESMTP id 0F4733A67B2; Sun, 26 Jul 2009 17:51:26 -0700 (PDT) Received: from 201.1.125.118 by studies.it; Sun, 26 Jul 2009 21:50:37 -0300 Date: Sun, 26 Jul 2009 21:50:37 -0300 From: X-Mailer: The Bat! (v3.5) Educational Reply-To: carnot50@studies.it X-Priority: 3 (Normal) Message-ID: <279237640.32810027300753@studies.it> To: dnsext-archive@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear dnsext-archive@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Chrystal Holder

Subscribe | Privacy Statement | Unsubscribe
© 2009 iPharmacy Ltd, All rights reserved.
From owner-namedroppers@ops.ietf.org Sun Jul 26 21:15:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BD93A6846; Sun, 26 Jul 2009 21:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_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 nxyGFtKjVSYl; Sun, 26 Jul 2009 21:15:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B9BB3A67A5; Sun, 26 Jul 2009 21:15:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVHW6-000PIo-AC for namedroppers-data0@psg.com; Mon, 27 Jul 2009 04:08:50 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVHUj-000P6L-19 for namedroppers@ops.ietf.org; Mon, 27 Jul 2009 04:07:46 +0000 Received: from drugs.dv.isc.org (unknown [212.112.167.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 72241E6070; Mon, 27 Jul 2009 04:07:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6R45fYj013323; Mon, 27 Jul 2009 14:05:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907270405.n6R45fYj013323@drugs.dv.isc.org> To: bert hubert Cc: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" From: Mark Andrews References: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> Subject: Re: [dnsext] some NSEC confusion on cname wildcards In-reply-to: Your message of "Sun, 26 Jul 2009 23:40:24 +0200." <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> Date: Mon, 27 Jul 2009 14:05:41 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com>, bert hubert writes: > Hi everybody, > > I now have my prototype live-signing PowerDNS-with-DNSSEC working well > enough that I know of no further protocol related issues with it, > except for one discrepancy where I am not sure that what I am doing is > wrong. > > Everyone is cordially invited to compare the results of > powerdnssec.org as served by the PowerDNS experimental code with those > served by more established servers. A version of the zone signed by > dnssec-signzone can be found on http://www.powerdnssec.org. > (non-do queries to this PowerDNS code may still miss some DNSSEC data). > > Now for the discrepancy, if we query PowerDNS for > www.belgium.powerdnssec.org AAAA, we find that BIND and PowerDNS agree > on the answer section: > www.belgium.powerdnssec.org. 3600 IN CNAME powerdnssec.org. > www.belgium.powerdnssec.org. 3600 IN RRSIG CNAME 5 3 3600 > 20090806000000 20090723000000 44332 powerdnssec.org. > d3y5gxVaE7otS7eZjKtlVwmEq1EpmgqcFQD+V2qyrzxtoAxcZ/g65ucf > A+az7TmxFCs2ZU6Lga1ZnibUK1RmjAXvsqg4uWy9sxxgN66QA7BHEF65 > ME62tuldrePIggUDYjswpDbQGcXgr0NN0p/yLVALqUlEcBJe+WCFa7Pq BKM= > > (in the zone, there is: *.belgium.powerdnssec.org. 3600 IN CNAME > powerdnssec.org.) > > However, PowerDNS then adds; > *.belgium.powerdnssec.org. > 3600 IN NSEC server.belgium.powerdnssec.org. CNAME RRSIG NSEC > *.belgium.powerdnssec.org. 3600 IN RRSIG NSEC 5 3 3600 20090806000000 > 20090723000000 44332 powerdnssec.org. > j/e4XDJYJOh1oGlawMMpPCDQuW8//+yYrlTCmzld+86NujpJOXRgelsT > Fu6w867UcIMHqICqdP2nefkTFO9g0K/FTCO+qzmlPe8CcQNPrLpil/1h > TpSE7E+b/Ph9e9DJQAUBwJvq1yaN7prPL8S08hrlb3Tg1wNFqZGwhmBw r8Y= > > Whereas BIND emits the 'next' NSEC: > server.belgium.powerdnssec.org. 3600 IN NSEC france.powerdnssec.org. A > RRSIG NSEC > server.belgium.powerdnssec.org. 3600 IN RRSIG NSEC 5 4 3600 > 20090806000000 20090723000000 44332 powerdnssec.org. > T92UcTDqG8FVwIw+XL2rzdzhhKUEKpaD2uw7WFLx+gcQry/xJ9eL+nRH > OPXRhmsFsu+mpDuwlWcXYQq2PtnjUxXIPEA9eu2IDkJhIg+ePOfmrLNs > plrVO2RsXOGPbQ2KXs8ZnT1nGVfu1RobL1y+aKLPdtW4WmTHbx1zQoOI Jec= You have to prove the QNAME does not exist to prove that the wildcard answer is valid. This requires finding the NSEC record that covers QNAME and show that QNAME was not in the zone. This is to prevent answers being picked apart, reassembled and replayed to get the wildcard rather than a record that is there (e.g. server.belgium.powerdnssec.org). www.belgium.powerdnssec.org is between server.belgium.powerdnssec.org and france.powerdnssec.org when the zone is sorted in DNSSEC order so that is the NSEC that is returned. > Bind & PowerDNS then both add the powerdnssec.org SOA and NSEC > records, and signatures. > > I've been scanning the various RFCs, but perhaps my eyes are a bit > tired after all this coding, and I can't find elucidation. I'm > assuming BIND is right, but I can't see why yet. > > If I'm missing the obvious, my apologies. If I've discovered a bug in > BIND "9.5.0.dfsg.P2-1ubuntu3.1", I again apologise for not having used > the right list to report it. > > > Bert > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From illegality83@skor.nl Sun Jul 26 21:21:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590F33A6BF4; Sun, 26 Jul 2009 21:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.293 X-Spam-Level: * X-Spam-Status: No, score=1.293 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, GB_PHARMACY=1, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgt3sf0CeXvv; Sun, 26 Jul 2009 21:21:13 -0700 (PDT) Received: from CableLink-173-228-82.CPE.InterCable.net (CableLink-173-228-82.CPE.InterCable.net [201.173.228.82]) by core3.amsl.com (Postfix) with ESMTP id 900E13A6846; Sun, 26 Jul 2009 21:21:13 -0700 (PDT) Received: from 201.173.228.82 by fallback.vbvb.nl; Sun, 26 Jul 2009 23:19:52 -0600 Date: Sun, 26 Jul 2009 23:19:52 -0600 From: X-Mailer: The Bat! (v2.00) Educational Reply-To: illegality83@skor.nl X-Priority: 3 (Normal) Message-ID: <405704209.27414663837328@skor.nl> To: dnsext-archive@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear dnsext-archive@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Mohammad Mathis

Subscribe | Privacy Statement | Unsubscribe
© 2009 iPharmacy Ltd, All rights reserved.
From owner-namedroppers@ops.ietf.org Sun Jul 26 23:32:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FA428C0F5; Sun, 26 Jul 2009 23:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BNAJinsx35D; Sun, 26 Jul 2009 23:32:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97DC828C0EC; Sun, 26 Jul 2009 23:32:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVJf0-000JMA-9M for namedroppers-data0@psg.com; Mon, 27 Jul 2009 06:26:10 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVJev-000JKj-E2 for namedroppers@ops.ietf.org; Mon, 27 Jul 2009 06:26:08 +0000 Received: from dhcp-170f.meeting.ietf.org (dhcp-170f.meeting.ietf.org [130.129.23.15]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6R6PxgJ059680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jul 2009 08:26:00 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Cc: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Message-Id: <3787CAF0-0031-40FF-8E33-4E7207E67815@NLnetLabs.nl> From: Olaf Kolkman To: bert hubert In-Reply-To: <3efd34cc0907261519o3c376adft7a992fabcbef5a5d@mail.gmail.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6--214180127" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: some NSEC confusion on cname wildcards Date: Mon, 27 Jul 2009 08:25:59 +0200 References: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> <3efd34cc0907261519o3c376adft7a992fabcbef5a5d@mail.gmail.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [213.154.224.1]); Mon, 27 Jul 2009 08:26:00 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6--214180127 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 jul 2009, at 00:19, bert hubert wrote: > Thanks to a quick off-list tip (thanks!), it turns out the covering > NSEC in such cases should be generated from the original query name, > and not from the wildcard name that matched it. > > I expect the rationale of supplying both an RRSIG for the > wildcard-synthesised record, together with a 'covering' NSEC, is that > the first proves the presence of a wildcard, the second one proves > there was no non-wildcard data that would have trumped the wildcard? > > Both powerdnssec.org nameservers have been updated with this fix. > > I hope in the future only to bother you with real protocol questions, > and not misunderstandings. Well, keep these questions coming, they may indicate that the specs are not clear. In fact, any implementation experience, specifically clarifications can be put in: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates Maybe you can capture what you learned in that document. --Olaf --Apple-Mail-6--214180127 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkptSHcACgkQtN/ca3YJIoeqnACcCG5KXChAu5Rdey9pQu7VupoU 2WUAn2dmwBH3eZdl85tCTIpcA78qnrBZ =4xtv -----END PGP SIGNATURE----- --Apple-Mail-6--214180127-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From terrorismnu4@softwerxconsulting.com Mon Jul 27 00:52:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBB028C11B; Mon, 27 Jul 2009 00:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.622 X-Spam-Level: X-Spam-Status: No, score=-9.622 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_PHARMACY=1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_RECV_VIRTUACOMBR=1.193, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbBpwTU8O0ix; Mon, 27 Jul 2009 00:52:28 -0700 (PDT) Received: from c9065817.virtua.com.br (c9065817.virtua.com.br [201.6.88.23]) by core3.amsl.com (Postfix) with ESMTP id 7B85428C164; Mon, 27 Jul 2009 00:52:28 -0700 (PDT) Received: from 201.6.88.23 by softwerxconsulting.com; Mon, 27 Jul 2009 04:52:11 -0300 Date: Mon, 27 Jul 2009 04:52:11 -0300 From: X-Mailer: The Bat! (v2.00.5) Personal Reply-To: terrorismnu4@softwerxconsulting.com X-Priority: 3 (Normal) Message-ID: <445289765.19511101837657@softwerxconsulting.com> To: ancp@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear ancp@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Malinda Mckee

Subscribe | Privacy Statement | Un subscribe
© 2009 iPharmacy Ltd, All rights reserved.
From fireproofsn2@stahlquartett.de Mon Jul 27 04:43:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038963A6C5B; Mon, 27 Jul 2009 04:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.634 X-Spam-Level: X-Spam-Status: No, score=-19.634 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeRSEcTPCzbY; Mon, 27 Jul 2009 04:43:05 -0700 (PDT) Received: from ppp-94-66-142-193.home.otenet.gr (ppp-94-66-142-193.home.otenet.gr [94.66.142.193]) by core3.amsl.com (Postfix) with ESMTP id BB7B33A6875; Mon, 27 Jul 2009 04:43:04 -0700 (PDT) Received: from 94.66.142.193 by mailin.rzone.de; Mon, 27 Jul 2009 14:43:05 +0200 Date: Mon, 27 Jul 2009 14:43:05 +0200 From: X-Mailer: The Bat! (v3.81.14 Beta) Professional Reply-To: fireproofsn2@stahlquartett.de X-Priority: 3 (Normal) Message-ID: <450469440.39580029445589@stahlquartett.de> To: imss@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear imss@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Brian Terry

Subscribe | Privacy Statement | Unsubscribe
© 2009 iPharmacy Ltd, All rights reserved.
From earacheoj9@rowersworld.com Mon Jul 27 06:16:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D67F28C180; Mon, 27 Jul 2009 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CLUBINTERNET=0.781, HELO_EQ_DSL=1.129, HELO_EQ_FR=0.35, HOST_EQ_CLUBINTERNET=0.663, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om29-JLKQs4f; Mon, 27 Jul 2009 06:16:53 -0700 (PDT) Received: from mtr77-1-87-88-38-24.dsl.club-internet.fr (mtr77-1-87-88-38-24.dsl.club-internet.fr [87.88.38.24]) by core3.amsl.com (Postfix) with ESMTP id 35B993A6C73; Mon, 27 Jul 2009 06:16:52 -0700 (PDT) Received: from 87.88.38.24 by aspmx3.googlemail.com; Mon, 27 Jul 2009 15:15:45 +0100 Date: Mon, 27 Jul 2009 15:15:45 +0100 From: X-Mailer: The Bat! (v3.71.14) Home Reply-To: earacheoj9@rowersworld.com X-Priority: 3 (Normal) Message-ID: <375286962.27237040062377@rowersworld.com> To: agentx-request@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear agentx-request@ietf.org,

Welcome to the July issue.

If you unable to see this image, click 
 here

Kind Regards,
Jerrold Washburn

Subscribe | Privacy Statement | Unsubscribe
© 2009 iPharmacy Ltd, All rights reserved.
From owner-namedroppers@ops.ietf.org Mon Jul 27 07:09:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990893A6ADE; Mon, 27 Jul 2009 07:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNJmW1ffi7Qp; Mon, 27 Jul 2009 07:09:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B260328C23D; Mon, 27 Jul 2009 07:09:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVQlS-00013I-K7 for namedroppers-data0@psg.com; Mon, 27 Jul 2009 14:01:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVQlO-000122-NN for namedroppers@ops.ietf.org; Mon, 27 Jul 2009 14:01:16 +0000 Received: from [10.31.200.165] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6RE16DL025535; Mon, 27 Jul 2009 10:01:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3787CAF0-0031-40FF-8E33-4E7207E67815@NLnetLabs.nl> References: <3efd34cc0907261440q776b2a73od31329d22a81cc80@mail.gmail.com> <3efd34cc0907261519o3c376adft7a992fabcbef5a5d@mail.gmail.com> <3787CAF0-0031-40FF-8E33-4E7207E67815@NLnetLabs.nl> Date: Mon, 27 Jul 2009 10:01:02 -0400 To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" From: Edward Lewis Subject: Re: [dnsext] Re: some NSEC confusion on cname wildcards Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-963419230==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-963419230==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:25 +0200 7/27/09, Olaf Kolkman wrote: >Well, keep these questions coming, they may indicate that the specs >are not clear. That's would have been my reply. There are lots of places where "the rationale" didn't seem to make it into text. In this instance - DNSSEC is not meant to only add signatures to what is sent, but to also add signed records to prove that the algorithm in RFC 1034, 4.3.2 was properly followed. (I.e., prove when "...at some label, a match is impossible" resulting in looking "to see if a the [sic] "*" label exists".) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-963419230==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Re: some NSEC confusion on cname wildcards
At 8:25 +0200 7/27/09, Olaf Kolkman wrote:

>Well, keep these questions coming, they may indicate that the specs
>are not clear.

That's would have been my reply.

There are lots of places where "the rationale" didn't seem to make it into text.

In this instance - DNSSEC is not meant to only add signatures to what is sent, but to also add signed records to prove that the algorithm in RFC 1034, 4.3.2 was properly followed.  (I.e., prove when "...at some label, a match is impossible" resulting in looking "to see if a the [sic] "*" label exists".)

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-963419230==_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 procedural13@italy-weddings.net Mon Jul 27 08:01:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B4A3A68FD; Mon, 27 Jul 2009 08:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.926 X-Spam-Level: X-Spam-Status: No, score=-42.926 tagged_above=-999 required=5 tests=[BAYES_95=3, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, SARE_UNI=0.591, UNPARSEABLE_RELAY=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhbPpdO-cjdA; Mon, 27 Jul 2009 08:01:24 -0700 (PDT) Received: from 79-73-28.dial.terra.cl (79-73-28.dial.terra.cl [200.28.73.79]) by core3.amsl.com (Postfix) with ESMTP id 441073A699E; Mon, 27 Jul 2009 08:01:23 -0700 (PDT) Received: from 200.28.73.79 by italy-weddings.net Date: Mon, 27 Jul 2009 10:59:41 -0400 Message-Id: <7ZLWC61176.7XKT00O95R233485@200.28.73.79.italy-weddings.net> From: aaa-archive@lists.ietf.org To: aaa-archive@lists.ietf.org Subject: Acai Berry has saved lives , let it help yours get your trial Now. Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
View this email as a Web page Please add us to your Safe Sender list.
Using a mobile device? Click this link

Blocked images? Click here to enable


Thank you for reading HOT Daily!
Make sure your copy of Daily News is not blocked by anti-spam software. Be sure to add us to your list of allowed senders and contacts.

Tell your friends and colleagues to sign-up for the HOT Daily newsletter  Click Here


2009 All Rights Reserved
You received this newsletter at kvachdmitry@gmail.com
To Unsubscribe from this list please follow this link unsubscribe

Manage your online subscriptions here
From owner-namedroppers@ops.ietf.org Mon Jul 27 09:17:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C2B28C1A0; Mon, 27 Jul 2009 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etmQo-KIeC07; Mon, 27 Jul 2009 09:17:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2C8D3A6B1F; Mon, 27 Jul 2009 09:17:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVSof-000IDn-CP for namedroppers-data0@psg.com; Mon, 27 Jul 2009 16:12:45 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVSoa-000ICv-8e for namedroppers@ops.ietf.org; Mon, 27 Jul 2009 16:12:43 +0000 Received: from crankycanuck.ca (host-78-64-88-217.homerun.telia.com [78.64.88.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 78AD32FE8ED5 for ; Mon, 27 Jul 2009 16:12:38 +0000 (UTC) Date: Mon, 27 Jul 2009 12:12:36 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Materials for any talking Message-ID: <20090727161235.GG3192@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, This is a reminder that if you expect to be speaking at the DNSEXT meeting this Wed., you need (1) to tell me if you haven't already and (2) to send me your slides. (2) MUST be done in advance. We saw today in DNSOP the difficulty with projectors, so I'm really hoping we can do everything from one laptop. If you can't get the slides in advance, put them on a USB drive or something. We don't want to waste meeting time fooling with projection problems. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From dnslam@geocities.com Mon Jul 27 11:39:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C863A69F4 for ; Mon, 27 Jul 2009 11:39:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: "VIAGRA \256 Official Site"[...] X-Spam-Flag: NO X-Spam-Score: -42.106 X-Spam-Level: X-Spam-Status: No, score=-42.106 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gywDGpbzUgoi for ; Mon, 27 Jul 2009 11:39:03 -0700 (PDT) Received: from pi46-33-48.cn.ru (pi46-32-48.cn.ru [195.46.32.48]) by core3.amsl.com (Postfix) with SMTP id 35CB33A6C85 for ; Mon, 27 Jul 2009 11:38:49 -0700 (PDT) To: Subject: RE: DISCOUNT ID77682 75% 0FF on Pfizer ! From: "VIAGRA ® Official Site" MIME-Version: 1.0 Importance: High Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20090727183850.35CB33A6C85@core3.amsl.com> Date: Mon, 27 Jul 2009 11:38:49 -0700 (PDT)
*By clicking on the link above, you will be leaving this Pfizer site. Links to other sites are provided as a convenience to the viewer.

Can't See Images? Click here!
From impressivevebx86@sfasoft.com Mon Jul 27 12:49:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30593A6CEB; Mon, 27 Jul 2009 12:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, 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, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh0vUuXejOoJ; Mon, 27 Jul 2009 12:49:53 -0700 (PDT) Received: from 64-130-171-159.pool.dsl.scrtc.com (64-130-171-159.pool.dsl.scrtc.com [64.130.171.159]) by core3.amsl.com (Postfix) with ESMTP id EAAE43A6CF6; Mon, 27 Jul 2009 12:49:52 -0700 (PDT) Received: from 64.130.171.159 by aspmx.l.google.com; Mon, 27 Jul 2009 14:49:50 -0600 From: problem-archive@lists.ietf.org To: problem-archive@lists.ietf.org Subject: Its so easy to look great Try Anitrim with Acai Berries. Date: Mon, 27 Jul 2009 14:49:50 -0600 Message-ID: MIME-version: 1.0 Content-type: text/html; charset="iso-8859-2"
Click here to view as a web page.

Make her glad she chose you
Unsubscribe |  Change e-mail address |  Privacy Policy |  About Us

Copyright (c) 2009 eatvfv Inc. All rights reserved.
 
From squishes8@itair.com Mon Jul 27 14:36:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EF33A6C2C; Mon, 27 Jul 2009 14:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.034 X-Spam-Level: X-Spam-Status: No, score=-17.034 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCNVnjEY6hUg; Mon, 27 Jul 2009 14:36:03 -0700 (PDT) Received: from host242-172-dynamic.181-80-r.retail.telecomitalia.it (host242-172-dynamic.181-80-r.retail.telecomitalia.it [80.181.172.242]) by core3.amsl.com (Postfix) with ESMTP id C99483A6B29; Mon, 27 Jul 2009 14:36:01 -0700 (PDT) Date: Mon, 27 Jul 2009 23:35:43 +0100 Message-Id: From: Jeane Ladd To: ftpext-archive@lists.ietf.org Subject: Get The power of Acai working for you. Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
View this email as a Web page Please add us to your Safe Sender list.
Using a mobile device? Click this link

Blocked images? Click here to enable


Thank you for reading HOT Daily!
Make sure your copy of Daily News is not blocked by anti-spam software. Be sure to add us to your list of allowed senders and contacts.

Tell your friends and colleagues to sign-up for the HOT Daily newsletter  Click Here


2009 All Rights Reserved
You received this newsletter at kvachdmitry@gmail.com
To Unsubscribe from this list please follow this link unsubscribe

Manage your online subscriptions here
From quartjo2@riversedgefurniture.com Mon Jul 27 16:42:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BFA3A6C2E; Mon, 27 Jul 2009 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.484 X-Spam-Level: X-Spam-Status: No, score=-9.484 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_203=0.994, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfw4cIeOfH2S; Mon, 27 Jul 2009 16:42:18 -0700 (PDT) Received: from stylek.lnk.telstra.net (stylek.lnk.telstra.net [203.45.78.237]) by core3.amsl.com (Postfix) with ESMTP id 35E103A6878; Mon, 27 Jul 2009 16:42:18 -0700 (PDT) Received: from 203.45.78.237 by mail.riversedgefurniture.com; Tue, 28 Jul 2009 09:42:15 +1000 Date: Tue, 28 Jul 2009 09:42:15 +1000 Message-Id: From: dix@ietf.org To: dix@ietf.org Subject: Enhance sexual Desire , Try Anitrim with Acai Berries. Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Click here to view as a web page.

Add Anitrim with Acai Berries to your Diet. Lose weight Instantly.
Unsubscribe |  Change e-mail address |  Privacy Policy |  About Us

Copyright (c) 2009 gmdrl Inc. All rights reserved.
 
From jabbersxe@isuus.com Mon Jul 27 16:58:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017823A6CA7; Mon, 27 Jul 2009 16:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.417 X-Spam-Level: X-Spam-Status: No, score=-38.417 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7oD7t00qoh9; Mon, 27 Jul 2009 16:58:20 -0700 (PDT) Received: from 201-43-119-32.dsl.telesp.net.br (201-43-119-32.dsl.telesp.net.br [201.43.119.32]) by core3.amsl.com (Postfix) with ESMTP id B31B93A6C45; Mon, 27 Jul 2009 16:58:19 -0700 (PDT) Date: Mon, 27 Jul 2009 20:52:46 -0300 Message-Id: From: Deborah Yu To: dnsext-archive@lists.ietf.org Subject: Slow down your aging process , Try Acai Berry. Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Get your stock of acaiberry at superbly discounted prices
 
Start your weight loss journey immediately , with Acai Slim.
Acai Berry , do yourself the favor.


best regards Deborah Yu
From gibbons7@rouxster.com Mon Jul 27 17:37:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4583A6AF9; Mon, 27 Jul 2009 17:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.951 X-Spam-Level: X-Spam-Status: No, score=-37.951 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_URI_CONS7=0.306, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQf4n7slitSx; Mon, 27 Jul 2009 17:37:19 -0700 (PDT) Received: from pc-104-151-45-190.cm.vtr.net (pc-104-151-45-190.cm.vtr.net [190.45.151.104]) by core3.amsl.com (Postfix) with ESMTP id DE36C3A6A6B; Mon, 27 Jul 2009 17:37:18 -0700 (PDT) Received: from 190.45.151.104 by mx2.turbodns.co.uk; Mon, 27 Jul 2009 20:37:11 -0400 Date: Mon, 27 Jul 2009 20:37:11 -0400 From: X-Mailer: The Bat! (v3.62.14) Educational Reply-To: gibbons7@rouxster.com X-Priority: 3 (Normal) Message-ID: <230990068.17620305782268@rouxster.com> To: agentx-request@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear agentx-request@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Rhonda Albert

Subscribe | Privacy Statement | Un subscribe
© 2009 iPharmacy Ltd, All rights reserved.
From homogenizedufee@rise.net.au Mon Jul 27 19:02:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5893A68E4; Mon, 27 Jul 2009 19:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.324 X-Spam-Level: X-Spam-Status: No, score=-18.324 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcxwg1ied4X2; Mon, 27 Jul 2009 19:02:33 -0700 (PDT) Received: from 201-75-56-205-ma.cpe.vivax.com.br (201-75-56-205-ma.cpe.vivax.com.br [201.75.56.205]) by core3.amsl.com (Postfix) with ESMTP id 660BF3A69AF; Mon, 27 Jul 2009 19:02:29 -0700 (PDT) Received: from 201.75.56.205 by extreme01.extremedsl.com.au; Mon, 27 Jul 2009 23:02:24 -0300 Message-ID: <000d01ca0f27$734b3410$6400a8c0@homogenizedufee> From: channel-binding@ietf.org To: Subject: Beneficial Berry , Acai works to help you lose wieght fast. Date: Mon, 27 Jul 2009 23:02:24 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0F27.734B3410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0F27.734B3410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy Acai Berry is amazingly smooth and suprisingl= y tasty, Get your free trial.=20 =A0 Run inside Copyright C 2009=20 Mxlbkbrrpbutiq=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01CA0F27.734B3410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web.
= Unsubscr= ibe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy


 Acai Berry is amazingly smooth and= suprisingly tasty, Get your free trial.
= =A0
= Run insi= de


Copyright C 2009=20
Mxlbkbrrpbutiq=20 International,=20 Inc.
=A0
------=_NextPart_000_0007_01CA0F27.734B3410-- From endocrinecpk101@isvgroup.com Mon Jul 27 19:48:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24AB3A6C62; Mon, 27 Jul 2009 19:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.643 X-Spam-Level: X-Spam-Status: No, score=-26.643 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id claOrm1-v5Oe; Mon, 27 Jul 2009 19:48:29 -0700 (PDT) Received: from dbe4df1bf.dslam-172-17-16-243-436-1340-mad-03.dsl.cantv.net (unknown [190.77.241.191]) by core3.amsl.com (Postfix) with ESMTP id 00C193A6A6F; Mon, 27 Jul 2009 19:48:25 -0700 (PDT) Date: Mon, 27 Jul 2009 23:48:18 -0300 Message-Id: <9TZX0DF7715.9ISFL96YXC9537@190.77.241.191.isvgroup.com> From: emu-request@ietf.org To: emu-request@ietf.org Subject: Acai the fat buster Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Read this newsletter ONLINE
From chignonsvdb@stadegeneve.ch Mon Jul 27 22:34:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C25D3A67B7; Mon, 27 Jul 2009 22:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.948 X-Spam-Level: X-Spam-Status: No, score=-78.948 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-XhPtbcasVp; Mon, 27 Jul 2009 22:34:02 -0700 (PDT) Received: from ktv77-234-84-170.bonyhad.pool.tvnet.hu (ktv77-234-84-170.bonyhad.pool.tvnet.hu [77.234.84.170]) by core3.amsl.com (Postfix) with ESMTP id ACE033A684B; Mon, 27 Jul 2009 22:34:01 -0700 (PDT) Received: from 77.234.84.170 by mta-gw.infomaniak.ch; Mon, 27 Jul 2009 22:33:33 -0800 Date: Mon, 27 Jul 2009 22:33:33 -0800 From: X-Mailer: The Bat! (v3.71.04) Professional Reply-To: chignonsvdb@stadegeneve.ch X-Priority: 3 (Normal) Message-ID: <183671863.50889665639522@stadegeneve.ch> To: imss@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear imss@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Quinton Reyna

Subscribe | Privacy Statement | Un subscribe
© 2009 iPharmacy Ltd, All rights reserved.
From obsessionhjd1@rofin-baasel.com Tue Jul 28 01:39:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CDE13A6889; Tue, 28 Jul 2009 01:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.343 X-Spam-Level: X-Spam-Status: No, score=-58.343 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGjDftpp3vmE; Tue, 28 Jul 2009 01:39:25 -0700 (PDT) Received: from 25-34-132-95.pool.ukrtel.net (25-34-132-95.pool.ukrtel.net [95.132.34.25]) by core3.amsl.com (Postfix) with ESMTP id E4AF43A6DC6; Tue, 28 Jul 2009 01:38:53 -0700 (PDT) Received: from 95.132.34.25 by exchange.rofin-baasel.com; Tue, 28 Jul 2009 11:38:24 +0200 Date: Tue, 28 Jul 2009 11:38:24 +0200 From: X-Mailer: The Bat! (v3.51) Home Reply-To: obsessionhjd1@rofin-baasel.com X-Priority: 3 (Normal) Message-ID: <069627220.08669531028491@rofin-baasel.com> To: bliss@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear bliss@ietf.org,

Welcome to the July issue.

If you unable to see this image, click here

Kind Regards,
Lavern Henson

Subscribe | Privacy Statement | Un subscribe
© 2009 iPharmacy Ltd, All rights reserved.
From prioritizingtqe577@signsnow.com Tue Jul 28 01:41:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678FC3A6DD4; Tue, 28 Jul 2009 01:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.69 X-Spam-Level: X-Spam-Status: No, score=-75.69 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_FAKE_RCVD_LINE_B=5.777, FH_RELAY_NODNS=1.451, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, 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 mfWFHbIvJsiA; Tue, 28 Jul 2009 01:41:38 -0700 (PDT) Received: from mail.majormail.com (unknown [216.224.28.131]) by core3.amsl.com (Postfix) with ESMTP id 61B2A3A6DCF; Tue, 28 Jul 2009 01:41:38 -0700 (PDT) Received: from 216.224.28.131 by mailgate.signsnow.com; Tue, 28 Jul 2009 04:41:21 -0500 Date: Tue, 28 Jul 2009 04:41:21 -0500 From: X-Mailer: The Bat! (v3.51) Home Reply-To: prioritizingtqe577@signsnow.com X-Priority: 3 (Normal) Message-ID: <624651026.43393635212314@signsnow.com> To: asrg-announce-request@ietf.org Subject: You have new message! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Web version | Forward | Edit profile | Add to contacts | Subscribe

Dear asrg-announce-request@ietf.org,

Welcome to the July issue.

If you unable to see this image, click
  here

Kind Regards,
Charles Jacobs

Subscribe | Privacy Statement | U nsubscribe
© 2009 iPharmacy Ltd, All rights reserved.
From owner-namedroppers@ops.ietf.org Tue Jul 28 02:31:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543EC3A6D27; Tue, 28 Jul 2009 02:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-0.943, 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 ZznXF3MJR8-8; Tue, 28 Jul 2009 02:31:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B5403A6E97; Tue, 28 Jul 2009 02:31:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MViuN-000B0z-B7 for namedroppers-data0@psg.com; Tue, 28 Jul 2009 09:23:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MViuE-000Azd-3l for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 09:23:37 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6S9NWHg036408 for ; Tue, 28 Jul 2009 05:23:32 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n6S9NWPX036407 for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 05:23:32 -0400 (EDT) (envelope-from namedroppers) Received: from [65.122.17.41] (helo=fledge.watson.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MViDM-0005re-LZ for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 08:39:18 +0000 Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n6S8dDxU048814; Tue, 28 Jul 2009 04:39:13 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n6S8dDsp048811; Tue, 28 Jul 2009 09:39:13 +0100 (BST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 28 Jul 2009 09:39:13 +0100 (BST) From: Samuel Weiler To: "Rose, Scott W." cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] -03 version of algo-signal posted In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Tue, 28 Jul 2009 09:39:13 +0100 (BST) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Sundry comments and questions, some of which repeat points already raised on this list. Generally: this appears to be a reasonable solution, but I'm not yet convinced this is a problem we need to solve. With going back to a list of codes (or a bitmap), why insist on ordering? I think private algorithms should be supported, at least to the granulatity of the type codes, if not looking deeper for the identifiers. Section 3: why is there a 2119 SHOULD? Why not let a client set algorithms beyond what the client understands? A clear reference to section 5 and explaining the differences v. "end system resolver" might be appropriate, since I'm not sure that term has occured before in the DNSSECbis doc set. Similarly, why not "MAY" set fewer than understood? In section 4, be clear that the DNSKEY RRset must not be broken up. Perhaps s/DNSSEC RRs/RRSIG RRs/ In section 5, "Caches ... when performing recursion on behalf of a stub client." How does a cache know whether its client is a stub? I think this phrase is a no-op and the instruction can be generalized. (Alternatively, the doc couold be restuctured, giving one set of resolver rules with a conditional clause...) "the cache SHOULD follow the AU option request and only include the RRSIGs generated using the algorithm equal to or less than the value in ALG-CODE." What does equal to or less than mean here? Again, having gone back to a list, how about removing the referring to ordering? 5.1 is there a standard definition for "intermediate proxy resolver"? If not, perhaps another term is more appropriate? Security considerations: "In these cases a client might be able to detect an attack if the target zone has a DS RR in its delegating parent with the desired algorithm." Wouldn't looking at both the DS and DNSKEY RRsets be more appropriate? The current text seems to have the potential to lead folks astray. It might be worthwhile to repeat the mandatory algorithm rules in this doc. -- 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 despatchedh@rosario.com Tue Jul 28 03:53:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99CE3A6BFB for ; Tue, 28 Jul 2009 03:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.928 X-Spam-Level: X-Spam-Status: No, score=-25.928 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_IP_220116=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR6Niem70cRU for ; Tue, 28 Jul 2009 03:53:43 -0700 (PDT) Received: from host39-129-dynamic.48-82-r.retail.telecomitalia.it (host39-129-dynamic.48-82-r.retail.telecomitalia.it [82.48.129.39]) by core3.amsl.com (Postfix) with ESMTP id 9294B3A6ABC for ; Tue, 28 Jul 2009 03:53:37 -0700 (PDT) Received: from [220.125.10.81] (account despatchedh@rosario.com HELO vrxvjtbfldvofur.rljifiwwi.su) by host39-129-dynamic.48-82-r.retail.telecomitalia.it (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 944205184 for dnsext-archive@lists.ietf.org; Tue, 28 Jul 2009 11:53:40 +0100 Date: Tue, 28 Jul 2009 11:53:40 +0100 From: gifts@core3.amsl.com, odnsext-archive@lists.ietf.org X-Mailer: The Bat! (v3.60.07) Professional X-Priority: 3 (Normal) Message-ID: <8949751028.06QEPGTR447707@ghyqazhlrkwk.pcmxdialkn.biz> To: dnsext-archive@lists.ietf.org Subject: Grant A. Stringer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://masssivewatches.net/ From militiasls854@ranchomv.com Tue Jul 28 06:17:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02BA33A6EE8; Tue, 28 Jul 2009 06:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.238 X-Spam-Level: X-Spam-Status: No, score=-67.238 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZgnum5BKtfx; Tue, 28 Jul 2009 06:17:48 -0700 (PDT) Received: from h226.223.55.139.static.ip.windstream.net (h226.223.55.139.static.ip.windstream.net [139.55.223.226]) by core3.amsl.com (Postfix) with ESMTP id 301093A6EFB; Tue, 28 Jul 2009 06:17:48 -0700 (PDT) Received: from 139.55.223.226 by smtp.ranchomv.com; Tue, 28 Jul 2009 07:17:03 -0600 Date: Tue, 28 Jul 2009 07:17:03 -0600 From: X-Mailer: The Bat! (v3.0) Professional Reply-To: militiasls854@ranchomv.com X-Priority: 3 (Normal) Message-ID: <066780490.46432112293753@ranchomv.com> To: agentx-request@ietf.org Subject: It boosts your rod! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address agentx-request@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
Drilling and drilling more, all night long! These pilules really work!
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address agentx-request@ietf.org has subscribed to the newsletter.

Stop future issues
From matthewspb82@isel-electronic.com Tue Jul 28 09:12:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAD03A6E25; Tue, 28 Jul 2009 09:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.382 X-Spam-Level: X-Spam-Status: No, score=-24.382 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FS_START_LOSE=1.493, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_RECV_VIRTUACOMBR=1.193, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXejFbI0YVmb; Tue, 28 Jul 2009 09:12:19 -0700 (PDT) Received: from c9535741.virtua.com.br (c9535741.virtua.com.br [201.83.87.65]) by core3.amsl.com (Postfix) with ESMTP id BE8D43A6E1F; Tue, 28 Jul 2009 09:12:18 -0700 (PDT) Received: from 201.83.87.65 by mail.nethinks.com; Tue, 28 Jul 2009 13:11:55 -0300 Date: Tue, 28 Jul 2009 13:11:55 -0300 Message-Id: From: Norman Lyon To: action@ietf.org Subject: Lose weight without starving yourself Acai Berry, get your trial Now. Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Immune system booster Acai Berry, get your free trial now.
don't let food be your greatest concern.
 
Thank You!
best regards Norman Lyon
From owner-namedroppers@ops.ietf.org Tue Jul 28 09:23:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B103A7102; Tue, 28 Jul 2009 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fazfZk7BTW+i; Tue, 28 Jul 2009 09:23:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A8A73A6919; Tue, 28 Jul 2009 09:23:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVpKi-000HHN-HX for namedroppers-data0@psg.com; Tue, 28 Jul 2009 16:15:20 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVpKe-000HGd-QT for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 16:15:18 +0000 Received: from crankycanuck.ca (host-78-64-88-217.homerun.telia.com [78.64.88.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0E36C2FE8ED5 for ; Tue, 28 Jul 2009 16:15:14 +0000 (UTC) Date: Tue, 28 Jul 2009 12:15:12 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] agenda updated Message-ID: <20090728161512.GK6181@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, I have just updated the agenda for tomorrow's DNSEXT meeting. We have moved the algorithm discussion to the end of the meeting, in order to allow people from the crypto community to join us in case they can wrap up another meeting early. As usual, the agenda is here: http://www.ietf.org/proceedings/75/agenda/dnsext.txt. It has version number 2009-07-28. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From adaaoh70@roundrocklaw.com Tue Jul 28 10:46:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CA13A6CD1; Tue, 28 Jul 2009 10:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.702 X-Spam-Level: X-Spam-Status: No, score=-23.702 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyjSAX5NtcQy; Tue, 28 Jul 2009 10:46:19 -0700 (PDT) Received: from c-75-64-32-58.hsd1.tn.comcast.net (c-75-64-32-58.hsd1.tn.comcast.net [75.64.32.58]) by core3.amsl.com (Postfix) with ESMTP id 8F0A63A6998; Tue, 28 Jul 2009 10:46:19 -0700 (PDT) Received: from 75.64.32.58 by roundrocklaw-com.relay1b.spamh.com; Tue, 28 Jul 2009 12:44:35 -0600 Date: Tue, 28 Jul 2009 12:44:35 -0600 From: X-Mailer: The Bat! (v3.71.04) Professional Reply-To: adaaoh70@roundrocklaw.com X-Priority: 3 (Normal) Message-ID: <490277029.08285612852605@roundrocklaw.com> To: bliss@ietf.org Subject: Power up your meat cigar MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address bliss@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
The solution for raising your rod's sensitivity.
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address bliss@ietf.org has subscribed to the newsletter.

Stop future issues
From owner-namedroppers@ops.ietf.org Tue Jul 28 10:55:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147223A6CED; Tue, 28 Jul 2009 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xV-LACxczkm; Tue, 28 Jul 2009 10:55:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 909C83A6C6C; Tue, 28 Jul 2009 10:55:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVqpT-0004h5-Sb for namedroppers-data0@psg.com; Tue, 28 Jul 2009 17:51:11 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVqpP-0004dn-20 for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 17:51:09 +0000 Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6SHoxT7011954 for ; Tue, 28 Jul 2009 13:50:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 28 Jul 2009 13:50:59 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Tue, 28 Jul 2009 13:50:57 -0400 Subject: Re: [dnsext] -03 version of algo-signal posted Thread-Topic: [dnsext] -03 version of algo-signal posted Thread-Index: AcoPXu8qtcDQjGkrQPe/jJzeG1snrQATQaTY Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7/28/09 4:39 AM, "Samuel Weiler" wrote: >=20 >=20 > With going back to a list of codes (or a bitmap), why insist on > ordering? >=20 I was thinking preference mainly. A way for clients to express which algos they would rather see. Not sure if it's necessary, but maybe. > I think private algorithms should be supported, at least to the > granulatity of the type codes, if not looking deeper for the > identifiers. >=20 > Section 3: why is there a 2119 SHOULD? Why not let a client set > algorithms beyond what the client understands? A clear reference to > section 5 and explaining the differences v. "end system resolver" > might be appropriate, since I'm not sure that term has occured before > in the DNSSECbis doc set. > > Similarly, why not "MAY" set fewer than understood? > We'll take that under consideration. Also, terminology has always been an issue here when describing roles. =20 > In section 4, be clear that the DNSKEY RRset must not be broken up. > Perhaps s/DNSSEC RRs/RRSIG RRs/ >=20 Ok - will add text. > In section 5, "Caches ... when performing recursion on behalf of a > stub client." How does a cache know whether its client is a stub? I > think this phrase is a no-op and the instruction can be generalized. > (Alternatively, the doc couold be restuctured, giving one set of > resolver rules with a conditional clause...) >=20 The only way would be to look for the RD bit. That is no guarantee. May adjust text around that instead of stub/full wording. > "the cache SHOULD follow the AU option request and only include the > RRSIGs generated using the algorithm equal to or less than the value > in ALG-CODE." > What does equal to or less than mean here? Again, having gone back to > a list, how about removing the referring to ordering? >=20 > 5.1 is there a standard definition for "intermediate proxy resolver"? > If not, perhaps another term is more appropriate? >=20 There has always been issues with terminology in DNS drafts. Will see if w= e can adjust role descriptions in this doc or just define everything better. Scott > Security considerations: "In these cases a client might be able to > detect an attack if the target zone has a DS RR in its delegating > parent with the desired algorithm." Wouldn't looking at both the DS > and DNSKEY RRsets be more appropriate? The current text seems to have > the potential to lead folks astray. It might be worthwhile to repeat > the mandatory algorithm rules in this doc. >=20 > -- Sam >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From exhortingb944@italbrand.com Tue Jul 28 12:11:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EA73A6C1B; Tue, 28 Jul 2009 12:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.291 X-Spam-Level: X-Spam-Status: No, score=-21.291 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_FR=0.35, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SXLIFE=1.07, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiAO64a2IhaO; Tue, 28 Jul 2009 12:11:34 -0700 (PDT) Received: from 212-198-52-4.rev.numericable.fr (212-198-52-4.rev.numericable.fr [212.198.52.4]) by core3.amsl.com (Postfix) with ESMTP id 562BF3A68E9; Tue, 28 Jul 2009 12:11:32 -0700 (PDT) Received: from 212.198.52.4 by italbrand.com; Tue, 28 Jul 2009 21:11:28 +0100 Message-ID: <000d01ca0fb7$35c9cd50$6400a8c0@exhortingb944> From: dnsext-archive@lists.ietf.org To: Subject: Want a BetterSex Life use AcaiBerry Date: Tue, 28 Jul 2009 21:11:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA0FB7.35C9CD50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA0FB7.35C9CD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lose weight feel great with Acai Berry.   Try a full bottle of Acai Berry for Free =20 click =20 best regards Beverly=20 Prescott =20 =20 ------=_NextPart_000_0007_01CA0FB7.35C9CD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Los= e weight feel great with Acai Berry.
&n= bsp;
Try a full bottle of Acai Berry for Free
<= A=20 href=3D"http://aisyjngo.cn">click
best regards Beverly=20 Prescott
------=_NextPart_000_0007_01CA0FB7.35C9CD50-- From owner-namedroppers@ops.ietf.org Tue Jul 28 13:04:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B238B3A67F9; Tue, 28 Jul 2009 13:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnqGhKiXS9ia; Tue, 28 Jul 2009 13:04:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDBF53A6877; Tue, 28 Jul 2009 13:04:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVsqH-0001i8-0D for namedroppers-data0@psg.com; Tue, 28 Jul 2009 20:00:09 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVsqC-0001hU-Mu for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 20:00:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A116E3A67F9; Tue, 28 Jul 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-rfc2671bis-edns0-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090728200001.A116E3A67F9@core3.amsl.com> Date: Tue, 28 Jul 2009 13:00:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Extension Mechanisms for DNS (EDNS0) Author(s) : M. Graff, P. Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-02.txt Pages : 11 Date : 2009-07-28 The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification based on 10 years of operational experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2671bis-edns0-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-28125422.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From flossing050@rconestop.com Tue Jul 28 16:11:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775893A6A1C; Tue, 28 Jul 2009 16:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.325 X-Spam-Level: X-Spam-Status: No, score=-72.325 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_URI_CONS8=1.036, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y40OfC2flE96; Tue, 28 Jul 2009 16:11:18 -0700 (PDT) Received: from dhcp-077-249-172-025.chello.nl (dhcp-077-249-172-025.chello.nl [77.249.172.25]) by core3.amsl.com (Postfix) with ESMTP id 3301D3A6904; Tue, 28 Jul 2009 16:11:18 -0700 (PDT) Received: from 77.249.172.25 by server85.appriver.com; Wed, 29 Jul 2009 01:09:59 +0100 Date: Wed, 29 Jul 2009 01:09:59 +0100 From: X-Mailer: The Bat! (v3.60.07) Home Reply-To: flossing050@rconestop.com X-Priority: 3 (Normal) Message-ID: <198199492.97206078212495@rconestop.com> To: agentx-request@ietf.org Subject: Load more in her slit! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address agentx-request@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
This one can raise your level and don't let it fall all night!
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address agentx-request@ietf.org has subscribed to the newsletter.

Stop future issues
From climes8@irishart.net Tue Jul 28 19:30:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28753A6D79; Tue, 28 Jul 2009 19:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.947 X-Spam-Level: X-Spam-Status: No, score=-25.947 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fS5CqXU9WFc; Tue, 28 Jul 2009 19:30:54 -0700 (PDT) Received: from pc-110-116-241-201.cm.vtr.net (pc-110-116-241-201.cm.vtr.net [201.241.116.110]) by core3.amsl.com (Postfix) with ESMTP id D9EF03A6D4B; Tue, 28 Jul 2009 19:30:53 -0700 (PDT) Received: from 201.241.116.110 by irishart.net; Tue, 28 Jul 2009 22:30:42 -0400 Content-type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Message-ID: Date: Tue, 28 Jul 2009 22:30:42 -0400 From: "Kerwin Leary" To: dix@ietf.org Subject: Amazing weight loss now you can get it FREE Enhance your life with the worlds # 1 Miracle food. Press the button http://aiawento.cn best regards Kerwin Leary From pulsateiju3@ir-forwarding.com Tue Jul 28 19:54:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0383A6D6C; Tue, 28 Jul 2009 19:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.164 X-Spam-Level: X-Spam-Status: No, score=-28.164 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-LHFrh5d52G; Tue, 28 Jul 2009 19:54:07 -0700 (PDT) Received: from c-98-238-132-148.hsd1.ca.comcast.net (c-98-238-132-148.hsd1.ca.comcast.net [98.238.132.148]) by core3.amsl.com (Postfix) with ESMTP id 0A7813A6CCC; Tue, 28 Jul 2009 19:54:05 -0700 (PDT) Received: from 98.238.132.148 by mail.ir-forwarding.com; Tue, 28 Jul 2009 19:54:06 -0800 Content-type: text/html; charset="us-ascii" MIME-Version: 1.0 Message-ID: Date: Tue, 28 Jul 2009 19:54:06 -0800 From: "Antoinet Ferreira" To: dnsext-archive@lists.ietf.org Subject: Hollywoods hottest secret , Acai Berry Diet. This is often called the corwn jewel of the amazon. Click http://aiawento.cn best regards Antoinet Ferreira From testifies6@stalmot.com Tue Jul 28 20:32:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A183A6D79; Tue, 28 Jul 2009 20:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.709 X-Spam-Level: X-Spam-Status: No, score=-78.709 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mhi7zj9pPgIp; Tue, 28 Jul 2009 20:32:48 -0700 (PDT) Received: from c-71-234-41-248.hsd1.ct.comcast.net (c-71-234-41-248.hsd1.ct.comcast.net [71.234.41.248]) by core3.amsl.com (Postfix) with ESMTP id F0DAD3A6D81; Tue, 28 Jul 2009 20:32:47 -0700 (PDT) Received: from 71.234.41.248 by mx2.stalmot.com; Tue, 28 Jul 2009 23:32:04 -0500 Date: Tue, 28 Jul 2009 23:32:04 -0500 From: X-Mailer: The Bat! (v3.51) Professional Reply-To: testifies6@stalmot.com X-Priority: 3 (Normal) Message-ID: <543129099.56825187482310@stalmot.com> To: dnsext-archive@ietf.org Subject: Being great is easy MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address dnsext-archive@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
Perfect solution for bored couples. Swallow one and get a burst of desire!
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address dnsext-archive@ietf.org has subscribed to the newsletter.

Stop future issues
From cleansge61@ritson-sole.com Tue Jul 28 22:56:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03B43A6B99; Tue, 28 Jul 2009 22:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.189 X-Spam-Level: X-Spam-Status: No, score=-12.189 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc9hUOpaXtin; Tue, 28 Jul 2009 22:56:27 -0700 (PDT) Received: from host-78-15-231-40.cust-adsl.tiscali.it (host-78-15-231-40.cust-adsl.tiscali.it [78.15.231.40]) by core3.amsl.com (Postfix) with ESMTP id 128FC3A6A45; Tue, 28 Jul 2009 22:56:25 -0700 (PDT) Received: from 78.15.231.40 by mailscanner.tera-byte.com; Wed, 29 Jul 2009 07:56:16 +0100 Date: Wed, 29 Jul 2009 07:56:16 +0100 From: X-Mailer: The Bat! (v3.81.14 Beta) Educational Reply-To: cleansge61@ritson-sole.com X-Priority: 3 (Normal) Message-ID: <314856166.65565164404327@ritson-sole.com> To: bliss@ietf.org Subject: Power up your meat cigar MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address bliss@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
The solution for raising your rod's sensitivity.
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address bliss@ietf.org has subscribed to the newsletter.

Stop future issues
From owner-namedroppers@ops.ietf.org Wed Jul 29 00:00:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D503A6907; Wed, 29 Jul 2009 00:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=-0.885, 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 RYj6CfW+pZMK; Wed, 29 Jul 2009 00:00:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 131733A6873; Wed, 29 Jul 2009 00:00:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW321-0002oB-07 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 06:52:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW31s-0002n4-Fm for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 06:52:55 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6T6qjJn049384 for ; Wed, 29 Jul 2009 02:52:45 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n6T6qjqb049383 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 02:52:45 -0400 (EDT) (envelope-from namedroppers) Received: from [69.64.72.227] (helo=step.reedcat.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MVjp7-000Iqk-R7 for namedroppers@ops.ietf.org; Tue, 28 Jul 2009 10:22:23 +0000 Received: from [130.129.70.234] (dhcp-46ea.meeting.ietf.org [130.129.70.234]) by step.reedcat.net (Postfix) with ESMTPA id 40ABF29563F; Tue, 28 Jul 2009 14:22:20 +0400 (MSD) Message-ID: <4A6ED15C.9080909@reedcat.net> Date: Tue, 28 Jul 2009 14:22:20 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Samuel Weiler CC: "Rose, Scott W." , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] -03 version of algo-signal posted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Samuel Weiler wrote: > > > With going back to a list of codes (or a bitmap), why insist on ordering? > Hope that is just the remnants in the text. And going to the bitmap ( "set" in Pascal terms or "enum" in C terms) in not "going back" it is "going the right way". ;) dol@ -- to unsubscribe send a message to namedroppers-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 Jul 29 00:39:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79FB13A6B99; Wed, 29 Jul 2009 00:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVRe-H+7i6d9; Wed, 29 Jul 2009 00:39:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1DDE3A6819; Wed, 29 Jul 2009 00:39:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW3hf-0007cm-7j for namedroppers-data0@psg.com; Wed, 29 Jul 2009 07:35:59 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW3hc-0007c9-2c for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 07:35:57 +0000 Received: from crankycanuck.ca (dhcp-44db.meeting.ietf.org [130.129.68.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 54F632FE8ED5 for ; Wed, 29 Jul 2009 07:35:52 +0000 (UTC) Date: Wed, 29 Jul 2009 03:35:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Report from the Chairs Message-ID: <20090729073545.GB8492@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, This is the report of the Chairs on WG progress. The idea is that we'll put this report on the list, and then we don't need to spend meeting time going over it. If you have specific issues with our report, please do feel free to bring them up during the allotted time in the meeting. Published drafts: RFC 5452 came out last January. That was before the San Francisco IETF, but DNSEXT didn't have a meeting there and your Chairs neglected to prepare this report at the time. Active drafts: * RFC Editor: draft-ietf-dnsext-dnsproxy * WG last call done: draft-ietf-dnsext-dnssec-rsasha256 To be sent to IESG with request to publish real soon now. draft-ietf-dnsext-rfc2672bis-dname Some issues raised in WGLC. The editors are addressing them. draft-ietf-dnsext-tsig-md5-deprecated Waiting for write-up from shepherd (Olafur). * In progress draft-ietf-dnsext-axfr-clarify Editor requested WGLC; shepherd (Andrew) sent it back to address intermingled discussion of IXFR. draft-ietf-dnsext-dnssec-bis-updates Editors asked recently for feedback on one open issue. draft-ietf-dnsext-rfc2671bis-edns0 New editor. A new version appeared just yesterday. Best regards, Olafur and Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From plucksp940@simcona.ca Wed Jul 29 03:11:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C432F3A6EF1; Wed, 29 Jul 2009 03:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.91 X-Spam-Level: X-Spam-Status: No, score=-76.91 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ub+0xW1pPcM; Wed, 29 Jul 2009 03:11:06 -0700 (PDT) Received: from CPE-121-208-49-55.qld.bigpond.net.au (CPE-121-208-49-55.qld.bigpond.net.au [121.208.49.55]) by core3.amsl.com (Postfix) with ESMTP id A6D903A6F38; Wed, 29 Jul 2009 03:11:05 -0700 (PDT) Received: from 121.208.49.55 by mail.simcona.ca; Wed, 29 Jul 2009 20:10:21 +1000 Date: Wed, 29 Jul 2009 20:10:21 +1000 From: X-Mailer: The Bat! (v3.62.14) Home Reply-To: plucksp940@simcona.ca X-Priority: 3 (Normal) Message-ID: <489744688.60535406542732@simcona.ca> To: dnsext-archive@ietf.org Subject: Attack slits more! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address dnsext-archive@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
If night are not hot enough, this pilule will light the fire again!
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address dnsext-archive@ietf.org has subscribed to the newsletter.

Stop future issues
From eviscerationxt24@relationbrand.com Wed Jul 29 04:01:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC1A3A69ED; Wed, 29 Jul 2009 04:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.401 X-Spam-Level: X-Spam-Status: No, score=-74.401 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrCf-4-SJN16; Wed, 29 Jul 2009 04:01:09 -0700 (PDT) Received: from 77-253-51-82.adsl.inetia.pl (77-253-51-82.adsl.inetia.pl [77.253.51.82]) by core3.amsl.com (Postfix) with ESMTP id 32D733A684C; Wed, 29 Jul 2009 04:01:07 -0700 (PDT) Received: from 77.253.51.82 by mail-7.relationbrand.com; Wed, 29 Jul 2009 13:00:45 +0100 Date: Wed, 29 Jul 2009 13:00:45 +0100 From: X-Mailer: The Bat! (v3.5) Educational Reply-To: eviscerationxt24@relationbrand.com X-Priority: 3 (Normal) Message-ID: <049000870.64836251507415@relationbrand.com> To: dccp-owner@ietf.org Subject: It boosts your rod! MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
You are receiving this email because the email address dccp-owner@ietf.org was subscribed to the weekly newsletter. Having trouble reading this page? View it on our website.
Weekly Tips for YOU
Aging is no more a problem for your manhood activities. Chemical answer to bedroom problems.
Share This Newsletter
If you know who may be interested in receiving this guide, please forward it to them.
You are receiving this email because the email address dccp-owner@ietf.org has subscribed to the newsletter.

Stop future issues
From owner-namedroppers@ops.ietf.org Wed Jul 29 05:35:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0053D3A684C; Wed, 29 Jul 2009 05:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWsLszJl4-nb; Wed, 29 Jul 2009 05:35:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F12F43A6A15; Wed, 29 Jul 2009 05:35:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8Gn-0003ki-D1 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 12:28:33 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8Gi-0003k7-L5 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 12:28:30 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n6TCSQ0j058615 for ; Wed, 29 Jul 2009 14:28:27 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200907291228.n6TCSQ0j058615@givry.fdupont.fr> From: Francis Dupont To: namedroppers@ops.ietf.org Subject: [dnsext] DNS64 and lying cache servers Date: Wed, 29 Jul 2009 14:28:26 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [Please forward this to the behave mailing-list] [I use the term "cache server" as a synonym of "recursive DNS server"] DNS64 (draft-ietf-behave-dns64-00.txt) is usually presented with a cache server serving a lot of NAT64 IPv6-only clients and performing AAAA RR synthesis from A RRs to make external IPv4-only servers reachable through a NAT64 translator. So this is essentially a lying cache server: this is *bad* for the usual reason (it breaks DNSSEC). Worse, its lie is very location dependent, so it has very bad interaction when the DNS is assumed to be location independent, for instance with Mobility. But as explained in the draft at the end of the section 2 Overview this is not the only way to deploy DNS64: in the "DNS64 in stub- resolver mode" the synthesis is done as close as possible to the client so there is no longer lying issues. Note this doesn't extend to some other lying DNS proposals from NAT based IPv6/IPv4 transition mechanisms because DNS64 uses a small set of static parameters (mainly the Pref64::/n) which is the only state of the synthesis process. So I recommend the DNSEXT WG to advise to put more work into the sub-resolver mode (producing DNS64 capable stub-resolvers, which should be very easy, and solving the DNS64 parameter distribution issue) than into the DNS server mode which should be recognized as an example of a false good idea. Regards Francis.Dupont@fdupont.fr PS: Acknowledgments to Mark Andrews who introduced the strong but correct "lying" term, and to Wassim Haddad who remarked DNS64 and Mobility together can easily lead to disasters. -- to unsubscribe send a message to namedroppers-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 Jul 29 06:01:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457303A7081; Wed, 29 Jul 2009 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRwKjTrs02vU; Wed, 29 Jul 2009 06:01:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76A2C3A707B; Wed, 29 Jul 2009 06:01:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8gY-0007mo-SD for namedroppers-data0@psg.com; Wed, 29 Jul 2009 12:55:10 +0000 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8gT-0007k2-HU for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 12:55:08 +0000 Received: from khazad-dum.hactrn.net (dhcp-13fe.meeting.ietf.org [130.129.19.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id B3E8A28433 for ; Wed, 29 Jul 2009 12:55:03 +0000 (UTC) Received: from khazad-dum.hactrn.net (localhost [IPv6:::1]) by khazad-dum.hactrn.net (Postfix) with ESMTP id C9A697358A for ; Wed, 29 Jul 2009 12:55:01 +0000 (UTC) Date: Wed, 29 Jul 2009 14:55:01 +0200 From: Rob Austein To: namedroppers@ops.ietf.org Subject: [dnsext] Signing the root with SHA-1 or SHA-2 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [Continuation of Stockholm WG session, cut off due to lack of time] My concern with the proposal to sign the root just with SHA-2 is that it will be years before enough of the installed base has SHA-2-capable DNSSEC in production. Even ignoring vendors with long development cycles, mainstream operators don't upgrade quickly. We're talking years here, not months. I think the suggestion that we start with SHA-1 then roll to SHA-2 makes a fair amount of sense. If algorithm roll at the root really is that scary, we should not wait until an emergency to try 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 Wed Jul 29 06:12:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE8E3A6B24; Wed, 29 Jul 2009 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=-1.773, 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 Zz6pwtG1kz1i; Wed, 29 Jul 2009 06:12:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC3893A684C; Wed, 29 Jul 2009 06:12:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8t8-000AfI-06 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:08:10 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8t2-000Ac1-3w for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:08:08 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANXmb0qrR7PD/2dsb2JhbAC7R4gnkDsFhBE X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="sig'?scan'208";a="220699202" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2009 13:08:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6TD832o016469; Wed, 29 Jul 2009 06:08:03 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6TD7oqF005942; Wed, 29 Jul 2009 13:08:03 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:07:58 +0200 Received: from dhcp-17cb.meeting.ietf.org ([10.61.102.143]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 15:07:57 +0200 Cc: namedroppers@ops.ietf.org Message-Id: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Rob Austein In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-56--17263300" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 15:07:56 +0200 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 13:07:57.0950 (UTC) FILETIME=[97D7A9E0:01CA104D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1689; t=1248872883; x=1249736883; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dnsext]=20Signing=20the=20root=20with= 20SHA-1=20or=20SHA-2 |Sender:=20; bh=4ush+yhz2Cp6BAZ/TPtSWO+ya6mrsM9koknAAbOudiQ=; b=uhOVFV9LsY++wfDI/LVMT8tE5dFXu1nmTRCsX971k/w3n1UQ7bweMnpZ2C rYauAwcHN65vrDd/5MHl9AXrE3IxrffmPfAFUXYt6jOLj82HDPqDaOkHDq4L HlGV89py3I; Authentication-Results: sj-dkim-3; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-56--17263300 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 29 jul 2009, at 14.55, Rob Austein wrote: > [Continuation of Stockholm WG session, cut off due to lack of time] > > My concern with the proposal to sign the root just with SHA-2 is that > it will be years before enough of the installed base has SHA-2-capable > DNSSEC in production. Even ignoring vendors with long development > cycles, mainstream operators don't upgrade quickly. We're talking > years here, not months. > > I think the suggestion that we start with SHA-1 then roll to SHA-2 > makes a fair amount of sense. If algorithm roll at the root really is > that scary, we should not wait until an emergency to try it. FWIW: This makes sense to me. What we do need is, for pure interoperability reasons, _one_ algorithm that is "the algorithm that is in use", and then a mechanism for rollover algorithms when needed. I would argue strongly against mechanisms that enable what would be a terrible tragedy of the commons, which would be simultaneously use of unlimited number of algorithms. paf --Apple-Mail-56--17263300 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) iD8DBQFKcEmsvHlR2X0luNwRAkB8AKC1+PcH7136vFML5XfCG8LpDnS25wCg3vG3 7deZjy7jrPkBuSCiozlPV2k= =T/st -----END PGP SIGNATURE----- --Apple-Mail-56--17263300-- -- to unsubscribe send a message to namedroppers-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 Jul 29 06:12:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5F53A69BA; Wed, 29 Jul 2009 06:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 ngPllw7iarlW; Wed, 29 Jul 2009 06:12:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA7A53A684C; Wed, 29 Jul 2009 06:12:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8uR-000AvX-BQ for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:09:31 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW8uK-000Ato-Od for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:09:28 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MW8zC-0000OV-Vp; Wed, 29 Jul 2009 15:14:26 +0200 Received: by bfk.de with local id 1MW8uI-0000aJ-QH; Wed, 29 Jul 2009 13:09:22 +0000 To: Francis Dupont Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS64 and lying cache servers References: <200907291228.n6TCSQ0j058615@givry.fdupont.fr> From: Florian Weimer Date: Wed, 29 Jul 2009 13:09:22 +0000 In-Reply-To: <200907291228.n6TCSQ0j058615@givry.fdupont.fr> (Francis Dupont's message of "Wed\, 29 Jul 2009 14\:28\:26 +0200") Message-ID: <82iqhbiqkd.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: * Francis Dupont: > So I recommend the DNSEXT WG to advise to put more work into > the sub-resolver mode (producing DNS64 capable stub-resolvers, > which should be very easy, and solving the DNS64 parameter > distribution issue) than into the DNS server mode which should be > recognized as an example of a false good idea. Stub behavior is out of the scope of the DNSEXT and DNSOP WGs, see the discussions about address selection. And DNS64 appears to be just another form of address selection. --=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 Jul 29 06:27:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335613A6FFC; Wed, 29 Jul 2009 06:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.027 X-Spam-Level: * X-Spam-Status: No, score=1.027 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 MnO7CHLeqOkf; Wed, 29 Jul 2009 06:27:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 569E23A6F81; Wed, 29 Jul 2009 06:27:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW98t-000EI7-4b for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:24:27 +0000 Received: from [209.85.220.222] (helo=mail-fx0-f222.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW98p-000EHN-Jq for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:24:25 +0000 Received: by fxm22 with SMTP id 22so748608fxm.41 for ; Wed, 29 Jul 2009 06:24:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.15 with SMTP id d15mr4285569fap.105.1248873862141; Wed, 29 Jul 2009 06:24:22 -0700 (PDT) In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Wed, 29 Jul 2009 13:24:02 +0000 Message-ID: Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Is there a possibility to sign with BOTH? SHA-1 and SHA-256? Ondrej. On Wed, Jul 29, 2009 at 12:55 PM, Rob Austein wrote: > [Continuation of Stockholm WG session, cut off due to lack of time] > > My concern with the proposal to sign the root just with SHA-2 is that > it will be years before enough of the installed base has SHA-2-capable > DNSSEC in production. =C2=A0Even ignoring vendors with long development > cycles, mainstream operators don't upgrade quickly. =C2=A0 We're talking > years here, not months. > > I think the suggestion that we start with SHA-1 then roll to SHA-2 > makes a fair amount of sense. =C2=A0If algorithm roll at the root really = is > that scary, we should not wait until an emergency to try 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: > --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 06:36:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0836E3A708A; Wed, 29 Jul 2009 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLisDOyo4bzW; Wed, 29 Jul 2009 06:36:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D43223A7083; Wed, 29 Jul 2009 06:35:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9GK-000G2R-IB for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:32:08 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9GH-000G0u-3Y for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:32:06 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 074CC95899; Wed, 29 Jul 2009 10:32:04 -0300 (BRT) Date: Wed, 29 Jul 2009 10:32:03 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090729133203.GA87506@registro.br> Mail-Followup-To: Frederico A C Neves , namedroppers@ops.ietf.org References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 02:55:01PM +0200, Rob Austein wrote: > [Continuation of Stockholm WG session, cut off due to lack of time] > > My concern with the proposal to sign the root just with SHA-2 is that > it will be years before enough of the installed base has SHA-2-capable > DNSSEC in production. Even ignoring vendors with long development > cycles, mainstream operators don't upgrade quickly. We're talking > years here, not months. > > I think the suggestion that we start with SHA-1 then roll to SHA-2 > makes a fair amount of sense. If algorithm roll at the root really is > that scary, we should not wait until an emergency to try it. I'm with Rob. Besides the advantages of testing the roll I would really not like to depend on a not completely specified and deployed algorithm for initial 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 Wed Jul 29 06:36:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CF23A7011; Wed, 29 Jul 2009 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV5KCjQ-hLTo; Wed, 29 Jul 2009 06:36:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A19F3A6912; Wed, 29 Jul 2009 06:36:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9I6-000GSg-P2 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:33:58 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9I2-000GRN-Fz for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:33:56 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 4E88E95888; Wed, 29 Jul 2009 10:33:53 -0300 (BRT) Date: Wed, 29 Jul 2009 10:33:53 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090729133353.GB87506@registro.br> Mail-Followup-To: Frederico A C Neves , namedroppers@ops.ietf.org References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 01:24:02PM +0000, Ond??ej Surý wrote: > Is there a possibility to sign with BOTH? SHA-1 and SHA-256? If the roots don't fear the TCP traffic. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 06:49:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062593A685F; Wed, 29 Jul 2009 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7HknsWoXayj; Wed, 29 Jul 2009 06:49:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B44263A6E94; Wed, 29 Jul 2009 06:49:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9Tt-000J2V-1M for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:46:09 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9To-000J10-9Z for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:46:06 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n6TDk1tP059208; Wed, 29 Jul 2009 15:46:01 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200907291346.n6TDk1tP059208@givry.fdupont.fr> From: Francis Dupont To: Florian Weimer cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS64 and lying cache servers In-reply-to: Your message of Wed, 29 Jul 2009 13:09:22 -0000. <82iqhbiqkd.fsf@mid.bfk.de> Date: Wed, 29 Jul 2009 15:46:01 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: * Francis Dupont: Stub behavior is out of the scope of the DNSEXT and DNSOP WGs, see the discussions about address selection. And DNS64 appears to be just another form of address selection. => no, DNS64 is about AAAA RR synthesis from A RRs when there is no AAAA, this is fully orthogonal to address selection (which is no more in the BEHAVE WG charter than in DNS* WGs'). To summary there are two possible places where to perform the synthesis, my concern is about to do at the right place and not at the place which seems easy. Regards Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 06:50:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFA93A6F6A; Wed, 29 Jul 2009 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcrV+Uul1CL4; Wed, 29 Jul 2009 06:50:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D2B53A6BD4; Wed, 29 Jul 2009 06:50:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9Vu-000JUj-5a for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:48:14 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9Vo-000JSM-I3 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:48:12 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 31ACE50C4C; Wed, 29 Jul 2009 14:48:07 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: From: Jim Reid To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 14:48:06 +0100 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 29 Jul 2009, at 14:24, Ond=C5=99ej Sur=C3=BD wrote: > Is there a possibility to sign with BOTH? SHA-1 and SHA-256? What should the validator do if the SHA-1 signature turns out to be =20 invalid but the SHA-256 one was OK? Or vice versa? Would/should there =20= be a priority order/preference for validators to pick from when =20 choosing between multiple RRSIGs which each have different hash =20 algorithms? [Evil thought: perhaps the hash algorithm identifier =20 should be a field in the RRSIG rather than the DNSKEY.....] I tend to =20= agree with Patrik's suggestion that there should be One True Hash =20 algorithm and a mechanism for replacing that when necessary. Hopefully =20= there will be plenty of notice before a new hash algorithm would need =20= to be introduced, implemented and deployed. I'm not sure if that would =20= be a wise assumption however.= -- to unsubscribe send a message to namedroppers-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 Jul 29 06:51:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F8F3A6BD4; Wed, 29 Jul 2009 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAmUzNzQIkTz; Wed, 29 Jul 2009 06:51:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48B613A6903; Wed, 29 Jul 2009 06:51:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9UB-000J5J-Us for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:46:27 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9U8-000J4v-LA for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:46:26 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TDkIP9004725; Wed, 29 Jul 2009 06:46:18 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Rob Austein In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 06:46:18 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 5:55 AM, Rob Austein wrote: > [Continuation of Stockholm WG session, cut off due to lack of time] > > My concern with the proposal to sign the root just with SHA-2 is that > it will be years before enough of the installed base has SHA-2-capable > DNSSEC in production. Even ignoring vendors with long development > cycles, mainstream operators don't upgrade quickly. We're talking > years here, not months. > > I think the suggestion that we start with SHA-1 then roll to SHA-2 > makes a fair amount of sense. If algorithm roll at the root really is > that scary, we should not wait until an emergency to try it. I STRONGLY disagree. Crypto only gets weaker, never stronger, and it can get very SUDDENLY weaker. The cracks are REALLY showing in SHA-1. Resolvers need an update anyway in order to handle a signed root, if only the key itself. Thus I believe it is critical to start with SHA-2. Signing BOTH ways doesn't solve the problem, either: you then become vulnerable to downgrade attacks and similar problems. -- to unsubscribe send a message to namedroppers-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 Jul 29 07:00:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6F43A70D6; Wed, 29 Jul 2009 07:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[AWL=0.654, 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 VKba+MpkOFaY; Wed, 29 Jul 2009 07:00:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D61E3A70B8; Wed, 29 Jul 2009 07:00:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9f7-000Mfu-4v for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:57:45 +0000 Received: from [192.36.115.43] (helo=paka.besserwisser.org) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9f3-000Mem-Fz for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:57:43 +0000 Received: from paka.besserwisser.org (localhost [127.0.0.1]) by paka.besserwisser.org (8.13.8+Sun/8.13.7) with ESMTP id n6TDvTiH006748; Wed, 29 Jul 2009 15:57:29 +0200 (CEST) Received: (from mansaxel@localhost) by paka.besserwisser.org (8.13.8+Sun/8.13.7/Submit) id n6TDvT9u006747; Wed, 29 Jul 2009 15:57:29 +0200 (CEST) Date: Wed, 29 Jul 2009 15:57:29 +0200 From: Mans Nilsson To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090729135729.GI10901@besserwisser.org> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.19 (2009-01-05) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Subject: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, Jul 29, 2009 at 02:55:01PM +0200 Quoting Rob Austein (sra@isc.org): > [Continuation of Stockholm WG session, cut off due to lack of time] > > My concern with the proposal to sign the root just with SHA-2 is that > it will be years before enough of the installed base has SHA-2-capable > DNSSEC in production. Even ignoring vendors with long development > cycles, mainstream operators don't upgrade quickly. We're talking > years here, not months. On the other hand, the installed base of validating resolvers at this point in time is not yet forgotten by those that installed them. And everybody just upgraded BIND anyway. (not to a SHA-256 compatible release, but that is only marginally relevant; it is the practice that counts.) > I think the suggestion that we start with SHA-1 then roll to SHA-2 > makes a fair amount of sense. If algorithm roll at the root really is > that scary, we should not wait until an emergency to try it. This is IMHO a more valid argument; but the notion of "they are not done yet" as was mentioned in the meeting is a dire threat; probably as much of a delay to adoption as would "lack of SHA-256 capable resolvers" would be. SHA-256 for first root key is a good start. A planned rollover after 2 years or so would address the need to do rollover in a controlled way. The only thing we'd lose with rollover 256>256 would be the algorithm roll. But I firmly believe that getting people to roll is the hard part. Once you get "must roll key" into peoples to-do list, the fact that the key algorithm changes as well is just a minor detail. -- MÃ¥ns Nilsson -- to unsubscribe send a message to namedroppers-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 Jul 29 07:01:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EB63A70E0; Wed, 29 Jul 2009 07:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=0.327, 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 kVu6Amzdlok9; Wed, 29 Jul 2009 07:01:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0E493A69E5; Wed, 29 Jul 2009 07:01:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9g5-000MuN-Cv for namedroppers-data0@psg.com; Wed, 29 Jul 2009 13:58:45 +0000 Received: from [192.36.115.43] (helo=paka.besserwisser.org) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9g1-000Mst-AF for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 13:58:43 +0000 Received: from paka.besserwisser.org (localhost [127.0.0.1]) by paka.besserwisser.org (8.13.8+Sun/8.13.7) with ESMTP id n6TDwd4k006821; Wed, 29 Jul 2009 15:58:39 +0200 (CEST) Received: (from mansaxel@localhost) by paka.besserwisser.org (8.13.8+Sun/8.13.7/Submit) id n6TDwdVK006820; Wed, 29 Jul 2009 15:58:39 +0200 (CEST) Date: Wed, 29 Jul 2009 15:58:39 +0200 From: Mans Nilsson To: Frederico A C Neves , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090729135839.GJ10901@besserwisser.org> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <20090729133353.GB87506@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090729133353.GB87506@registro.br> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.19 (2009-01-05) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, Jul 29, 2009 at 10:33:53AM -0300 Quoting Frederico A C Neves (fneves@registro.br): > On Wed, Jul 29, 2009 at 01:24:02PM +0000, Ond??ej Surý wrote: > > Is there a possibility to sign with BOTH? SHA-1 and SHA-256? > > If the roots don't fear the TCP traffic. Any resolver doing DNSSEC also does EDNS0. -- MÃ¥ns Nilsson -- to unsubscribe send a message to namedroppers-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 Jul 29 07:07:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECAC3A70D8; Wed, 29 Jul 2009 07:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXUa7FcpPbDe; Wed, 29 Jul 2009 07:07:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E38F83A70B3; Wed, 29 Jul 2009 07:07:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9ls-000OUd-HG for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:04:44 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9ln-000OSn-Dk for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:04:42 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MW9qe-0007fy-3F; Wed, 29 Jul 2009 16:09:40 +0200 Received: by bfk.de with local id 1MW9lj-0003iY-I6; Wed, 29 Jul 2009 14:04:35 +0000 To: Nicholas Weaver Cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> From: Florian Weimer Date: Wed, 29 Jul 2009 14:04:35 +0000 In-Reply-To: (Nicholas Weaver's message of "Wed\, 29 Jul 2009 06\:46\:18 -0700") Message-ID: <827hxrio0c.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Nicholas Weaver: > Resolvers need an update anyway in order to handle a signed > root, if only the key itself. Thus I believe it is critical to start > with SHA-2. SHA-2 support implies NSEC3 support, so this is certainly not a simple key installation or cryptographic algorithm update for most operators. --=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 Jul 29 07:07:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060F13A70E1; Wed, 29 Jul 2009 07:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=3.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7feIY7PqtLS; Wed, 29 Jul 2009 07:07:53 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3B6513A70B3; Wed, 29 Jul 2009 07:07:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9mu-000Ok8-Ew for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:05:48 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9mr-000OjC-0j for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:05:46 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1MW9rj-0007qN-LG; Wed, 29 Jul 2009 16:10:47 +0200 Received: by bfk.de with local id 1MW9mp-0004Wo-9u; Wed, 29 Jul 2009 14:05:43 +0000 To: Francis Dupont Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS64 and lying cache servers References: <200907291346.n6TDk1tP059208@givry.fdupont.fr> From: Florian Weimer Date: Wed, 29 Jul 2009 14:05:43 +0000 In-Reply-To: <200907291346.n6TDk1tP059208@givry.fdupont.fr> (Francis Dupont's message of "Wed\, 29 Jul 2009 15\:46\:01 +0200") Message-ID: <8263dbinyg.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: * Francis Dupont: > In your previous mail you wrote: > > * Francis Dupont: >=20=20=20=20 > Stub behavior is out of the scope of the DNSEXT and DNSOP WGs, see the > discussions about address selection. And DNS64 appears to be just > another form of address selection. >=20=20=20=20 > =3D> no, DNS64 is about AAAA RR synthesis from A RRs when there is no AAA= A, > this is fully orthogonal to address selection (which is no more in > the BEHAVE WG charter than in DNS* WGs'). Address selection is about suppressing address records so that they are never used by the application (unless special conditions, like unreachable servers, are met). > To summary there are two possible places where to perform the synthesis, > my concern is about to do at the right place and not at the place which > seems easy. The right place is inside the stub (or in close cooperation with the stub), and that seems to be out of scope to me, based on prior discussions. (It also suffers from the "not b****y likely" problem because as I understand it, BEHAVE aims at not requiring far-reaching client-side changes.) --=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 Jul 29 07:07:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920153A70B3; Wed, 29 Jul 2009 07:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZcbwIfQAjkw; Wed, 29 Jul 2009 07:07:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F1383A70D8; Wed, 29 Jul 2009 07:07:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9mq-000OjI-Bo for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:05:44 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9mm-000OiA-DK for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:05:42 +0000 Received: from [IPv6:2001:df8:0:16:222:43ff:fe24:8028] ([IPv6:2001:df8:0:16:222:43ff:fe24:8028]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6TE5Xni003879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 16:05:34 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A70572D.2070403@NLnetLabs.nl> Date: Wed, 29 Jul 2009 16:05:33 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Jim Reid CC: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 29 Jul 2009 16:05:35 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Reid wrote: > On 29 Jul 2009, at 14:24, OndÅ™ej Surý wrote: > >> Is there a possibility to sign with BOTH? SHA-1 and SHA-256? > > What should the validator do if the SHA-1 signature turns out to be > invalid but the SHA-256 one was OK? Or vice versa? Would/should there be > a priority order/preference for validators to pick from when choosing > between multiple RRSIGs which each have different hash algorithms? [Evil i tried to get something like that in an earlier version of the sha2 draft, but it got voted out; currently if one or more of the signatures seems correct, the rrset is marked as ok, according to 4034. > implemented and deployed. I'm not sure if that would be a wise > assumption however. if anyone knows another implementation of the draft (preferably a non-openssl one), please let me know :) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpwVyUACgkQ4nZCKsdOncXf5wCgrx4zeHpRZ9M2v2OLnZR+6JBu KxgAn19HBPHc+OP8UEASHZvwH2Xy80X7 =zVf8 -----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 Jul 29 07:12:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5C53A70CF; Wed, 29 Jul 2009 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.436 X-Spam-Level: X-Spam-Status: No, score=-5.436 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czHEKj3mSgYR; Wed, 29 Jul 2009 07:12:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA2653A70E5; Wed, 29 Jul 2009 07:12:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9qt-000PXe-Lm for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:09:55 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9qo-000PWd-HH for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:09:52 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TE9ahe006189; Wed, 29 Jul 2009 07:09:37 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Jim Reid In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 07:09:36 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 6:48 AM, Jim Reid wrote: > On 29 Jul 2009, at 14:24, Ond=C5=99ej Sur=C3=BD wrote: > >> Is there a possibility to sign with BOTH? SHA-1 and SHA-256? > > What should the validator do if the SHA-1 signature turns out to be =20= > invalid but the SHA-256 one was OK? Or vice versa? Would/should =20 > there be a priority order/preference for validators to pick from =20 > when choosing between multiple RRSIGs which each have different hash =20= > algorithms? [Evil thought: perhaps the hash algorithm identifier =20 > should be a field in the RRSIG rather than the DNSKEY.....] I tend =20 > to agree with Patrik's suggestion that there should be One True Hash =20= > algorithm and a mechanism for replacing that when necessary. =20 > Hopefully there will be plenty of notice before a new hash algorithm =20= > would need to be introduced, implemented and deployed. I'm not sure =20= > if that would be a wise assumption however. Remember, also, the attitude of "yeah, its cracks are showing but its =20= not broken yet from our viewpoint, its just collision attacks" had =20 root cert vendors continuing to use MD5: http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt That didn't work out very well... So to ease deployment on those unwilling or unable to update their =20 codebase to NSEC3/SHA-256, the solution is to put a potential time-=20 bomb into the root 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 Jul 29 07:17:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EF63A703C; Wed, 29 Jul 2009 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIs7WwSg1-D8; Wed, 29 Jul 2009 07:17:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D6273A6814; Wed, 29 Jul 2009 07:17:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9vN-0000P2-C4 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:14:33 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MW9vI-0000Nv-KM for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:14:31 +0000 Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6TEEWer015586 for ; Wed, 29 Jul 2009 10:14:32 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Wed, 29 Jul 2009 10:14:20 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Wed, 29 Jul 2009 10:14:19 -0400 Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Thread-Topic: [dnsext] Signing the root with SHA-1 or SHA-2 Thread-Index: AcoQTsjizay6kLAnTG6cIXitNsl6ugACBPa7 Message-ID: In-Reply-To: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7/29/09 9:07 AM, "Patrik Faltstrom" wrote: >>=20 >> I think the suggestion that we start with SHA-1 then roll to SHA-2 >> makes a fair amount of sense. If algorithm roll at the root really is >> that scary, we should not wait until an emergency to try it. >=20 > FWIW: This makes sense to me. >=20 > What we do need is, for pure interoperability reasons, _one_ algorithm > that is "the algorithm that is in use", and then a mechanism for > rollover algorithms when needed. >=20 I would agree with this, but different groups have opinions about what should be "the" algorithm in use. That will hamper DNSSEC deployment in some areas. If that can be worked out to one agreed upon algorithm, I'd be very happy. ;-) =20 Scott > I would argue strongly against mechanisms that enable what would be a > terrible tragedy of the commons, which would be simultaneously use of > unlimited number of algorithms. >=20 > paf >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 07:24:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEADA3A6810; Wed, 29 Jul 2009 07:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+A7XPma7CPg; Wed, 29 Jul 2009 07:24:21 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 34F933A69D8; Wed, 29 Jul 2009 07:24:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWA0u-0001KI-B5 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:20:16 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWA0q-0001JO-A7 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:20:14 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 44ACD95873; Wed, 29 Jul 2009 11:20:11 -0300 (BRT) Date: Wed, 29 Jul 2009 11:20:11 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090729142011.GC87506@registro.br> Mail-Followup-To: Frederico A C Neves , namedroppers@ops.ietf.org References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <20090729133353.GB87506@registro.br> <20090729135839.GJ10901@besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090729135839.GJ10901@besserwisser.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 03:58:39PM +0200, Mans Nilsson wrote: > Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, Jul 29, 2009 at 10:33:53AM -0300 Quoting Frederico A C Neves (fneves@registro.br): > > On Wed, Jul 29, 2009 at 01:24:02PM +0000, Ond??ej Surý wrote: > > > Is there a possibility to sign with BOTH? SHA-1 and SHA-256? > > > > If the roots don't fear the TCP traffic. > > Any resolver doing DNSSEC also does EDNS0. Sing a popular zone with 2 KSKs + 2 spare KSKs + 2 ZSKs (6 keys + 4 sigs to the keyset and 2 sigs for the other rrsets) and get back to us with the traffic results. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 07:34:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616883A6E03; Wed, 29 Jul 2009 07:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz31e2nFXBp1; Wed, 29 Jul 2009 07:34:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 482463A6D46; Wed, 29 Jul 2009 07:34:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWABY-000321-LT for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:31:16 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWABU-00031e-L3 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:31:14 +0000 Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:16:216:6fff:fe46:b75d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D09E6E601C; Wed, 29 Jul 2009 14:31:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6TEV8hP066648; Thu, 30 Jul 2009 00:31:08 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907291431.n6TEV8hP066648@drugs.dv.isc.org> To: Florian Weimer Cc: Nicholas Weaver , Rob Austein , namedroppers@ops.ietf.org From: Mark Andrews References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <827hxrio0c.fsf@mid.bfk.de> Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-reply-to: Your message of "Wed, 29 Jul 2009 14:04:35 GMT." <827hxrio0c.fsf@mid.bfk.de> Date: Thu, 30 Jul 2009 00:31:08 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <827hxrio0c.fsf@mid.bfk.de>, Florian Weimer writes: > * Nicholas Weaver: > > > Resolvers need an update anyway in order to handle a signed > > root, if only the key itself. Thus I believe it is critical to start > > with SHA-2. > > SHA-2 support implies NSEC3 support, so this is certainly not a simple > key installation or cryptographic algorithm update for most operators. It is for those with NSEC3 support. :-) Seriously if you are DNSSEC player you will have or get NSEC3 support RSN. Too many high level zones use NSEC3 for developers to avoid it. > > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 07:40:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F37C3A6BD8; Wed, 29 Jul 2009 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx6M4vftM67I; Wed, 29 Jul 2009 07:40:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 038823A6830; Wed, 29 Jul 2009 07:40:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAEd-0003es-01 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:34:27 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAEY-0003e9-Ow for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:34:24 +0000 Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:16:216:6fff:fe46:b75d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F2D87E609D; Wed, 29 Jul 2009 14:34:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6TEYJMC006643; Thu, 30 Jul 2009 00:34:19 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907291434.n6TEYJMC006643@drugs.dv.isc.org> To: Jim Reid Cc: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , namedroppers@ops.ietf.org From: Mark Andrews References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-reply-to: Your message of "Wed, 29 Jul 2009 14:48:06 +0100." Date: Thu, 30 Jul 2009 00:34:19 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Jim Reid writes: > On 29 Jul 2009, at 14:24, Ond=C5=99ej Sur=C3=BD wrote: > > > Is there a possibility to sign with BOTH? SHA-1 and SHA-256? > > What should the validator do if the SHA-1 signature turns out to be =20 > invalid but the SHA-256 one was OK? You accept the answer if you support both. That is what the DNSSEC RFC's say to do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 07:45:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894BB3A6EA3; Wed, 29 Jul 2009 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk1vcb9nuM+O; Wed, 29 Jul 2009 07:45:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC7BC3A6CFB; Wed, 29 Jul 2009 07:45:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWALx-0005E9-CG for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:42:01 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWALt-0005Cy-EF for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:41:59 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id D2B04327A78 for ; Wed, 29 Jul 2009 14:41:56 +0000 (UTC) Received: from red-dragon.road.flame.org (unknown [IPv6:2001:df8:0:16:213:46ff:feb9:ea2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id A9422327A6D for ; Wed, 29 Jul 2009 14:41:55 +0000 (UTC) Message-ID: <4A702AE1.10201@isc.org> Date: Wed, 29 Jul 2009 05:56:33 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (X11/20090622) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 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: Let me state some reasons I'm opposed to this draft's purpose, even though I think some part of it would be very interesting to pursue. (1) This becomes a meta-type in practice. It might prevent some lookups initially, but should a client ask for items that were not in the cache, the server would have to remember which algorithms it saw in the DNSKEY response to know which it could usefully retrieve with follow-on queries. For example, a particular stub might support more algorithms than the cache it asks, so additional queries (including additional queries for the DNSKEY to obtain its signatures) would have to be generated. (2) This solves a problem I do not fully believe is a problem, that of TCP fallback. I've said it before, but chat servers, web servers, and other types of TCP-based servers handle many, many connections/sec and many, many sustained clients today. I don't understand why DNS is different here, excepting perhaps that we have not encountered this situation until now. (3) It solves a problem that I do not fully believe is a problem, that of fragmented packets. There is no solid solution in this proposal that it WILL get packets through, only that it might have a better chance to do so. Key rollover will still cause large packets and/or TCP fallback, which means only during rollover events will badness occur. I'd rather it occur all the time rather than only in some situations. (4) I believe the knowledge it would allow to be gathered -- that of which algorithms, hashes, etc. were in common use -- is very valuable. Perhaps a draft on "voluntary reporting of server capabilities" would be useful, where the data would be anonymous, infrequently (order days at least) reported, and collected into reports. Knowing that RSA/SHA1 is not used any longer is very good information to know in terms of deprecating protocols, but using that as a filter seems unwise to me. --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 Jul 29 07:48:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDAA3A67E7; Wed, 29 Jul 2009 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 ex4DQv2OpgI8; Wed, 29 Jul 2009 07:48:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB9CD3A6F6D; Wed, 29 Jul 2009 07:48:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAPY-00064M-H6 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:45:44 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAPS-00063Q-R0 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:45:42 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id F3CDA57090; Wed, 29 Jul 2009 10:45:37 -0400 (EDT) Date: Wed, 29 Jul 2009 10:45:37 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: Message-ID: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 29 Jul 2009, Nicholas Weaver wrote: > Remember, also, the attitude of "yeah, its cracks are showing but its not > broken yet from our viewpoint, its just collision attacks" had root cert > vendors continuing to use MD5: > > http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt > > That didn't work out very well... > > So to ease deployment on those unwilling or unable to update their codebase > to NSEC3/SHA-256, the solution is to put a potential time-bomb into the root > signature? Note that the usage is quite different. Certs tend to be trusted until their signature expiry time, due to lack of CRL deployments. That makes pulling the plug on a compromised algorithm very hard. However, with DNSSEC, we have no requirement to sign "for the future". We can rollover the key whenever cracking sha-1 has become uncomfortably close to reality, while at the same time alternatives have become available, and nameservers have been sufficiently deployed with the new algorithm. And it is not clear SHA-2 would stand that much longer after SHA-1 falls either, so I'm not sure what the exact gain is with deploying SHA-2. What happened to "walk, not run" ? Paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 07:55:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357263A6A86; Wed, 29 Jul 2009 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, 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 AWl0yrVt9tk9; Wed, 29 Jul 2009 07:54:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1DD33A67F4; Wed, 29 Jul 2009 07:54:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAVY-0007FQ-8K for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:51:56 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAVS-0007Em-PR for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:51:52 +0000 Received: from [10.31.200.165] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6TEpg05062937; Wed, 29 Jul 2009 10:51:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Date: Wed, 29 Jul 2009 10:50:58 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:48 +0100 7/29/09, Jim Reid wrote: >What should the validator do if the SHA-1 signature turns out to be invalid >but the SHA-256 one was OK? Or vice versa? The plan in the development of DNSSEC was - if there's one validation "chain" that works, then the data is good. "One that is good" is in the eyes of the validator. (Chorus:) Adding security to a functioning system make the underlying system more brittle. The goal is to limit the increase in the brittleness. DNS is a loose system, this is what allows it to scale. For DNSSEC not to screw DNS up, DNSSEC can't be too tight - it has to be just-tight-enough. >Would/should there be a priority order/preference for validators to pick >from when choosing between multiple RRSIGs which each have different hash >algorithms? That's up to local policy. I'd encourage my competitors to have a policy that sets such preferences; to paraphrase a quip from a past chair of this group. Security systems with lots of parameters reminds me of a Johnny Cash lyric: Can be found here: http://www.azlyrics.com/lyrics/johnnycash/onepieceatatime.html # Now, up to now my plan went all right # 'Til we tried to put it all together one night # And that's when we noticed that something was definitely wrong. # # The transmission was a '53 # And the motor turned out to be a '73 # And when we tried to put in the bolts all the holes were gone. (The signer was a '07 and the openssl was a '09 ... same effect.) The story goes well though: # So we drilled it out so that it would fit # And with a little bit of help with an A-daptor kit We just need a good "A-daptor." (I'm in a musical mood today - last night "The Music of Abba" [a.k.a. "Faux Abba"] played at Wolf Trap Park near WashingtonDC/US. I might not be at the IETF in Stockholm, but Swedish culture is paying me a visit anyway.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 07:59:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAED13A692D; Wed, 29 Jul 2009 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.306 X-Spam-Level: X-Spam-Status: No, score=-5.306 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxm-xdjdiAof; Wed, 29 Jul 2009 07:59:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0F583A67F4; Wed, 29 Jul 2009 07:59:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAZC-0007zT-3Z for namedroppers-data0@psg.com; Wed, 29 Jul 2009 14:55:42 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAZ8-0007xz-HZ for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:55:40 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TEtNvH008681; Wed, 29 Jul 2009 07:55:23 -0700 (PDT) Cc: Nicholas Weaver , Jim Reid , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , namedroppers@ops.ietf.org Message-Id: <15666469-5989-4552-A12F-6839D0DB5C8D@icsi.berkeley.edu> From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200907291434.n6TEYJMC006643@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 07:55:23 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <200907291434.n6TEYJMC006643@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 7:34 AM, Mark Andrews wrote: > > In message , Jim > Reid writes: >> On 29 Jul 2009, at 14:24, Ond=C5=99ej Sur=C3=BD wrote: >> >>> Is there a possibility to sign with BOTH? SHA-1 and SHA-256? >> >> What should the validator do if the SHA-1 signature turns out to be >> =20 >> invalid but the SHA-256 one was OK? > > You accept the answer if you support both. That is what > the DNSSEC RFC's say to do. This leaves open to downgrade attacks etc. Two signatures, with one broken, general equals one broken 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 Jul 29 08:04:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111193A6814; Wed, 29 Jul 2009 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxVHR0BI0c2x; Wed, 29 Jul 2009 08:04:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0005B3A6830; Wed, 29 Jul 2009 08:03:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAdx-00090q-NF for namedroppers-data0@psg.com; Wed, 29 Jul 2009 15:00:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWAdt-00090E-3e for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 15:00:34 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TF0Wsj008977; Wed, 29 Jul 2009 08:00:32 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Paul Wouters In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 08:00:32 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 7:45 AM, Paul Wouters wrote: > On Wed, 29 Jul 2009, Nicholas Weaver wrote: > >> Remember, also, the attitude of "yeah, its cracks are showing but >> its not broken yet from our viewpoint, its just collision attacks" >> had root cert vendors continuing to use MD5: >> >> http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt >> >> That didn't work out very well... >> >> So to ease deployment on those unwilling or unable to update their >> codebase to NSEC3/SHA-256, the solution is to put a potential time- >> bomb into the root signature? > > Note that the usage is quite different. Certs tend to be trusted > until their > signature expiry time, due to lack of CRL deployments. That makes > pulling the plug > on a compromised algorithm very hard. > > However, with DNSSEC, we have no requirement to sign "for the > future". We can > rollover the key whenever cracking sha-1 has become uncomfortably > close to > reality, while at the same time alternatives have become available, > and nameservers > have been sufficiently deployed with the new algorithm. But there is a huge difference between "key rollover" and "algorithm rollover", especially if the better algorithm was specifically NOT used the first time because of some unspecified deployment fears. > And it is not clear SHA-2 would stand that much longer after SHA-1 > falls either, > so I'm not sure what the exact gain is with deploying SHA-2. More bits in the same family tend to paper over a LOT of sins. SHA-256 gives a fair bit more safety margin than SHA-1s 160bit. > What happened to "walk, not run" ? What happened to avoid known-problems? SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd like to see a formal commitment to shift to the Advanced Hash function winner after it gets NSA approval for Top Secret communication), but better. -- to unsubscribe send a message to namedroppers-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 Jul 29 08:17:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDE13A6D46; Wed, 29 Jul 2009 08:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8I7mb-4i9y4; Wed, 29 Jul 2009 08:17:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD4493A6AA1; Wed, 29 Jul 2009 08:17:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWArZ-000CMm-6Z for namedroppers-data0@psg.com; Wed, 29 Jul 2009 15:14:41 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWArU-000CLr-Ke for namedroppers@psg.com; Wed, 29 Jul 2009 15:14:39 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id F2A80327A76 for ; Wed, 29 Jul 2009 15:14:35 +0000 (UTC) Received: from red-dragon.road.flame.org (unknown [IPv6:2001:df8:0:16:213:46ff:feb9:ea2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id EC1F5327A6D for ; Wed, 29 Jul 2009 15:14:34 +0000 (UTC) Message-ID: <4A703289.2030005@isc.org> Date: Wed, 29 Jul 2009 06:29:13 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (X11/20090622) MIME-Version: 1.0 To: namedroppers@psg.com Subject: [dnsext] draft-li-dnsext-ipv4-ipv6 comments 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: I do not like this draft in its current form. Technical issues were requested to be discussed here, so here goes. (1) The wording is confusing regarding "no new record type" but then using "query type" -- it is effectively a meta-query type saying "return A or AAAA records." It will only be used in queries, so this seems like an apt definition, but it will consume rr type address space. (2) It is a meta-type, which makes it scary to me for a number of reasons. If you ask for an A record, you get a clear yes/no answer. If you ask for AAAA, you get a clear yes/no answer. However, if you ask for this meta-type, you might get A, AAAA, both, or neither. If you get both, you know something useful, as with neither. If you only get one type, you don't really know if the other exists, or if the cache you asked only had one of them. (3) We are concerned about packet sizes, and yet here is a proposal that will drastically increase the size of an answer should DNSSEC be involved. I believe the purpose of this is not to minimize queries, so much as giving the client as close to immediate response time. That is, "give me what you have and I'll try to use it!" I believe however that this will cause a strong bias to ipv4 since it is more likely that this information may be cached, and will further bias statistics on ipv6 vs ipv4 traffic in the wrong direction. This can be somewhat mitigated if a recursive cache always asked for both types when a client asks for A or AAAA, just in case someone might later need it. This will in general increase traffic per query but probably not so much as multiple queries. I propose this become an EDNS option, assuming the combined query has merit -- which I feel it does. That option would indicate on sending that even though you are asking for A records, you also want AAAA if available. Perhaps this could be extended to other types, but initially it should be restricted to A/AAAA only. I would write it as "additional types to return" so if a client asked specifically for an AAAA record, an AAAA+A query could be issued, while if an A was asked for, an A+AAAA would be issued. This ensures progress should the option not be understood upstream. The response would include an EDNS option specifying the tri-state (I know there is no record, I do not know if I have a record) for each type NOT returned in the answer section, so the client can decide if it should try harder if it really prefers one or the other option. --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 Jul 29 08:26:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA36A3A697F; Wed, 29 Jul 2009 08:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csVlr8KJt6s0; Wed, 29 Jul 2009 08:26:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC16E3A696F; Wed, 29 Jul 2009 08:26:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWB0Q-000Djx-99 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 15:23:50 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWB0L-000DjG-Vb for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 15:23:47 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n6TFNh6u059785; Wed, 29 Jul 2009 17:23:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200907291523.n6TFNh6u059785@givry.fdupont.fr> From: Francis Dupont To: Florian Weimer cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS64 and lying cache servers In-reply-to: Your message of Wed, 29 Jul 2009 14:05:43 -0000. <8263dbinyg.fsf@mid.bfk.de> Date: Wed, 29 Jul 2009 17:23:43 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Address selection is about suppressing address records so that they are never used by the application (unless special conditions, like unreachable servers, are met). => I used another definition of address selection but mine or yours are not related to DNS64. > To summary there are two possible places where to perform the synthesis, > my concern is about to do at the right place and not at the place which > seems easy. The right place is inside the stub (or in close cooperation with the stub), and that seems to be out of scope to me, based on prior discussions. => I agree the DNS64 details are not in the scope of DNS* WGs but to avoid spurious deployment of lying cache servers *is*. So as BEHAVE people'd like to know what we (DNS people) think about DNS64 I can't see a reason to not explain we prefer stub-resolver mode. (It also suffers from the "not b****y likely" problem because as I understand it, BEHAVE aims at not requiring far-reaching client-side changes.) => DNS64 proposes the two modes but seems to prefer the DNS server one. Our role should be to explain that from the DNS point of view this mode has many critical issues so the preference should be reconsidered (to summarize the stub-resolver mode should be investigated too and not kept only on paper. For instance the stub-resolver mode should be supported as the default mechanism and the DNS server mode used as the fallback for nodes which are not DNS64-aware, i.e., which don't ask for DNS64 setup by DHCPv6). Regards Francis.Dupont@fdupont.fr PS: what is exactly your concern? Not give advise to BEHAVE? Another recommendation? -- to unsubscribe send a message to namedroppers-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 Jul 29 08:57:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9651A3A6B6C; Wed, 29 Jul 2009 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ooQ4wdJsxc2; Wed, 29 Jul 2009 08:57:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B95563A6E78; Wed, 29 Jul 2009 08:57:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBRd-000IvS-8F for namedroppers-data0@psg.com; Wed, 29 Jul 2009 15:51:57 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBRY-000Iu6-WE for namedroppers@psg.com; Wed, 29 Jul 2009 15:51:55 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n6TFpkTk060093; Wed, 29 Jul 2009 17:51:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200907291551.n6TFpkTk060093@givry.fdupont.fr> From: Francis Dupont To: Michael Graff cc: namedroppers@psg.com Subject: Re: [dnsext] draft-li-dnsext-ipv4-ipv6 comments In-reply-to: Your message of Wed, 29 Jul 2009 06:29:13 CDT. <4A703289.2030005@isc.org> Date: Wed, 29 Jul 2009 17:51:46 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: The response would include an EDNS option specifying the tri-state (I know there is no record, I do not know if I have a record) for each type NOT returned in the answer section, so the client can decide if it should try harder if it really prefers one or the other option. => or a NSEC* RR showing one of the address RR type is not present (it works only with DNSSEC but is simple). Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 08:57:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31AA3A6BE7; Wed, 29 Jul 2009 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.818 X-Spam-Level: X-Spam-Status: No, score=-101.818 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqwZrIEAHZvd; Wed, 29 Jul 2009 08:57:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 272063A6909; Wed, 29 Jul 2009 08:57:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBUJ-000JQB-4N for namedroppers-data0@psg.com; Wed, 29 Jul 2009 15:54:43 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBSw-000J7M-MR for namedroppers@psg.com; Wed, 29 Jul 2009 15:53:38 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 120F1327A76; Wed, 29 Jul 2009 15:53:18 +0000 (UTC) Received: from [130.129.23.145] (dhcp-1791.meeting.ietf.org [130.129.23.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 54217327A6D; Wed, 29 Jul 2009 15:53:17 +0000 (UTC) References: <200907291551.n6TFpkTk060093@givry.fdupont.fr> Message-Id: From: Michael Graff To: Francis Dupont In-Reply-To: <200907291551.n6TFpkTk060093@givry.fdupont.fr> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Subject: Re: [dnsext] draft-li-dnsext-ipv4-ipv6 comments Date: Wed, 29 Jul 2009 17:53:11 +0200 Cc: "namedroppers@psg.com" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: And better if dnssec was used. I am concerd about the answer where an A is cached and AAAA is not. As a client I may want to know that. --Michael On Jul 29, 2009, at 17:51, Francis Dupont wrote: > In your previous mail you wrote: > > The response would include an EDNS option specifying the tri-state > (I > know there is no record, I do not know if I have a record) for > each type > NOT returned in the answer section, so the client can decide if it > should try harder if it really prefers one or the other option. > > => or a NSEC* RR showing one of the address RR type is not present > (it works only with DNSSEC but is simple). > > Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 08:59:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63C53A6FA1; Wed, 29 Jul 2009 08:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlbxSna+eajM; Wed, 29 Jul 2009 08:59:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FC253A6F11; Wed, 29 Jul 2009 08:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBVS-000Jb4-L4 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 15:55:54 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBVN-000JaN-3U for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 15:55:51 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n6TFteDU060164; Wed, 29 Jul 2009 17:55:40 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200907291555.n6TFteDU060164@givry.fdupont.fr> From: Francis Dupont To: Florian Weimer cc: Nicholas Weaver , Rob Austein , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-reply-to: Your message of Wed, 29 Jul 2009 14:04:35 -0000. <827hxrio0c.fsf@mid.bfk.de> Date: Wed, 29 Jul 2009 17:55:40 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: SHA-2 support implies NSEC3 support, so this is certainly not a simple key installation or cryptographic algorithm update for most operators. => support != use so I don't understand your concern (or it is about the NSEC3 code complexity and .gov already chose for you :-). Regards Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 09:07:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7503A6F33; Wed, 29 Jul 2009 09:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs0bY8rL98JB; Wed, 29 Jul 2009 09:07:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 685A83A70FB; Wed, 29 Jul 2009 09:07:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBdD-000LNN-Be for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:03:55 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBd5-000LKx-5W for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:03:49 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n6TG2s3L060223; Wed, 29 Jul 2009 18:02:54 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200907291602.n6TG2s3L060223@givry.fdupont.fr> From: Francis Dupont To: Jelte Jansen cc: Jim Reid , =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-reply-to: Your message of Wed, 29 Jul 2009 16:05:33 +0200. <4A70572D.2070403@NLnetLabs.nl> Date: Wed, 29 Jul 2009 18:02:54 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: if anyone knows another implementation of the draft (preferably a non-openssl one), please let me know :) => is your concern about OpenSSL for SHA-2 or for RSA? In the second case I have a dnspython hack using OpenSSL for hash but the builtin big intergers for RSA, so I can adapt it to SHA-2. Just send a message to me to my other/company address... Regards Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 09:09:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4D03A6943; Wed, 29 Jul 2009 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa6C8WQuL1wd; Wed, 29 Jul 2009 09:09:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2029A3A6909; Wed, 29 Jul 2009 09:09:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBgN-000Lzs-Bi for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:07:11 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBg7-000Lw2-SP for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:07:06 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=l/eC2F3cyobY8UqNd4wAS4jxixRLVojPHlaGgs9xcOC1juTlENRiW9ka VnwRIscILxDBAkCcEOjH1SxtldsYVmhcw4GasWRSh8VtYXFyOcDeR2mE0 OY747PP7Z8lEis4; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1248883615; x=1280419615; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20[dnsext]=20Signing=20the=20root=20with=20SHA-1 =20or=20SHA-2|Date:=20Wed,=2029=20Jul=202009=2018:06:47 =20+0200|Message-ID:=20|To:=20namedroppe rs@ops.ietf.org|MIME-Version:=201.0; bh=iQicndVEQLh4TRd6FTMJtMTOFUt6oVT2iTNhYpPjOs4=; b=I6ooFLGcOuxLhr4Lq/uysTqeRBT3SkpJ4n3i8yW8g5X6j+Bo9detz002 iBq/uzdjWMZW39rHHySEjdY0824p2Bca6ZgFbZDgR8DxOmYjCP+0jkaUW NpyT0ZhJwga7Lc9; X-IronPort-AV: E=Sophos;i="4.43,289,1246834800"; d="scan'208";a="16232988" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Jul 2009 17:06:50 +0100 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: "Roy Arends" Date: Wed, 29 Jul 2009 18:06:47 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/07/2009 05:06:53 PM, Serialize complete at 29/07/2009 05:06:53 PM Content-Type: multipart/alternative; boundary="=_alternative 005883BEC1257602_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 005883BEC1257602_= Content-Type: text/plain; charset="US-ASCII" Rolling to a new algorithm is no sinecure. It essentially means that both algorithms need to be used in parallel for a fair amount of time. There will be two events. Event 1 adds RSASHA256 keys and signatures to the root. Event 2 removes RSASHA1 keys and signatures from the root. What is the exit strategy for RSASHA1 (i.e. when will event 2 happen), without evidence of a sginificant cryptanalysis of SHA1? When is it safe to remove it, without a significant set of validators (who only support RSASHA1) being unable to validate? Is that day when all of the TLDs support RSASHA256 only? When will it be safe for TLDs to phase out RSASHA1? I fear that there will be a significant period where the root has to support both algorithms, after event1. That means that the DNSKEY set becomes larger. That means that there will be more signatures in a response. The DNSKEY set will have a minimum of 4 DNSKEYs. Assuming 2Kbit KSKs and 1K ZSKs. That is going to be 6Kbit in key material. During a KSK (not algorithm) roll, add 2Kbit key material. This results in 8Kbit key material + 6Kbit signature material, which results in 14Kbit, or a response size of at least 1792 bytes. (obviously this will be a lot larger as this number _just_ shows the crypto) EDNS0 buffer size doesn't help here. The bulk of the resolvers will fall back to tcp, or fail due to dropped fragments if incorrect edns buffer sizes are announced. We can significantly move this problem of large response size further in the future if the root is signed with RSASHA2. There are many more considerations, for and against, I just wanted this to be taken into consideration. Kind Regards, Roy Arends Nominet --=_alternative 005883BEC1257602_= Content-Type: text/html; charset="US-ASCII" Rolling to a new algorithm is no sinecure. It essentially means that both algorithms need to be used in parallel for a fair amount of time. There will be two events. Event 1 adds RSASHA256 keys and signatures to the root. Event 2 removes RSASHA1 keys and signatures from the root. What is the exit strategy for RSASHA1 (i.e. when will event 2 happen), without evidence of a sginificant cryptanalysis of SHA1? When is it safe to remove it, without a significant set of validators (who only support RSASHA1) being unable to validate? Is that day when all of the TLDs support RSASHA256 only? When will it be safe for TLDs to phase out RSASHA1?

I fear that there will be a significant period where the root has to support both algorithms, after event1. That means that the DNSKEY set becomes larger. That means that there will be more signatures in a response. The DNSKEY set will have a minimum of 4 DNSKEYs. Assuming 2Kbit KSKs and 1K ZSKs. That is going to be 6Kbit in key material. During a KSK (not algorithm) roll, add 2Kbit key material. This results in 8Kbit key material + 6Kbit signature material, which results in 14Kbit, or a response size of at least 1792 bytes. (obviously this will be a lot larger as this number _just_ shows the crypto)

EDNS0 buffer size doesn't help here. The bulk of the resolvers will fall back to tcp, or fail due to dropped fragments if incorrect edns buffer sizes are announced.

We can significantly move this problem of large response size further in the future if the root is signed with RSASHA2.

There are many more considerations, for and against, I just wanted this to be taken into consideration.

Kind Regards,

Roy Arends
Nominet --=_alternative 005883BEC1257602_=-- -- to unsubscribe send a message to namedroppers-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 Jul 29 09:14:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757A23A6AA1; Wed, 29 Jul 2009 09:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HODJ4zfkIHfb; Wed, 29 Jul 2009 09:14:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3A553A6B2D; Wed, 29 Jul 2009 09:13:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBjc-000MUK-V5 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:10:32 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBjV-000MR8-LR for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:10:30 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6TGAKAO064016; Wed, 29 Jul 2009 12:10:21 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200907291610.n6TGAKAO064016@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 12:10:20 -0400 To: Nicholas Weaver , Paul Wouters From: Olafur Gudmundsson Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Cc: namedroppers@ops.ietf.org In-Reply-To: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:00 29/07/2009, Nicholas Weaver wrote: >>And it is not clear SHA-2 would stand that much longer after SHA-1 >>falls either, >>so I'm not sure what the exact gain is with deploying SHA-2. > >More bits in the same family tend to paper over a LOT of sins. >SHA-256 gives a fair bit more safety margin than SHA-1s 160bit. > >>What happened to "walk, not run" ? > >What happened to avoid known-problems? > >SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd >like to see a formal commitment to shift to the Advanced Hash function >winner after it gets NSA approval for Top Secret communication), but >better. References please. There is a big difference IMHO using SHA-1 in DNSSEC signatures that are valid for a "short" time compared to the "long" time that CERT's live. If you look at the tread starting at http://psg.com/lists/namedroppers/namedroppers.2009/msg00785.html In particular: http://psg.com/lists/namedroppers/namedroppers.2009/msg00848.html 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 Jul 29 09:29:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB6E3A6F0B; Wed, 29 Jul 2009 09:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=-1.715, 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 6ev31d5gDHAQ; Wed, 29 Jul 2009 09:29:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04BAC3A6955; Wed, 29 Jul 2009 09:28:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBxz-000PDL-Mq for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:25:23 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBxu-000PCd-Sd for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:25:21 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOsUcEqrR7PD/2dsb2JhbAC8EognkDYFhBE X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="sig'?scan'208";a="180293820" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2009 16:25:18 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6TGPIA5007765; Wed, 29 Jul 2009 09:25:18 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6TGPHVN023826; Wed, 29 Jul 2009 16:25:17 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 18:25:16 +0200 Received: from dhcp-17cb.meeting.ietf.org ([10.61.95.71]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 18:25:16 +0200 Cc: Rob Austein , namedroppers@ops.ietf.org Message-Id: <5ED96A6E-B522-4231-AEE5-9B9598BF99C3@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Basil Dolmatov In-Reply-To: <4A705CCB.9030304@reedcat.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-72--5423822" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 18:25:15 +0200 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A705CCB.9030304@reedcat.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 16:25:16.0490 (UTC) FILETIME=[282982A0:01CA1069] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1363; t=1248884718; x=1249748718; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dnsext]=20Signing=20the=20root=20with= 20SHA-1=20or=20SHA-2 |Sender:=20; bh=ze3tRQBORa5sDiYtsjFTxRewaaY20Fz3M3YIqdkLbHg=; b=AxlyUW2tMuiuKCSVX4kz+X6KG/u96n/CwDrWo0ZUTFm9pYumNKwhv4YcPZ S3zX5awfO5WNLyWFkq9f0jZsGu2v2uEZ5Q5oAuLj76mrNiZ6McH15hg/IGfP FiorIdcHoE; Authentication-Results: sj-dkim-3; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-72--5423822 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 29 jul 2009, at 16.29, Basil Dolmatov wrote: >> What we do need is, for pure interoperability reasons, _one_ >> algorithm that is "the algorithm that is in use", and then a >> mechanism for rollover algorithms when needed. >> >> I would argue strongly against mechanisms that enable what would be >> a terrible tragedy of the commons, which would be simultaneously >> use of unlimited number of algorithms. > So you will effectively restrict a significant part of the world > Internet from usage of this technology. That is not what I am saying. I am saying the problem you refer to should be worked on and resolved, instead of patching around it, as patches always are patches. Patrik --Apple-Mail-72--5423822 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) iD8DBQFKcHfrvHlR2X0luNwRAuggAJ0ZNAb3IZJn36dzShjKdncJ3DzHugCcDZa3 KBwAxGrY1xPThD7XdPvmTVM= =hriN -----END PGP SIGNATURE----- --Apple-Mail-72--5423822-- -- to unsubscribe send a message to namedroppers-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 Jul 29 09:29:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C16B3A6955; Wed, 29 Jul 2009 09:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFsFTdr19zP4; Wed, 29 Jul 2009 09:29:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8CA13A6D61; Wed, 29 Jul 2009 09:28:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBz7-000PN8-Ev for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:26:33 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWBz3-000PMW-Sq for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:26:31 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id E125957090; Wed, 29 Jul 2009 12:26:28 -0400 (EDT) Date: Wed, 29 Jul 2009 12:26:28 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> Message-ID: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 29 Jul 2009, Nicholas Weaver wrote: >> What happened to "walk, not run" ? > > What happened to avoid known-problems? To me, the problem to avoid is using algorithms that have not seen a wide deployment. > SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd like to > see a formal commitment to shift to the Advanced Hash function winner after > it gets NSA approval for Top Secret communication), but better. If you see moving to the Advanced Hash function winner soon, then what is the problem of starting with sha1 and moving to sha2 once its seen a few more adoptions in commonly deployed nameserver software? There seems to be two reasons to do SHA-256: - SHA1 is too weak (not true for the next two years IMHO, and if that estimate is wrong, you can decrease the rollover interval to counteract) - Algorithm rollover is scary (As you said, it will happen sooner rather then later anyway) Reasons to start with SHA-1: - Give SHA-256 some more time to get deployed and tested - Give vendors more time to test nameserver software with SHA-256 - Don't add the "you must upgrade software" roadblock to people who just want to use a deployed signed root. Paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 09:43:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF843A7003; Wed, 29 Jul 2009 09:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.814, 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 uoN9RkkXTJgj; Wed, 29 Jul 2009 09:43:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99D6E3A6822; Wed, 29 Jul 2009 09:43:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWCBX-0001lz-LE for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:39:23 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWCBT-0001jh-QD for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:39:21 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6TGdI7O064367 for ; Wed, 29 Jul 2009 12:39:18 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n6TGdImB064366 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 12:39:18 -0400 (EDT) (envelope-from namedroppers) Received: from [69.64.72.227] (helo=step.reedcat.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWA9r-0002iR-So for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 14:29:35 +0000 Received: from [130.129.19.181] (dhcp-13b5.meeting.ietf.org [130.129.19.181]) by step.reedcat.net (Postfix) with ESMTPA id 11B5029563F; Wed, 29 Jul 2009 18:29:29 +0400 (MSD) Message-ID: <4A705CCB.9030304@reedcat.net> Date: Wed, 29 Jul 2009 18:29:31 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Rob Austein , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> In-Reply-To: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Patrik Fältström wrote: > On 29 jul 2009, at 14.55, Rob Austein wrote: > >> [Continuation of Stockholm WG session, cut off due to lack of time] >> >> My concern with the proposal to sign the root just with SHA-2 is that >> it will be years before enough of the installed base has SHA-2-capable >> DNSSEC in production. Even ignoring vendors with long development >> cycles, mainstream operators don't upgrade quickly. We're talking >> years here, not months. >> >> I think the suggestion that we start with SHA-1 then roll to SHA-2 >> makes a fair amount of sense. If algorithm roll at the root really is >> that scary, we should not wait until an emergency to try it. > > FWIW: This makes sense to me. > > What we do need is, for pure interoperability reasons, _one_ algorithm > that is "the algorithm that is in use", and then a mechanism for > rollover algorithms when needed. > > I would argue strongly against mechanisms that enable what would be a > terrible tragedy of the commons, which would be simultaneously use of > unlimited number of algorithms. So you will effectively restrict a significant part of the world Internet from usage of this technology. Maybe that makes sense, I should evaluate that. dol@ > > paf > -- to unsubscribe send a message to namedroppers-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 Jul 29 10:04:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332703A67D2; Wed, 29 Jul 2009 10:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpohMP7-iw6q; Wed, 29 Jul 2009 10:04:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0ADA53A6D46; Wed, 29 Jul 2009 10:04:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWCV1-0005Av-G5 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 16:59:31 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWCUx-0005AJ-7p for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 16:59:28 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TGx2Lt019498; Wed, 29 Jul 2009 09:59:02 -0700 (PDT) Cc: Nicholas Weaver , Paul Wouters , namedroppers@ops.ietf.org Message-Id: <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Olafur Gudmundsson In-Reply-To: <200907291610.n6TGAKAO064016@stora.ogud.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 09:59:02 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 9:10 AM, Olafur Gudmundsson wrote: > At 11:00 29/07/2009, Nicholas Weaver wrote: > >>> And it is not clear SHA-2 would stand that much longer after SHA-1 >>> falls either, >>> so I'm not sure what the exact gain is with deploying SHA-2. >> >> More bits in the same family tend to paper over a LOT of sins. >> SHA-256 gives a fair bit more safety margin than SHA-1s 160bit. >> >>> What happened to "walk, not run" ? >> >> What happened to avoid known-problems? >> >> SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd >> like to see a formal commitment to shift to the Advanced Hash >> function >> winner after it gets NSA approval for Top Secret communication), but >> better. > > References please. Even as old as 2005 it was known SHA-1 had problems: http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1 -- to unsubscribe send a message to namedroppers-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 Jul 29 11:41:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695FD3A70CA; Wed, 29 Jul 2009 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hidpRe54d0oz; Wed, 29 Jul 2009 11:41:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E95BC3A70FA; Wed, 29 Jul 2009 11:41:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWE0w-000NNO-HY for namedroppers-data0@psg.com; Wed, 29 Jul 2009 18:36:34 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWE0s-000NKH-9K for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 18:36:32 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id ADB5557090; Wed, 29 Jul 2009 14:36:28 -0400 (EDT) Date: Wed, 29 Jul 2009 14:36:28 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> Message-ID: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 29 Jul 2009, Nicholas Weaver wrote: >>> SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd >>> like to see a formal commitment to shift to the Advanced Hash function >>> winner after it gets NSA approval for Top Secret communication), but >>> better. >> >> References please. > > Even as old as 2005 it was known SHA-1 had problems: > http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html 2^106 calculations: much less than the 2^160 calculations for brute force. You are going to break that within a month? Even if you do get a collision, that's far from being able to create your own malicious spoofed record that appears correctly signed. > http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1 To that end, a collision search for SHA-1 using the distributed computing platform BOINC began August 8, 2007, organized by the Graz University of Technology. The effort was abandoned May 12, 2009 due to lack of progress. If you really think SHA1 is that weak, you can do various things: - More frequent KSK/ZSK rollovers - Use NSEC3 and change the seed regularly - Buy all PS3's from Sony before they get to the NSA So even if significant progress is made towards breaking SHA1, there are methods to "walk, not run" to SHA-256 or something else. Roy's argument about zone size is a good one though. We might not want to commit to that if we don't have to yet, though a lot of broken setups will break with any DNSSEC deployment, and those who still do not support ENDS0 or TCP will realisticly only upgrade after they break, so whatever we do to mitigate that will just postpone the inevitable. Paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 11:51:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540563A6F86; Wed, 29 Jul 2009 11:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.177 X-Spam-Level: X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+FLCHBaFAOD; Wed, 29 Jul 2009 11:51:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 589623A6926; Wed, 29 Jul 2009 11:51:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWEBl-000PyQ-AP for namedroppers-data0@psg.com; Wed, 29 Jul 2009 18:47:45 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWEBb-000Px2-TV for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 18:47:43 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TIlZ3D002854; Wed, 29 Jul 2009 11:47:35 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Paul Wouters In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 11:47:34 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 11:36 AM, Paul Wouters wrote: Read further: > Cameron McDonald, Philip Hawkes and Josef Pieprzyk presented a hash > collision attack with complexity 2^52 at the Rump session of > Eurocrypt 2009[28]. That is, to my mind, BROKEN. 2^52 for collision generation (it should be 2^80) is a big big deal. These are the symptoms seen before MD5 fell completely. And SHA1 has already been revoked by NIST for government use: http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html http://csrc.nist.gov/groups/ST/toolkit/documents/shs/NISTHashComments-final.pdf > Federal agencies should stop using SHA-1 for digital signatures, > digital time stamping and other applications that require collision > resistance as soon as practical, and must use the SHA-2 family of > hash functions for these applications after 2010. After 2010, > Federal agencies may use SHA-1 only for the following applications: > hash-based message authentication codes (HMACs); key derivation > functions (KDFs); and random number generators (RNGs). Regardless of > use, NIST encourages application and protocol designers to use the > SHA-2 family of hash functions for all new applications and protocols. SHA1 is dead, that you guys are even CONSIDERING SHA-1 for the root signature for DNSSEC is frankly, silly. SHA1 has been considered dead since 2006 in the eyes of NIST. -- to unsubscribe send a message to namedroppers-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 Jul 29 12:11:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0744D3A6F8C; Wed, 29 Jul 2009 12:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-bkEJEEeaU4; Wed, 29 Jul 2009 12:11:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F9A93A6F86; Wed, 29 Jul 2009 12:11:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWEUU-0004Mw-T2 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 19:07:06 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWEPd-00034Q-Uu for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 19:06:06 +0000 Received: by ewy11 with SMTP id 11so243416ewy.11 for ; Wed, 29 Jul 2009 12:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=vI+WOL1Z4yI9aaSz6zgd2EEY0aaO5pmPYaueKf6x+YE=; b=xBj8VRYDs7hBOAbBYv/B00xIispQzmQMNc+arRaF/VmLx5x4z4T0kcc5BECVsmeka5 eInVe1LN5KLT9jpSY1V41cDC9K+LcCy8HObaVlPwaPgOENQjWI1SNMrsHzy4lHWulstX wW3JTuWAHyM4kOSgvVnAyU90ECbTFp6iOt1Ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cLVpK2z2P/x2PZs3PhulOeEUgmQHCO4eon6o6AyeJW/u1eCmMyXwr2xOgv60V8DcfF jn+KtTWQlBJkYkZh8rlwyOOTVmYS4wi9otMdGi7qRaqYmbhwSbXrFQxGCtW0zO8jCADc yyedRpOL4nOklszJZgB1VFynZP98Pr4a9gyXc= MIME-Version: 1.0 Received: by 10.210.44.12 with SMTP id r12mr197499ebr.24.1248894124474; Wed, 29 Jul 2009 12:02:04 -0700 (PDT) In-Reply-To: <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> From: bert hubert Date: Wed, 29 Jul 2009 21:01:44 +0200 Message-ID: <3efd34cc0907291201w7533abacwdb6bdf551adf7354@mail.gmail.com> Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 To: Nicholas Weaver Cc: Olafur Gudmundsson , Paul Wouters , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 6:59 PM, Nicholas Weaver wrote: > Even as old as 2005 it was known SHA-1 had problems: > http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html > http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1 Let's not get our panties in a bunch too much. Even if you could collide a hash, you'd have a very hard time getting that to mean anything. And even if you could craft an RRSET that hashed identically, you'd need to do so before the RRSIG expires, and then get that answer injected - which is highly non-trivial anyhow. Also be aware that the liberty to hijack, let's say, an A record is constrained. What you could do is add 10 evil A-records, and manipulate a bunch of trailing A-records in order to get the hash to match. I'm not entirely sure of the state of the art wrt MD5 collisions, but my impression is that you need to fiddle with a (for DNS terms) non-trivial amount of garbage in order to get things to work. This might translate to 10 'evil' A records and 10 garbage A records, for example - but even in that case you can't fiddle all the bits indiscriminately - the names of the records need to continue to match for example. Plus everything needs to remain in canonical order, and presumably you'd want to corrupt the first record in the RRSET etc. I'm not weighing in on the full discussion as I have too little experience with DNSSEC deployments, but I did want to point out that because people have been able to collide a certificate does not mean they can collide an RRSET in canonical order. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 13:36:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C68D3A6B43; Wed, 29 Jul 2009 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uFEXV7d9Off; Wed, 29 Jul 2009 13:36:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3E5F3A6B0C; Wed, 29 Jul 2009 13:36:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWFo4-000Kbs-Nn for namedroppers-data0@psg.com; Wed, 29 Jul 2009 20:31:24 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWFo0-000KZZ-AQ for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 20:31:22 +0000 Received: from [10.20.30.158] ([77.241.97.116]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TKV8oC095338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 13:31:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Date: Wed, 29 Jul 2009 22:31:05 +0200 To: Rob Austein , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:55 PM +0200 7/29/09, Rob Austein wrote: >My concern with the proposal to sign the root just with SHA-2 is that >it will be years before enough of the installed base has SHA-2-capable >DNSSEC in production. This surprised me. Which DNSSEC resolvers have SHA-1 but not SHA-2 today? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 13:45:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D4D3A69D5; Wed, 29 Jul 2009 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeWMcrP0cdcY; Wed, 29 Jul 2009 13:45:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F6B73A6961; Wed, 29 Jul 2009 13:45:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWFyf-000MaP-H3 for namedroppers-data0@psg.com; Wed, 29 Jul 2009 20:42:21 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWFya-000MZg-Pq for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 20:42:18 +0000 Received: from [10.20.30.158] ([77.241.97.116]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TKg23i096097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 13:42:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> Date: Wed, 29 Jul 2009 22:42:00 +0200 To: Nicholas Weaver From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:59 AM -0700 7/29/09, Nicholas Weaver wrote: >>>SHA-1 is a known problem. SHA-256 is better. Not better ENOUGH (I'd >>>like to see a formal commitment to shift to the Advanced Hash function >>>winner after it gets NSA approval for Top Secret communication), but >>>better. >> >>References please. > >Even as old as 2005 it was known SHA-1 had problems: >http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html >http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1 Please stop the FUD about SHA-1. Those articles are about probable problems with SHA1's collision resistance. That is not applicable for the root signing TLDs. Even if such a collision can be done (it still has not been shown in practice, as compared to MD5), the scenario where it could be of damage to DNSSEC is both obscure and trivial to detect. Please stop the FUD about SHA-2. There have been no known attacks either on the collision resistance (which is easier, but not important in this use), nor on the preimage resistance. Please stop the FUD about SHA-3 or whatever it will be called. The NSA has never said (nor even hinted) that, after it is chosen that it will be a candidate for any level of classified use. I cannot speak for Olafur, but I would guess that when he asked for references, he meant ones that were relevant to this WG and supported your statements, not just random URLs about somewhat related topics. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 13:57:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B923A6E41; Wed, 29 Jul 2009 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fOdm2adBu3V; Wed, 29 Jul 2009 13:57:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 579893A6BCA; Wed, 29 Jul 2009 13:57:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWG9B-000OVB-TL for namedroppers-data0@psg.com; Wed, 29 Jul 2009 20:53:13 +0000 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWG96-000OUR-BG for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 20:53:11 +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 n6TKr65m031258 for ; Wed, 29 Jul 2009 15:53:06 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n6TKr4mo024649 for ; Wed, 29 Jul 2009 15:53:06 -0500 Received: from localhost ([204.152.186.186]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 16:53:03 -0400 Date: Wed, 29 Jul 2009 16:53:02 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@little To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Message-ID: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Jul 2009 20:53:03.0328 (UTC) FILETIME=[90BE6E00:01CA108E] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 29 Jul 2009, Rob Austein wrote: > I think the suggestion that we start with SHA-1 then roll to SHA-2 > makes a fair amount of sense. If algorithm roll at the root really is > that scary, we should not wait until an emergency to try it. I concur with Rob, primarily for the "let's force an algorithm rollover early on" reason. I'd very much like for us to prove to the world that algorithm rollover just works. And I'm happy to have that rollover scheduled from the very beginning, just so there's no debate later about when to do it. Let's do it in twelve months. Similarly, I hope that we will see several early KSK rollovers, perhaps once a year for the first 3-5 years of having a signed root, just to give resolver operators an opportunity to develop and test their KSK rollover procedures. I'm not particularly worried about market penetration of the SHA256 code. I'm more interested in making sure the (hopefully rarely used) operational procedures get exercised. -- 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 Wed Jul 29 14:16:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EABD3A6F80; Wed, 29 Jul 2009 14:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.159 X-Spam-Level: X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upZ5EMYeHlBl; Wed, 29 Jul 2009 14:16:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E5B53A6B96; Wed, 29 Jul 2009 14:16:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGSt-00033z-7I for namedroppers-data0@psg.com; Wed, 29 Jul 2009 21:13:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGSn-00032k-JN for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 21:13:32 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n6TLDSwR018039; Wed, 29 Jul 2009 14:13:28 -0700 (PDT) Cc: Nicholas Weaver , IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Wed, 29 Jul 2009 14:13:27 -0700 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 29, 2009, at 1:42 PM, Paul Hoffman wrote: > I cannot speak for Olafur, but I would guess that when he asked for =20= > references, he meant ones that were relevant to this WG and =20 > supported your statements, not just random URLs about somewhat =20 > related topics. http://csrc.nist.gov/groups/ST/hash/statement.html Including > The first of these is to transition rapidly to the stronger =93SHA-2=94 = =20 > family of hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) for =20= > digital signature applications. The SHA-2 hash functions are in the =20= > same general family of hash functions as SHA-1. They could =20 > potentially be attacked with similar techniques, but they are much =20 > stronger than SHA-1. Practical SHA-2 attacks are unlikely in the =20 > next decade; and might never be found, except through decades of =20 > exponential growth of available computing power. The SHA-2 hash =20 > functions are well along in the commercial system deployment process =20= > and are available in many newer systems and applications, but are =20 > not yet available in the majority of deployed systems. The primary =20 > constraint on the current use of the SHA-2 hash functions for =20 > signatures is interoperability; many relying party systems do not =20 > yet implement them, and may not do so for several more years. NIST =20 > encourages a rapid adoption of the SHA-2 hash functions for digital =20= > signatures, and, in any event, Federal agencies must stop relying on =20= > digital signatures that are generated using SHA-1 by the end of 2010. When NIST says "Don't do it, it may be hazardous", back in 2006! thats =20= usually a good indication that an algorithm should not be used. SHA-1 =20= is revoked for federal use effective Dec 31, 2010. The only reasons given for using SHA-1 over SHA-2 is that I can tell: There exist some resolvers: a: Properly support DNSSEC using SHA-1 b: Do not support SHA-2 c: Can not or will not be upgrade to support SHA-2 when being updated with the root's public key How many such resolvers are there where all three conditions are true? Worse, there is an additional condition proposed: d: Will be able to quickly transition to SHA-2 if a crisis actually occurs This discussion I find, frankly, bizarre. SHA-1 should be dead for =20 new deployments. DNSSEC may be a long time in coming, but the key =20 gating feature, a signed root, is a new thing. Even discussing the =20 deliberate use of a dead and scheduled-to-be-revoked hash algorithm =20 seems frankly silly. -- to unsubscribe send a message to namedroppers-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 Jul 29 14:17:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D98C3A7055; Wed, 29 Jul 2009 14:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9INw6HjCzRD5; Wed, 29 Jul 2009 14:17:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C89EA3A6A8D; Wed, 29 Jul 2009 14:17:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGRg-0002o6-2K for namedroppers-data0@psg.com; Wed, 29 Jul 2009 21:12:20 +0000 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGRc-0002mo-BB for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 21:12:18 +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 n6TLCFvj031612; Wed, 29 Jul 2009 16:12:15 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n6TLCFNm025531; Wed, 29 Jul 2009 16:12:15 -0500 Received: from localhost ([204.152.186.187]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 17:12:14 -0400 Date: Wed, 29 Jul 2009 17:12:13 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@little To: Jim Reid cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: Message-ID: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-OriginalArrivalTime: 29 Jul 2009 21:12:14.0611 (UTC) FILETIME=[3EF64630:01CA1091] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 29 Jul 2009, Jim Reid wrote: > What should the validator do if the SHA-1 signature turns out to be > invalid but the SHA-256 one was OK? Or vice versa? According to 4035, so long as there is "a" good chain, the result is Secure. It's very reasonable for a validator to have an option to disable algorithms (e.g. if one is discovered to be weak), in which case validators with different settings might get different validation results. > Would/should there be a priority order/preference for validators to > pick from when choosing between multiple RRSIGs which each have > different hash algorithms? We have not told validators to do that. A validator could ignore 4035 and implement such a function. If so, it might prefer to do so on a whole-zone basis rather than a per-RRSIG-RRset basis. But that's not behavior this WG has endorsed, AFAIK. > [Evil thought: perhaps the hash algorithm identifier should be a > field in the RRSIG rather than the DNSKEY.....] Quit trying to twiddle bits in DNSSEC. It's Done. Finally. (To the point: doing that might circumvent the protection against downgrade attacks that we wrote into this protocol some years ago. You need to signal the minimum set of cipher suites in use, including the hash algorithms, at the zone cut. Picking-and-choosing on a per-RRset basis is a recipe for attacks.) -- 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 Wed Jul 29 14:21:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200803A6FDA; Wed, 29 Jul 2009 14:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qeinlpa8VKX; Wed, 29 Jul 2009 14:21:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A3533A6EF9; Wed, 29 Jul 2009 14:21:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGWw-0003lu-SS for namedroppers-data0@psg.com; Wed, 29 Jul 2009 21:17:46 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGWq-0003iy-9F for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 21:17:44 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C11F3AAEC4 for ; Wed, 29 Jul 2009 21:17:39 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: Your message of "Wed, 29 Jul 2009 16:53:02 -0400." References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 29 Jul 2009 21:17:39 +0000 Message-ID: <51277.1248902259@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Wed, 29 Jul 2009 16:53:02 -0400 (EDT) > From: Samuel Weiler > > I concur with Rob, primarily for the "let's force an algorithm rollover > early on" reason. +1. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 14:40:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CB23A659A; Wed, 29 Jul 2009 14:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6T3yLXVrGPG; Wed, 29 Jul 2009 14:40:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63A8A3A68C2; Wed, 29 Jul 2009 14:40:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGo3-0006nG-ID for namedroppers-data0@psg.com; Wed, 29 Jul 2009 21:35:27 +0000 Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGnz-0006mp-Ri for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 21:35:25 +0000 Received: by ewy28 with SMTP id 28so199958ewy.41 for ; Wed, 29 Jul 2009 14:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=uVQ1zTAQu9GHIyaPZ9ld1IiCnKma8OACQOTLXzuxWi8=; b=s0wfvkES7NlIH4rXZDPDBss/GWVj8HqNH29mnShbPwe374Fox+s6qNN2ZKlM2RsWEH P0aDV08uUo9+bA5fPWx8zHBWgWu36klClUeDE2w3q5UeP4JAUBIWPIBg10O07KuX6fGz zf+hsQJQPo8RSVC+KbYh424j0vT/bcj8HlImI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=fOOIwwbcg0Fm7aZl8WJEQiGyirt1WSCibvyI2w9TbpjcIxLCxYxwBPZDPcuas55vi2 IYTbCwc7usslZDoIA+tuv4+vXY0W65o5EHmY4YTO/z0oFTrSmY899OMQt4NhyP/dpu8s xu8uCHKQRWI5DLs/RjV17hHZt9qMXm55v/doI= MIME-Version: 1.0 Received: by 10.210.68.17 with SMTP id q17mr642184eba.6.1248903322133; Wed, 29 Jul 2009 14:35:22 -0700 (PDT) In-Reply-To: <4A702AE1.10201@isc.org> References: <4A702AE1.10201@isc.org> From: bert hubert Date: Wed, 29 Jul 2009 23:35:02 +0200 Message-ID: <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 To: Michael Graff Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 12:56 PM, Michael Graff wrote: > Let me state some reasons I'm opposed to this draft's purpose, even though I > think some part of it would be very interesting to pursue. To add my reason why I'm opposed to this draft (versus its purpose): The complexity of DNSSEC is already of such stunning magnitude that almost anything that makes it even more complex, better have an earth shatteringly good reason going for it. And in this case, I'm not convinced selecting algorithms is the only way to go - it may in fact be better to simply pick algorithms well, and not choose too many. It may be that my state of mind is influenced by trying to implement NSEC3 processing - but when that is done, I don't think my opinion of DNSSEC complexity, and it being too complex already, is going to change. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 14:41:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72A928C0D8; Wed, 29 Jul 2009 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfSuM7+YXSyc; Wed, 29 Jul 2009 14:41:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A060E28C0CE; Wed, 29 Jul 2009 14:41:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGr1-0007B9-2i for namedroppers-data0@psg.com; Wed, 29 Jul 2009 21:38:31 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWGqx-0007Ap-Nv for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 21:38:29 +0000 Received: by pzk38 with SMTP id 38so150753pzk.33 for ; Wed, 29 Jul 2009 14:38:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.166.9 with SMTP id o9mr384900wae.158.1248903507015; Wed, 29 Jul 2009 14:38:27 -0700 (PDT) In-Reply-To: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Date: Wed, 29 Jul 2009 14:38:26 -0700 Message-ID: Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 From: Matthew Dempsky To: Samuel Weiler Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 1:53 PM, Samuel Weiler wrote: > Similarly, I hope that we will see several early KSK rollovers, perhaps once > a year for the first 3-5 years of having a signed root, just to give > resolver operators an opportunity to develop and test their KSK rollover > procedures. If the goal is to give them operational practice, wouldn't it make sense to instead roll keys once or twice a week during a test period lasting a few months or something? Or better, to setup some dummy keys/servers that continue to cycle once a week indefinitely so a company starting out a few years from now will be able to still test that key rollover works fine for them. Once a year doesn't seem much better than once every N years for the purpose of letting people test their software/configurations/etc. I fear it'll end up like NTP's leap second support: there's protocol support and the code's there, but there was still a surprising number of problem reports on the technical mailing lists / blogs that I was reading when the last one occurred. In the NTP leap second case, computers are out of sync by about a second. In the DNS case, host name resolution breaks. -- to unsubscribe send a message to namedroppers-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 Jul 29 15:02:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90BC3A6BD0; Wed, 29 Jul 2009 15:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 ZV4GDeA+-6fq; Wed, 29 Jul 2009 15:02:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F31463A6A14; Wed, 29 Jul 2009 15:02:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWH9j-000AhF-8M for namedroppers-data0@psg.com; Wed, 29 Jul 2009 21:57:51 +0000 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWH9f-000AgS-4t for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 21:57:48 +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 n6TLvjRI032173; Wed, 29 Jul 2009 16:57:45 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n6TLvjUm027038; Wed, 29 Jul 2009 16:57:45 -0500 Received: from localhost ([204.152.186.186]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 17:57:44 -0400 Date: Wed, 29 Jul 2009 17:57:42 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@little To: Matthew Dempsky cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-Reply-To: Message-ID: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Jul 2009 21:57:44.0369 (UTC) FILETIME=[9A064A10:01CA1097] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is straying away from the originally asked question about algorithms (and algorithm rollover) to key rollover. On Wed, 29 Jul 2009, Matthew Dempsky wrote: > If the goal is to give them operational practice, wouldn't it make > sense to instead roll keys once or twice a week during a test period > lasting a few months or something? I see your point, but no. Organizations are going to turn on validation slowly (by some metric). Each needs to get practice with rollover, not just the early adopters who turn it on during the test period. > Or better, to setup some dummy keys/servers that continue to cycle > once a week indefinitely so a company starting out a few years from > now will be able to still test that key rollover works fine for > them. That's a useful utility, but not one that addresses my concern, which is make sure we have the ability, both technically and politically, to do an emergency rollover in the future. A test server setup assumes they want to test and are awake and paying attention. Part of the point of the semi-slow rollovers of real-world keys is to allow time for the person who set up the validating resolver to move on to other things (maybe even a different organization) and make sure the new operator is still paying attention. > In the NTP leap second case, computers are out of sync by about a > second. In the DNS case, host name resolution breaks. Which is perhaps more incentive to fix it. :-) Yes, the breakage might be painful, but better to experience it now and prove to the world that we can cope so we can resist when someone trys to talk us out of an emergency rollover in ten years. -- 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 Wed Jul 29 15:39:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357753A6846; Wed, 29 Jul 2009 15:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qswQPxmlXr9; Wed, 29 Jul 2009 15:39:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7964E3A6AE3; Wed, 29 Jul 2009 15:39:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWHjV-000GeC-LV for namedroppers-data0@psg.com; Wed, 29 Jul 2009 22:34:49 +0000 Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWHjS-000Gdp-D1 for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 22:34:47 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 9D70957090; Wed, 29 Jul 2009 18:34:45 -0400 (EDT) Date: Wed, 29 Jul 2009 18:34:45 -0400 (EDT) From: Paul Wouters To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> Message-ID: References: <4A702AE1.10201@isc.org> <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 29 Jul 2009, bert hubert wrote: > It may be that my state of mind is influenced by trying to implement > NSEC3 processing - but when that is done, I don't think my opinion of > DNSSEC complexity, and it being too complex already, is going to > change. It grows on you. Having dinner with Roy helps too. Paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 16:34:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BF93A690A; Wed, 29 Jul 2009 16:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF6FR56D6P+h; Wed, 29 Jul 2009 16:34:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 044383A63C9; Wed, 29 Jul 2009 16:34:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWIZ2-000OIp-PG for namedroppers-data0@psg.com; Wed, 29 Jul 2009 23:28:04 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWIXq-000O7f-5f for namedroppers@ops.ietf.org; Wed, 29 Jul 2009 23:27:08 +0000 Received: from [192.168.2.178] (77.243.241.83.in-addr.dgcsystems.net [83.241.243.77]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6TNQTg1051630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 01:26:30 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A70DAA2.706@NLnetLabs.nl> Date: Thu, 30 Jul 2009 01:26:26 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Paul Hoffman CC: Rob Austein , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig163BF08A3FDE073C0DCC3588" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [213.154.224.1]); Thu, 30 Jul 2009 01:26:30 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig163BF08A3FDE073C0DCC3588 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Hoffman wrote: > At 2:55 PM +0200 7/29/09, Rob Austein wrote: >> My concern with the proposal to sign the root just with SHA-2 is that >> it will be years before enough of the installed base has SHA-2-capable= >> DNSSEC in production. >=20 > This surprised me. Which DNSSEC resolvers have SHA-1 but not SHA-2 toda= y? >=20 None of the DNSSEC validators support RSA/SHA-2 at the moment. One had it, but kind of by accident, and it has been pulled back in recent updates. There simply is no offically allocated algorithm number yet, so official support is impossible. Also, there are quite a bit of operating systems where the most public crypto lib, openssl, has no support for SHA-2 yet. It's been implemented in openssl for ages, but for so-called 'stable' branches ages are not enough. But maybe now that it's at a 1 version they are updated real soonish now. OTOH, since we're upgrading our resolvers to do DNSSEC now anyway, we might as well upgrade them to support SHA-2 while we're at it. Jelte --------------enig163BF08A3FDE073C0DCC3588 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpw2qUACgkQ4nZCKsdOncWW1QCfWVXL+SVQFAY0jsaKyFWdUwaR MF0An1YnfWCg6dg5fibyxvh8DJsjMJYm =WzGv -----END PGP SIGNATURE----- --------------enig163BF08A3FDE073C0DCC3588-- -- to unsubscribe send a message to namedroppers-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 Jul 29 17:36:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB083A6A48; Wed, 29 Jul 2009 17:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OuQMhctldE2; Wed, 29 Jul 2009 17:36:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4300E3A693B; Wed, 29 Jul 2009 17:36:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWJY9-0008Hu-Im for namedroppers-data0@psg.com; Thu, 30 Jul 2009 00:31:13 +0000 Received: from [209.86.89.64] (helo=elasmtp-curtail.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWJY0-0008HF-SR for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 00:31:10 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ps8uf5fVdyUrZasr1aHMad2Sm3E5mxp7ylnqhqgConi8mSjGZGl1JiykkIrYwwKZ; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.143] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWJXz-0007Kw-7C; Wed, 29 Jul 2009 20:31:04 -0400 Message-ID: <4A7104D5.41CBEDEF@ix.netcom.com> Date: Wed, 29 Jul 2009 19:26:30 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Graff CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 References: <4A702AE1.10201@isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688bb7d4d20ad322d7f30a241bdf6aa2071350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.143 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Micahel and all, I agree fully here... Michael Graff wrote: > Let me state some reasons I'm opposed to this draft's purpose, even > though I think some part of it would be very interesting to pursue. > > (1) This becomes a meta-type in practice. It might prevent some > lookups initially, but should a client ask for items that were not in > the cache, the server would have to remember which algorithms it saw in > the DNSKEY response to know which it could usefully retrieve with > follow-on queries. For example, a particular stub might support more > algorithms than the cache it asks, so additional queries (including > additional queries for the DNSKEY to obtain its signatures) would have > to be generated. > > (2) This solves a problem I do not fully believe is a problem, that of > TCP fallback. I've said it before, but chat servers, web servers, and > other types of TCP-based servers handle many, many connections/sec and > many, many sustained clients today. I don't understand why DNS is > different here, excepting perhaps that we have not encountered this > situation until now. > > (3) It solves a problem that I do not fully believe is a problem, that > of fragmented packets. There is no solid solution in this proposal that > it WILL get packets through, only that it might have a better chance to > do so. Key rollover will still cause large packets and/or TCP fallback, > which means only during rollover events will badness occur. I'd rather > it occur all the time rather than only in some situations. > > (4) I believe the knowledge it would allow to be gathered -- that of > which algorithms, hashes, etc. were in common use -- is very valuable. > Perhaps a draft on "voluntary reporting of server capabilities" would be > useful, where the data would be anonymous, infrequently (order days at > least) reported, and collected into reports. Knowing that RSA/SHA1 is > not used any longer is very good information to know in terms of > deprecating protocols, but using that as a filter seems unwise to me. > > --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: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 17:44:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B453A710F; Wed, 29 Jul 2009 17:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUwpxdzqDjAZ; Wed, 29 Jul 2009 17:44:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F055D28C100; Wed, 29 Jul 2009 17:44:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWJh0-0009OM-SW for namedroppers-data0@psg.com; Thu, 30 Jul 2009 00:40:22 +0000 Received: from [209.86.89.68] (helo=elasmtp-masked.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWJgv-0009Mm-E5 for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 00:40:20 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=M7lOxA7dt+e7NWN6tj9Q4C67oXSrGsCIlUcotN2eatG0j80chYfekbdZ/O14D1lW; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.143] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWJgs-0005ju-Mb; Wed, 29 Jul 2009 20:40:15 -0400 Message-ID: <4A7106FD.45851835@ix.netcom.com> Date: Wed, 29 Jul 2009 19:35:41 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicholas Weaver CC: Rob Austein , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f3b98663d6802c6c4b0316b40b0e7fb1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.143 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nic and all, Nic, your right of course. And SHA-2 itself is already coming under pressure/getting weaker. Yet some transition method from those using SHA-1 now to SHA-2 is really necessary. A conundrum we have here indeed. I'm likely the oddball here in that for me SHA-2 is already too weak for my taste. For that matter 256bit is too weak, IMO. But I am sure that is not widely a shared opinion. Nicholas Weaver wrote: > On Jul 29, 2009, at 5:55 AM, Rob Austein wrote: > > > [Continuation of Stockholm WG session, cut off due to lack of time] > > > > My concern with the proposal to sign the root just with SHA-2 is that > > it will be years before enough of the installed base has SHA-2-capable > > DNSSEC in production. Even ignoring vendors with long development > > cycles, mainstream operators don't upgrade quickly. We're talking > > years here, not months. > > > > I think the suggestion that we start with SHA-1 then roll to SHA-2 > > makes a fair amount of sense. If algorithm roll at the root really is > > that scary, we should not wait until an emergency to try it. > > I STRONGLY disagree. Crypto only gets weaker, never stronger, and it > can get very SUDDENLY weaker. The cracks are REALLY showing in SHA-1. > > Resolvers need an update anyway in order to handle a signed root, if > only the key itself. Thus I believe it is critical to start with SHA-2. > > Signing BOTH ways doesn't solve the problem, either: you then become > vulnerable to downgrade attacks and similar problems. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 17:47:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81F23A6F27; Wed, 29 Jul 2009 17:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS39xN7cCRop; Wed, 29 Jul 2009 17:47:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD0EC3A6B9E; Wed, 29 Jul 2009 17:47:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWJlK-000A6L-P0 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 00:44:50 +0000 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWJlD-000A5Z-OW for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 00:44:47 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Kv/6CLQXiZrHTwZTjLYK/8EKNrZJaKxndf8gpCS/Z0k7grumZMxbKgepOXtpUTxk; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.143] (helo=ix.netcom.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWJlC-000105-HH; Wed, 29 Jul 2009 20:44:43 -0400 Message-ID: <4A710809.6B1D6D4B@ix.netcom.com> Date: Wed, 29 Jul 2009 19:40:09 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rose, Scott W." CC: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606884605140e013b126434c7de661b3c1ff7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.143 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Scott and all I'd be very happy too if it's stronge enough and a transition period and process is excepted. A difficult task to accomplish in so broad a consideration though. But doable if cooperation is avaliable. "Rose, Scott W." wrote: > On 7/29/09 9:07 AM, "Patrik Faltstrom" wrote: > >> > >> I think the suggestion that we start with SHA-1 then roll to SHA-2 > >> makes a fair amount of sense. If algorithm roll at the root really is > >> that scary, we should not wait until an emergency to try it. > > > > FWIW: This makes sense to me. > > > > What we do need is, for pure interoperability reasons, _one_ algorithm > > that is "the algorithm that is in use", and then a mechanism for > > rollover algorithms when needed. > > > I would agree with this, but different groups have opinions about what > should be "the" algorithm in use. That will hamper DNSSEC deployment in > some areas. If that can be worked out to one agreed upon algorithm, I'd be > very happy. ;-) > > Scott > > > I would argue strongly against mechanisms that enable what would be a > > terrible tragedy of the commons, which would be simultaneously use of > > unlimited number of algorithms. > > > > paf > > > > =================================== > Scott Rose > NIST > scottr@nist.gov > ph: +1 301-975-8439 > 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: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 18:09:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04B83A6A38; Wed, 29 Jul 2009 18:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCnojtUnrEgF; Wed, 29 Jul 2009 18:09:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEB9A28C113; Wed, 29 Jul 2009 18:08:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWK45-000Cf6-Tn for namedroppers-data0@psg.com; Thu, 30 Jul 2009 01:04:13 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWK41-000Cec-WA for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 01:04:11 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=HGXCODQhUARQaMn3TnTGl5fl3+8nk904ptbb8m1MADpBC2MOmuwlZ8GDmv3eBVVI; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.143] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWK3y-0002Sb-OV; Wed, 29 Jul 2009 21:04:07 -0400 Message-ID: <4A710C95.D51230@ix.netcom.com> Date: Wed, 29 Jul 2009 19:59:33 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicholas Weaver CC: Paul Wouters , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f9b72ad66b1c76839fa0c0daee4dc51e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.143 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nic and all, SHA-1 should not in all instances have been revoked by the USG. None the less it has been broken some time ago now and for practical highly sensitive purposes should not be used or excepted. Yet for other uses not as sensitive to or by the USG I see no reason it cannot still be used and accepted, with a proviso that such has an expiration date of same use. Nicholas Weaver wrote: > On Jul 29, 2009, at 11:36 AM, Paul Wouters wrote: > > Read further: > > > Cameron McDonald, Philip Hawkes and Josef Pieprzyk presented a hash > > collision attack with complexity 2^52 at the Rump session of > > Eurocrypt 2009[28]. > > That is, to my mind, BROKEN. 2^52 for collision generation (it should > be 2^80) is a big big deal. > > These are the symptoms seen before MD5 fell completely. > > And SHA1 has already been revoked by NIST for government use: > > http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html > http://csrc.nist.gov/groups/ST/toolkit/documents/shs/NISTHashComments-final.pdf > > > Federal agencies should stop using SHA-1 for digital signatures, > > digital time stamping and other applications that require collision > > resistance as soon as practical, and must use the SHA-2 family of > > hash functions for these applications after 2010. After 2010, > > Federal agencies may use SHA-1 only for the following applications: > > hash-based message authentication codes (HMACs); key derivation > > functions (KDFs); and random number generators (RNGs). Regardless of > > use, NIST encourages application and protocol designers to use the > > SHA-2 family of hash functions for all new applications and protocols. > > SHA1 is dead, that you guys are even CONSIDERING SHA-1 for the root > signature for DNSSEC is frankly, silly. SHA1 has been considered dead > since 2006 in the eyes of NIST. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 23:15:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31AF3A6DC8; Wed, 29 Jul 2009 23:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJI2wRd8E45a; Wed, 29 Jul 2009 23:15:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E010C3A6B32; Wed, 29 Jul 2009 23:15:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWOpY-0007SX-5F for namedroppers-data0@psg.com; Thu, 30 Jul 2009 06:09:32 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWOpT-0007Rk-DO for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 06:09:29 +0000 Received: from [10.20.30.158] ([77.241.97.116]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U69MR3029327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jul 2009 23:09:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A70DAA2.706@NLnetLabs.nl> References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <4A70DAA2.706@NLnetLabs.nl> Date: Thu, 30 Jul 2009 07:58:24 +0200 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:26 AM +0200 7/30/09, Jelte Jansen wrote: >None of the DNSSEC validators support RSA/SHA-2 at the moment. One had >it, but kind of by accident, and it has been pulled back in recent >updates. There simply is no offically allocated algorithm number yet, so >official support is impossible. Got it. Then, no, it is inappropriate to sign any zone, much less the root, with RSA/SHA2 for the foreseeable future. Before the root is signed with RSA/SHA2, a lot of testing will need to be done to determine the level of support for the algorithm in resolvers. This is truly sad. I hummed (possibly too loudly) for signing with RSA/SHA2. Having said that, there are no known threats against signing the root with RSA/SHA1. The operational hurt of the algorithm rollover will be a black eye for this community, one that could have hopefully been avoided. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 23:16:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A879B3A6AA0; Wed, 29 Jul 2009 23:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYrMBqUMr3l8; Wed, 29 Jul 2009 23:16:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79F9E3A7160; Wed, 29 Jul 2009 23:16:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWOpj-0007TU-He for namedroppers-data0@psg.com; Thu, 30 Jul 2009 06:09:43 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWOpZ-0007Sg-Au for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 06:09:40 +0000 Received: from [10.20.30.158] ([77.241.97.116]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U69MR7029327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 23:09:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> Date: Thu, 30 Jul 2009 08:09:20 +0200 To: Nicholas Weaver From: Paul Hoffman Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Cc: Nicholas Weaver , IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:13 PM -0700 7/29/09, Nicholas Weaver wrote: >On Jul 29, 2009, at 1:42 PM, Paul Hoffman wrote: >>I cannot speak for Olafur, but I would guess that when he asked for references, he meant ones that were relevant to this WG and supported your statements, not just random URLs about somewhat related topics. > > > >http://csrc.nist.gov/groups/ST/hash/statement.html Um, following a complaint about random URLs with another one is not necessarily a good way to enlighten the WG. >When NIST says "Don't do it, it may be hazardous", back in 2006! thats usually a good indication that an algorithm should not be used. ...but only if you read what they actually said. Sorry to be so repetitive, but there are different uses for hashes, and each has its own security threats. If you lump all of them together, you will get the wrong result. > SHA-1 is revoked for federal use effective Dec 31, 2010. No, it is not. It is prohibited *for some uses*, including signing when the signer does not control the material being signed. >Worse, there is an additional condition proposed: >d: Will be able to quickly transition to SHA-2 if a crisis > actually occurs Please carefully define what would cause a crisis for DNSSEC with respect to SHA-1. Using that careful definition, look at the rest of the world's use of SHA-1 in places where a similar attack could happen. Then explain why anyone would give a rodent's patootie about our problems relative to, say, the entire banking sector, protection of physical resources, and so on. >This discussion I find, frankly, bizarre. Ah! A point of agreement! --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 29 23:35:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B1E3A6A1E; Wed, 29 Jul 2009 23:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=-0.868, 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 kTNmgrh-1406; Wed, 29 Jul 2009 23:35:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEA023A68E3; Wed, 29 Jul 2009 23:34:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWP9w-000BLU-He for namedroppers-data0@psg.com; Thu, 30 Jul 2009 06:30:36 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWP9r-000BKV-2w for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 06:30:34 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6U6U6SR004035; Thu, 30 Jul 2009 02:30:07 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200907300630.n6U6U6SR004035@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 30 Jul 2009 02:29:39 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson/DNSEXT chair Subject: [dnsext] Additions to the draft charter Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_2279908==_" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --=====================_2279908==_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Since the last version of the charter (attached) was posted for IETF= reviews, we have had some discussion on the mailing list=20 that the charter is too restrictive or there are current items that should be in the charter. This was discussed in the WG meeting yesterday. There are 3 topics that have asked for inclusion: IXFR-ONLY DNS guide to DNS RFC's DNSKEY alg support option [1] As of this moment only the second one has more than 5 volunteers. I need to give our AD an updated draft of the charter RSN, thus any work item that does NOT have 5 statements of support by Friday evening (Stockholm) will not be included in the charter IESG will review next week. If you oppose the documents please voice that as well. If you think you have volunteered please drop us[2] a private message to confirm. If items are added to charter the milestones for the items will have dates in March 2010, to be updated later. EDNS0bis document milestone will be added with milestone of Dec 2009. The working group is considering to investigate further the problem space of "retrieving address records for multiple network=20 protocols", there is a proposal in this space http://tools.ietf.org/id/draft-li-dnsext-ipv4-ipv6-01.txt. This might become a future charter item but not at this time. Sorry for the short notice Olafur [1] Patrik F=E4ltstr=F6m has been appointed "special=20 master" to judge the support for this item. [2] chairs + Patrik =20 --=====================_2279908==_ Content-Type: text/plain; name="charter-20090624.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="charter-20090624.txt" CTx2ZXJzaW9uIDIwMDkwNjIzPiAKClRoZSBETlMgaGFzIGEgbGFyZ2UgaW5zdGFsbGVkIGJhc2Ug YW5kIHJlcGVydG9pcmUgb2YgcHJvdG9jb2wKc3BlY2lmaWNhdGlvbnMuIFRoZSBETlNFWFQgV0cg Z3JvdXAgd2lsbCBhY3RpdmVseSBhZHZhbmNlIEROUwpwcm90b2NvbC1yZWxhdGVkIFJGQ3Mgb24g dGhlIHN0YW5kYXJkcyB0cmFjayB3aGlsZSB0aG9yb3VnaGx5CnJldmlld2luZyBmdXJ0aGVyIHBy b3Bvc2VkIGV4dGVuc2lvbnMuIFRoZSBzY29wZSBvZiB0aGUgRE5TRVhUIFdHIGlzCmNvbmZpbmVk IHRvIHRoZSBETlMgcHJvdG9jb2wsIHBhcnRpY3VsYXJseSBjaGFuZ2VzIHRoYXQgYWZmZWN0IERO Uwpwcm90b2NvbHMgIm9uIHRoZSB3aXJlIiBvciB0aGUgaW50ZXJuYWwgcHJvY2Vzc2luZyBvZiBE TlMgZGF0YS4gRE5TCm9wZXJhdGlvbnMgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhlIFdHLgoKVGhl IFdHIHdpbGwgbGltaXQgaXRzZWxmIHRvIHJldmlldyBvZiBwcm9wb3NhbHMgZm9yIG5ldyBleHRl bnNpb25zCmFuZCBjbGFyaWZpY2F0aW9uIHRvIHRoZSBETlMgcHJvdG9jb2wsIGluY2x1ZGluZyBE TlNTRUMuIEFkb3B0aW9uIG9mCm5ldyB3b3JrIHRhcmdldGVkIGZvciBzdGFuZGFyZHMgdHJhY2sg d2lsbCByZXF1aXJlIGNoYW5nZXMgdG8gdGhpcwpjaGFydGVyLgoKVGhlIHdvcmtpbmcgZ3JvdXAg Y2FuIG5ldmVydGhlbGVzcyB1bmRlcnRha2Ugd29yayBpbiBmb2xsb3dpbmcKc3ViamVjdHMgd2l0 aG91dCBhIGNoYXJ0ZXIgY2hhbmdlOgoJRE5TU0VDIGFuZCBUU0lHL1RLRVkgYWxnb3JpdGhtIG1h aW50ZW5hbmNlCglIYXJkZW5pbmcgRE5TIHByb3RvY29sIGFuZCBwcm92aWRpbmcgZ3VpZGFuY2Ug dG8gaW1wbGVtZW50b3JzCglFeGFtaW5pbmcgdHJhbnNwb3J0IHByb3RvY29scyBwb3NzaWJseSBh ZGRpbmcgbmV3IG9uZXMuCglBZHZhbmNpbmcgZXhpc3RpbmcgUHJvcG9zZWQgU3RhbmRhcmQgUkZD cyB0byBEcmFmdC9GdWxsIFN0YW5kYXJkCglPYnNvbGV0aW5nIFJGQ3MuCgpCZWZvcmUgZm9ybWFs IGFkb3B0aW9uIG9mIGFueSBzdWNoIGl0ZW1zIGF0IGxlYXN0IDUgd29ya2luZyBncm91cApwYXJ0 aWNpcGFudHMgbXVzdCBwdWJsaWNseSBzdGF0ZSB0aGF0IHRoZSBpdGVtIGlzIHdpdGhpbiBjaGFy dGVyIGFuZCBpcwp3b3J0aHdoaWxlIGl0ZW0gZm9yIGZ1cnRoZXIgc3R1ZHkuCgpUaGUgRE5TRVhU IFdHIHdpbGwgY29uZHVjdCB0aGUgc3BlY2lmaWVkIFJGQzUzOTUgcmV2aWV3IG9mIFJSCnRlbXBs YXRlcyBhcyB0aGV5IGFyZSBwb3N0ZWQsIGFuZCBFRE5TMCBPcHRpb24gdGVtcGxhdGVzIGlmIEVE TlMwLWJpcwp1cGRhdGVzIHJlZ2lzdHJhdGlvbiByZXF1aXJlbWVudHMuCgpUaGUgV0cgd2lsbCBy ZXZpZXcgRE5TIHByb3RvY29sIHJlbGF0ZWQgd29yayB3aGljaCBtYXkgb3JpZ2luYXRlCmVsc2V3 aGVyZSBpbiB0aGUgSUVURiwgaW5jbHVkaW5nIEFELXNwb25zb3JlZCBzdWJtaXNzaW9ucyBvciBk cmFmdHMKaW4gb3RoZXIgd29ya2luZyBncm91cC4gVGhlIFdHIGRvZXMgbm90IGludGVuZCB0byBo b2xkIGZhY2UgdG8gZmFjZQptZWV0aW5ncywgdGhvdWdoIG1heSBkbyBzbyBpZiBkZWVtZWQgbmVj ZXNzYXJ5IGZvciByZXNvbHV0aW9uIG9mIGEKc3BlY2lmaWMgaXNzdWUgYXQgaGFuZC4gCgoKTWls ZXN0b25lczoKSnVsICAyMDA5ICBUU0lHL01ENSBPYnNvbGV0aW5nIHRvIElFU0cuIApKdWwgIDIw MDkgIFJTQS9TSEEyNTYgdG8gSUVTRy4gCkF1ZyAgMjAwOSAgQVhGUiBDbGFyaWZ5ICB0byBJRVNH LgpTZXAgIDIwMDkgIEVETlMwIFBpbmcgT3B0aW9uIGFkdmFuY2VkIHRvIElFU0cgCk9jdCAgMjAw OSAgUmVzb2x2ZXIgc2lkZSBGb3JnZXJ5IFJlc2lsaWVuY2UgYWR2YW5jZWQgdG8gSUVTRwpPY3Qg IDIwMDkgIEROU1NFQyBFcnJhdGEgZG9jdW1lbnQgdG8gSUVTRyAKTm92ICAyMDA5ICBHT1NUIERO U0tFWSBhbmQgRFMgc3VwcG9ydCBhZHZhbmNlZCB0byBJRVNHCkRlYyAgMjAwOSAgRUROUzAtYmlz IHVwZGF0ZSBhZHZhbmNlZCB0byBJRVNHIApGZWIgIDIwMTAgIEROUyBleGlzdGluZyB0cmFuc3Bv cnQgcHJvdG9jb2wgcmVjb21tZW5kYXRpb25zL2NsYXJpZmljYXRpb25zICB0byBJRVNHIApKdW4g IDIwMTAgIEROUyA8bmV3PiB0cmFuc3BvcnQgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiAKCg== --=====================_2279908==_-- -- to unsubscribe send a message to namedroppers-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 Jul 29 23:59:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE313A693F; Wed, 29 Jul 2009 23:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U07kMMhUwKbL; Wed, 29 Jul 2009 23:59:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B73D28B23E; Wed, 29 Jul 2009 23:59:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWPYC-000FdK-R9 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 06:55:40 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWPY8-000Fcu-Sx for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 06:55:38 +0000 Received: from dhcp-10e1.meeting.ietf.org (dhcp-10e1.meeting.ietf.org [130.129.16.225]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6U6tRTl088320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jul 2009 08:55:28 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Cc: namedroppers@ops.ietf.org Message-Id: From: Olaf Kolkman To: Rob Austein In-Reply-To: <20090729125501.C9A697358A@khazad-dum.hactrn.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-46771574" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 08:55:11 +0200 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [213.154.224.1]); Thu, 30 Jul 2009 08:55:28 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-46771574 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 29 jul 2009, at 14:55, Rob Austein wrote: > Even ignoring vendors with long development > cycles, mainstream operators don't upgrade quickly. We're talking > years here, not months. I would think that folk who configure DNSSEC to use the roots trust- anchor would be doing that with up-to-date software and as such the deployment of DNSSEC is a forcing function towards a new upgrade cycle and SHA256 piggybacks along. I could be easily convinced that that is a bad (somewhat naive) assumption. --Olaf --Apple-Mail-1-46771574 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkpxQ88ACgkQtN/ca3YJIoeqeACg2Ic4btQXZGilDpWVSUpBtBhC 6McAoOkuWnkeaNGf8ZMXHKQCTRMy01R1 =scww -----END PGP SIGNATURE----- --Apple-Mail-1-46771574-- -- to unsubscribe send a message to namedroppers-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 Jul 30 00:14:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29FF3A6BC7; Thu, 30 Jul 2009 00:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z2ybgGsh1+7; Thu, 30 Jul 2009 00:14:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6774828C156; Thu, 30 Jul 2009 00:14:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWPmS-000Hu7-M7 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 07:10:24 +0000 Received: from [209.85.220.227] (helo=mail-fx0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWPmN-000Hsm-W0 for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 07:10:22 +0000 Received: by fxm27 with SMTP id 27so140590fxm.11 for ; Thu, 30 Jul 2009 00:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dPUupCyTs2NliUitCm6qMknBIW3APUPS/c5mj+YpihM=; b=kkkDLB16GCCbxTNfnCs0J1v462qeC4wwWdO9IaGFZg+cX25pnLYJmfxskgLUetvrAc 9ZWXWi5ArraQqY71Q8X9SHvMdAgtj6o6Oo1qyxjVpVhvA3amo8YWj+K6Y9XApuJwgSFQ yHM0DJxqHrNInyeMulTLQr3kOJL+kQjzdVR7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ruuyp9+a+D0pn5gMuEvQhLLqaXJj+jCxBhb7j5DjgSBRdtjmULiT4vps5lp6gv/aRK ebX6lNReZ6q+IuF3tzp/kDhVoP37DUETKLaa5tbkNXx+sS9w8jxQy+vFjSAHuJEuqZjo iQX2ETfXafUMHg9hzB0/6h1KBIh6fAKljZEO4= Received: by 10.103.242.4 with SMTP id u4mr425191mur.125.1248937818269; Thu, 30 Jul 2009 00:10:18 -0700 (PDT) Received: from dhcp-1678.meeting.ietf.org (dhcp-1678.meeting.ietf.org [130.129.22.120]) by mx.google.com with ESMTPS id 12sm10257273muq.52.2009.07.30.00.10.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 00:10:17 -0700 (PDT) Message-ID: <4A714758.2090902@gmail.com> Date: Thu, 30 Jul 2009 09:10:16 +0200 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Paul Hoffman CC: Nicholas Weaver , IETF DNSEXT WG Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7/30/09 8:09 AM, Paul Hoffman wrote: > At 2:13 PM -0700 7/29/09, Nicholas Weaver wrote: >> Worse, there is an additional condition proposed: d: Will be able >> to quickly transition to SHA-2 if a crisis actually occurs > > Please carefully define what would cause a crisis for DNSSEC with > respect to SHA-1. Using that careful definition, look at the rest of > the world's use of SHA-1 in places where a similar attack could > happen. Then explain why anyone would give a rodent's patootie about > our problems relative to, say, the entire banking sector, protection > of physical resources, and so on. A possible crisis could be caused by a requirement for significantly more resources needed to support the algorithm roll-over, especially early in the DNSSEC learning curve. This might be mitigated by a new signature selection parameter. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 00:59:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E163A716F; Thu, 30 Jul 2009 00:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=-1.644, 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 krEPrMlQ7Blm; Thu, 30 Jul 2009 00:59:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C77823A69A0; Thu, 30 Jul 2009 00:58:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWQSt-000Oj7-DM for namedroppers-data0@psg.com; Thu, 30 Jul 2009 07:54:15 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWQSo-000Oh6-L7 for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 07:54:13 +0000 X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPnucEqrR7O6/2dsb2JhbAC5VognkBEFhBE X-IronPort-AV: E=Sophos;i="4.43,293,1246838400"; d="sig'?scan'208";a="180494251" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2009 07:54:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6U7s9q4004688 for ; Thu, 30 Jul 2009 00:54:09 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6U7s7pA008268 for ; Thu, 30 Jul 2009 07:54:09 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 09:54:09 +0200 Received: from dhcp-17cb.meeting.ietf.org ([10.61.104.90]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 09:54:08 +0200 Message-Id: <583565A9-886F-41FB-92EA-B9F3E6741A7C@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "namedroppers@ops.ietf.org WG" Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-96-50308259" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time please! Date: Thu, 30 Jul 2009 09:54:07 +0200 X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jul 2009 07:54:08.0608 (UTC) FILETIME=[EB17D600:01CA10EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2093; t=1248940450; x=1249804450; c=relaxed/simple; s=sjdkim2002; 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:=20draft-crocker-dnssec-algo-signal-03=20--=20more =20time=20please! |Sender:=20; bh=fImU1/TYyF88nibpuYz2pXU7iSsqwltUTp26N9uHBbE=; b=llUKPi5ZOA4NsPI8e0MXmODt/o2KWGWdD/IJqibmp8NzyzlH4wL+/nXi4T NQObezP0ChYIo911gGs/o1MDxGG9AxxXjGX++QxVfRLftdNU1bVc65MtEAXy woUIlbIraZ; Authentication-Results: sj-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-96-50308259 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit A status report... People are still reaching out to me, and it is pretty clear to me that many people have problems answering yes or no to the question, and that seems to be similar reasons as both yes and no people want to talk so much about the issue. I will next week summarize in a bit more detail, but it seems people have the feeling that as the overall goal for standards in the IETF is interoperability, and the question is really what impact multiple algorithms have on real life interoperability. How are the algorithms selected? What if everyone "just pick" a favorite? If we are going to have preferred algorithms, how do we shift in and shift out algorithms in that pool (that might have only one entry)? How do we roll over algorithms? Etc... Everyone (almost) I have talked with think that if we only talked about the real problem, then most certainly one of the things that will be needed is some kind of signalling, for example in the transition from one algorithm to another, but at this point in time -- that is impossible to say. So at the moment, I see the consensus in the wg is "not yet, we need to work on other documents first, or at least in parallell". But, I at the same time think I have been contacted by "no" sayers more than "yes" sayers, so I ask the wg chairs for another week of work on what my findings on what the consensus of the wg is. Patrik --Apple-Mail-96-50308259 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) iD8DBQFKcVGfvHlR2X0luNwRArRtAJ440tc/BQbamkmuKm1Jhfhx2ZFuqgCfWbZb Yn8TtLKfdfhi71QGDVbvmao= =m94Z -----END PGP SIGNATURE----- --Apple-Mail-96-50308259-- -- to unsubscribe send a message to namedroppers-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 Jul 30 01:22:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7466528C1F8; Thu, 30 Jul 2009 01:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVMO2wLR9vny; Thu, 30 Jul 2009 01:22:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BF5528C202; Thu, 30 Jul 2009 01:22:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWQq8-0003Jw-HL for namedroppers-data0@psg.com; Thu, 30 Jul 2009 08:18:16 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWQq2-0003Hv-Nj for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 08:18:14 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=pOcrHAqZQzaPzD2BYtB1B6zL+fpVqyoljZGVa75LwxeEwcBc6/mJXxLMOJ90E4fMkD/vPwiIx2mn9qx77gn/5BxAvUF4KUEprhK6K29MmjQqIj/tA4RDnTWvQrgSaftu; Received: from [78.64.88.87] (helo=host-78-64-88-87.homerun.telia.com) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWQoY-000PEz-Si; Thu, 30 Jul 2009 08:16:40 +0000 Cc: Paul Hoffman , Nicholas Weaver , IETF DNSEXT WG Message-Id: <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> From: Joe Abley To: Doug Otis In-Reply-To: <4A714758.2090902@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 10:16:36 +0200 References: <20090729125501.C9A697358A@khazad-dum.hactrn.net> <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 30-Jul-2009, at 09:10, Doug Otis wrote: > A possible crisis could be caused by a requirement for significantly > more resources needed to support the algorithm roll-over, especially > early in the DNSSEC learning curve. This might be mitigated by a new > signature selection parameter. I think we must assume that an algorithm roll will be necessary at some point in the future, regardless of whether it is RSA/SHA-1 to RSA/ SHA-2. So choosing RSA/SHA-2 at day zero does not help us avoid work on algorithm rollover, but it does perhaps defer that work (on the grounds that RSA/SHA-2 is likely to be safe for longer than RSA/SHA-1). The mechanics of an algorithm rollover will surely require some consideration and testing, from an operational perspective if not a protocol perspective. However, the NTIA has expressed publicly a goal of having the root signed by the end of 2009. Even if that date slips, I think the detailed planning that the community surely expects to be done for that work will require the protocol to be used to be specified far earlier than that, before anybody can have clear knowledge about the timelines for RSA/SHA-2 codepoint assignment, implementation or deployment. Is it reasonable to think that an RSA/SHA-2 code-point could be assigned and that code could be released, tested and deployed early enough to allow planning for its use by the end of 2009? If the answer is no, then perhaps we have an answer. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 02:35:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E8728C19B; Thu, 30 Jul 2009 02:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsVhgZBnt1lB; Thu, 30 Jul 2009 02:35:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DB7028C19A; Thu, 30 Jul 2009 02:35:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWRyW-000EjV-03 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 09:31:00 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWRyQ-000EiC-Uk for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 09:30:56 +0000 Received: from crankycanuck.ca (host-78-64-88-52.homerun.telia.com [78.64.88.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EB3682FE8ED5 for ; Thu, 30 Jul 2009 09:30:52 +0000 (UTC) Date: Thu, 30 Jul 2009 05:30:50 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090730093050.GB11490@shinkuro.com> References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 30, 2009 at 10:16:36AM +0200, Joe Abley wrote: > Is it reasonable to think that an RSA/SHA-2 code-point could be assigned > and that code could be released, tested and deployed early enough to > allow planning for its use by the end of 2009? This is a good question (indeed, the right one, I think). I will be sending the SHA-2 draft to the IESG soon (I need to complete the writeup. I'm working on that today, as it happens). Then it needs to go to IETF last call. It is hard to predict whether we will get exploration of various ratholes about whether DNSSEC is a good idea, whether SHA-256 is ok, &c. during that last call. We've also been warned that the specification of SHA-512 in there might result in some heartburn; the editor decided to leave that alone because, on balance, he felt (and I agreed) that more delay was a bad thing. So I cannot say whether the code would be released in time for the planned use date. But I don't think one should anticipate a code point actually being assigned for this purpose until at least September. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 04:11:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166BC28C17B; Thu, 30 Jul 2009 04:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcraRsyavuls; Thu, 30 Jul 2009 04:11:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 092893A7184; Thu, 30 Jul 2009 04:11:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTSE-00036Z-0M for namedroppers-data0@psg.com; Thu, 30 Jul 2009 11:05:46 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTS1-00034Q-Gj for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 11:05:41 +0000 Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:16:216:6fff:fe46:b75d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8A37AE606E; Thu, 30 Jul 2009 11:05:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6UB5TDp016733; Thu, 30 Jul 2009 21:05:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907301105.n6UB5TDp016733@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 In-reply-to: Your message of "Thu, 30 Jul 2009 05:30:50 -0400." <20090730093050.GB11490@shinkuro.com> Date: Thu, 30 Jul 2009 21:05:29 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090730093050.GB11490@shinkuro.com>, Andrew Sullivan writes: > On Thu, Jul 30, 2009 at 10:16:36AM +0200, Joe Abley wrote: > > Is it reasonable to think that an RSA/SHA-2 code-point could be assigned > > and that code could be released, tested and deployed early enough to > > allow planning for its use by the end of 2009? > > This is a good question (indeed, the right one, I think). For those validators that are NSEC3 aware already it should be no more than a afternoon's work to add support. There are plenty of sha2 implementations that can be picked up if they don't already have a sha2 implementation for TSIG. For validators that arn't NSEC3 aware there is a enourmous amount of work involved. > I will be sending the SHA-2 draft to the IESG soon (I need to complete > the writeup. I'm working on that today, as it happens). Then it > needs to go to IETF last call. It is hard to predict whether we will > get exploration of various ratholes about whether DNSSEC is a good > idea, whether SHA-256 is ok, &c. during that last call. We've also > been warned that the specification of SHA-512 in there might result in > some heartburn; the editor decided to leave that alone because, on > balance, he felt (and I agreed) that more delay was a bad thing. > > So I cannot say whether the code would be released in time for the > planned use date. But I don't think one should anticipate a code > point actually being assigned for this purpose until at least > September. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 04:15:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D6B28C193; Thu, 30 Jul 2009 04:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJO9HcZNQ2hO; Thu, 30 Jul 2009 04:15:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCB7328C1C9; Thu, 30 Jul 2009 04:14:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTXB-0003ow-8F for namedroppers-data0@psg.com; Thu, 30 Jul 2009 11:10:53 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTX7-0003o2-0o for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 11:10:51 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=aS64pfU07aguBIzN/vxTq5ZQfKYZ6X+tE4hvh1n7ozxUfNhBYqzmCRkFM6moFnvzRX8mFzptFo2Od+06Gj7bl5zLoejRcK6+M6GLOzQNMZNVPhiXimp8O18svSiADRwn; Received: from [130.129.87.217] (helo=dhcp-57d9.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTVr-0000wA-Vt; Thu, 30 Jul 2009 11:09:32 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> From: Joe Abley To: Andrew Sullivan In-Reply-To: <20090730093050.GB11490@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 13:09:30 +0200 References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 30-Jul-2009, at 11:30, Andrew Sullivan wrote: > So I cannot say whether the code would be released in time for the > planned use date. But I don't think one should anticipate a code > point actually being assigned for this purpose until at least > September. This suggests two options with respect to signing the root, then: 1. Sign with RSA/SHA-1 on current schedule; 2. Defer signing of the root until 2010/2011/2012 (depending on implementation and deployment in the validator population) and use RSA/ SHA-2. Are those the two options available to us, in practical terms, or am I missing others? Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 04:27:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC163A6FF5; Thu, 30 Jul 2009 04:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdpR-1vx6xlI; Thu, 30 Jul 2009 04:27:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 468333A6C60; Thu, 30 Jul 2009 04:27:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTiv-0005sf-9w for namedroppers-data0@psg.com; Thu, 30 Jul 2009 11:23:01 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWTir-0005rJ-Cn for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 11:22:59 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n6UAaNa1002174; Thu, 30 Jul 2009 10:36:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n6UAa8P9002168; Thu, 30 Jul 2009 10:36:08 GMT Date: Thu, 30 Jul 2009 10:36:08 +0000 From: bmanning@vacation.karoshi.com To: Paul Wouters Cc: bert hubert , namedroppers@ops.ietf.org Subject: [dnsext] dnssec-algo-signal & Roy Message-ID: <20090730103608.GA2156@vacation.karoshi.com.> References: <4A702AE1.10201@isc.org> <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 29, 2009 at 06:34:45PM -0400, Paul Wouters wrote: > On Wed, 29 Jul 2009, bert hubert wrote: > > >It may be that my state of mind is influenced by trying to implement > >NSEC3 processing - but when that is done, I don't think my opinion of > >DNSSEC complexity, and it being too complex already, is going to > >change. > > It grows on you. Having dinner with Roy helps too. > > Paul > Roy doesn't scale. :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 05:00:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8911F3A69DF; Thu, 30 Jul 2009 05:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEOnwlRnuKBA; Thu, 30 Jul 2009 05:00:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BD903A68A9; Thu, 30 Jul 2009 05:00:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUEd-000B4o-KF for namedroppers-data0@psg.com; Thu, 30 Jul 2009 11:55:47 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUEX-000B40-UX for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 11:55:45 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=XWoAgqoWL+o9f/HLY5wevk0lywm0YhytM8A8mNGJ9xGK+LIJgJj0N2X8q7npc251W/vjtP+8y8AbdupoKKus39Xmwignodh32btp8ug0yLzhPmpxSWRJPdP+ZN5G446j; Received: from [130.129.87.217] (helo=dhcp-57d9.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUEU-0001Mh-W0; Thu, 30 Jul 2009 11:55:39 +0000 Cc: Michael Graff , namedroppers@ops.ietf.org Message-Id: <366FFEDE-0861-436B-9536-A3A292EB4126@hopcount.ca> From: Joe Abley To: bert hubert In-Reply-To: <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Thu, 30 Jul 2009 13:55:37 +0200 References: <4A702AE1.10201@isc.org> <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 29-Jul-2009, at 23:35, bert hubert wrote: > On Wed, Jul 29, 2009 at 12:56 PM, Michael Graff wrote: >> Let me state some reasons I'm opposed to this draft's purpose, even >> though I >> think some part of it would be very interesting to pursue. > > To add my reason why I'm opposed to this draft (versus its purpose): > The complexity of DNSSEC is already of such stunning magnitude that > almost anything that makes it even more complex, better have an earth > shatteringly good reason going for it. I think we either need to be prepared to roll algorithms in the future, or we don't. If we do, then I think it's reasonable to think that in some cases an algorithm roll will be mandated because of a perceived weakness in one algorithm, and that the replacement algorithm may not be as widely deployed as the weak algorithm. If we accept these points, then I think there's an operational need to be able to measure deployment of the new algorithm. This was Steve's point in his presentation yesterday, I think. I don't think the fall from grace of an algorithm will shatter the earth, but it seems like something we should be prepared to do well. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 05:22:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C143A6818; Thu, 30 Jul 2009 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.546 X-Spam-Level: X-Spam-Status: No, score=-101.546 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 q7j1re9rLffL; Thu, 30 Jul 2009 05:22:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17B213A680B; Thu, 30 Jul 2009 05:22:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUZo-000ES2-Eu for namedroppers-data0@psg.com; Thu, 30 Jul 2009 12:17:40 +0000 Received: from [207.97.245.155] (helo=smtp155.iad.emailsrvr.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUZk-000ER9-Ox for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 12:17:38 +0000 Received: from relay25.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id D42411B4015; Thu, 30 Jul 2009 08:17:35 -0400 (EDT) Received: by relay25.relay.iad.mlsrvr.com (Authenticated sender: schnizlein-AT-isoc.org) with ESMTPSA id 43F871B4004; Thu, 30 Jul 2009 08:17:35 -0400 (EDT) Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <7B2278E1-2A58-43CA-A84E-68C0DCBC1C9A@isoc.org> From: John Schnizlein To: Joe Abley In-Reply-To: <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> Content-Type: multipart/alternative; boundary=Apple-Mail-2-66113762 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 14:17:33 +0200 References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-2-66113762 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009Jul30, at 1:09 PM, Joe Abley wrote: > > On 30-Jul-2009, at 11:30, Andrew Sullivan wrote: > >> So I cannot say whether the code would be released in time for the >> planned use date. But I don't think one should anticipate a code >> point actually being assigned for this purpose until at least >> September. > > This suggests two options with respect to signing the root, then: > > 1. Sign with RSA/SHA-1 on current schedule; > > 2. Defer signing of the root until 2010/2011/2012 (depending on > implementation and deployment in the validator population) and use > RSA/SHA-2. > > Are those the two options available to us, in practical terms, or am > I missing others? Signing with SHA-1 and then with SHA-2 as soon as it has a code point would enable cautious validators to do just SHA-2 at their earliest convenience. Having both would be the first part of the rollover anyway, wouldn't it? John --Apple-Mail-2-66113762 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

On 2009Jul30, at = 1:09 PM, Joe Abley wrote:

On = 30-Jul-2009, at 11:30, Andrew Sullivan wrote:

So I cannot say whether the code would be released in time = for the
planned use date. =  But I don't think one should anticipate a = code
point actually being = assigned for this purpose until at least
September.

This suggests two options = with respect to signing the root, then:

1. Sign with RSA/SHA-1 on = current schedule;

2. Defer signing of the root until = 2010/2011/2012 (depending on implementation and deployment in the = validator population) and use RSA/SHA-2.

Are those the two = options available to us, in practical terms, or am I missing = others?

Sign= ing with SHA-1 and then with SHA-2 as soon = as it has a code point would enable cautious validators to do just SHA-2 = at their earliest convenience. =  Having both would be the first part of the = rollover anyway, wouldn't it? =  

John
= --Apple-Mail-2-66113762-- -- to unsubscribe send a message to namedroppers-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 Jul 30 05:30:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB463A6C3D; Thu, 30 Jul 2009 05:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.733 X-Spam-Level: X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wPYi8SVr8KP; Thu, 30 Jul 2009 05:30:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3420B28C260; Thu, 30 Jul 2009 05:29:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUho-000Fou-K1 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 12:25:56 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUhk-000FoC-6E for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 12:25:54 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 816DB327A85; Thu, 30 Jul 2009 12:25:51 +0000 (UTC) Received: from [130.129.23.145] (dhcp-1791.meeting.ietf.org [130.129.23.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id E476E327A84; Thu, 30 Jul 2009 12:25:49 +0000 (UTC) References: <4A702AE1.10201@isc.org> <3efd34cc0907291435x24ed85f3yf94093be19ef4540@mail.gmail.com> <366FFEDE-0861-436B-9536-A3A292EB4126@hopcount.ca> Message-Id: <31387FBB-4394-4285-BB63-46AB47828158@isc.org> From: Michael Graff To: Joe Abley In-Reply-To: <366FFEDE-0861-436B-9536-A3A292EB4126@hopcount.ca> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Thu, 30 Jul 2009 14:25:46 +0200 Cc: bert hubert , "namedroppers@ops.ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: As long as it is statistical that's good. If it is used to filter rrsigs I feel that is bad. That is all. A protocol to announce to some group once a month or something basic capabilities would be nice. Measured deployments of new and old protocols would really help decision making. --Michael On Jul 30, 2009, at 13:55, Joe Abley wrote: > > On 29-Jul-2009, at 23:35, bert hubert wrote: > >> On Wed, Jul 29, 2009 at 12:56 PM, Michael Graff >> wrote: >>> Let me state some reasons I'm opposed to this draft's purpose, >>> even though I >>> think some part of it would be very interesting to pursue. >> >> To add my reason why I'm opposed to this draft (versus its purpose): >> The complexity of DNSSEC is already of such stunning magnitude that >> almost anything that makes it even more complex, better have an earth >> shatteringly good reason going for it. > > I think we either need to be prepared to roll algorithms in the > future, or we don't. > > If we do, then I think it's reasonable to think that in some cases > an algorithm roll will be mandated because of a perceived weakness > in one algorithm, and that the replacement algorithm may not be as > widely deployed as the weak algorithm. > > If we accept these points, then I think there's an operational need > to be able to measure deployment of the new algorithm. This was > Steve's point in his presentation yesterday, I think. > > I don't think the fall from grace of an algorithm will shatter the > earth, but it seems like something we should be prepared to do well. > > > Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 05:30:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF3228C1B8; Thu, 30 Jul 2009 05:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqEHbxnxL4u6; Thu, 30 Jul 2009 05:30:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 232B128C266; Thu, 30 Jul 2009 05:29:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUiX-000FwQ-0R for namedroppers-data0@psg.com; Thu, 30 Jul 2009 12:26:41 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUiR-000Fum-Jp for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 12:26:38 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=L7gvjwQCBhxk3WqX1F2UiPV/T5uzu02YeJJwnVanFfgTQd4maUCAKo4IcymDtypNpRgvdhL0Sk0I+CJdKGtvjiRj04pHsw5f2H03WD4goBkQz4eTX6i7+//9ar2Wze0D; Received: from [130.129.87.217] (helo=dhcp-57d9.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUhC-0001a8-KX; Thu, 30 Jul 2009 12:25:19 +0000 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <1AD099C7-2F51-4363-A917-8E35881E6768@hopcount.ca> From: Joe Abley To: John Schnizlein In-Reply-To: <7B2278E1-2A58-43CA-A84E-68C0DCBC1C9A@isoc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 14:25:16 +0200 References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> <7B2278E1-2A58-43CA-A84E-68C0DCBC1C9A@isoc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 30-Jul-2009, at 14:17, John Schnizlein wrote: > Signing with SHA-1 and then with SHA-2 as soon as it has a code > point would enable cautious validators to do just SHA-2 at their > earliest convenience. Having both would be the first part of the > rollover anyway, wouldn't it? I think that during a normal KSK rollover we will see a dual-publish interval of 30 days, in accordance with 5011. This seems incompatible with what you are suggesting. The inference is that an algorithm rollover would be timed differently from a regular, scheduled KSK rollover. Perhaps that's to be expected, and it's not practical to execute a key rollover with an algorithm change in the same schedule as a normal key rollover, but I thought I'd call it out anyway. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 05:34:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E997E28C25F; Thu, 30 Jul 2009 05:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uQhCOe2TWkg; Thu, 30 Jul 2009 05:34:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27A0728C1A0; Thu, 30 Jul 2009 05:33:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUm0-000GYu-3q for namedroppers-data0@psg.com; Thu, 30 Jul 2009 12:30:16 +0000 Received: from [2607:f010:3fe:202:1013:72ff:fe5b:6108] (helo=out-11.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWUlr-000GXK-20 for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 12:30:12 +0000 Received: from smtp-2.smtp.ucla.edu (smtp-2.smtp.ucla.edu [169.232.47.240]) by out-11.smtp.ucla.edu with ESMTP id n6UCTZqT008597; Thu, 30 Jul 2009 05:29:36 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.158]) by smtp-2.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n6UCTZqT008597; Thu, 30 Jul 2009 05:29:35 -0700 Received: from dhcp-158b.meeting.ietf.org (dhcp-158b.meeting.ietf.org [130.129.21.139]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n6UCTWfx014273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2009 05:29:34 -0700 Cc: namedroppers@ops.ietf.org Message-Id: <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> From: Eric Osterweil To: Michael Graff In-Reply-To: <4A702AE1.10201@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Thu, 30 Jul 2009 14:29:28 +0200 References: <4A702AE1.10201@isc.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.47.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 29, 2009, at 12:56 PM, Michael Graff wrote: > Let me state some reasons I'm opposed to this draft's purpose, even =20= > though I think some part of it would be very interesting to pursue. > > (1) This becomes a meta-type in practice. It might prevent some =20 > lookups initially, but should a client ask for items that were not =20 > in the cache, the server would have to remember which algorithms it =20= > saw in the DNSKEY response to know which it could usefully retrieve =20= > with follow-on queries. For example, a particular stub might =20 > support more algorithms than the cache it asks, so additional =20 > queries (including additional queries for the DNSKEY to obtain its =20 > signatures) would have to be generated. > > (2) This solves a problem I do not fully believe is a problem, that =20= > of TCP fallback. I've said it before, but chat servers, web =20 > servers, and other types of TCP-based servers handle many, many =20 > connections/sec and many, many sustained clients today. I don't =20 > understand why DNS is different here, excepting perhaps that we have =20= > not encountered this situation until now. > > (3) It solves a problem that I do not fully believe is a problem, =20 > that of fragmented packets. There is no solid solution in this =20 > proposal that it WILL get packets through, only that it might have a =20= > better chance to do so. Key rollover will still cause large packets =20= > and/or TCP fallback, which means only during rollover events will =20 > badness occur. I'd rather it occur all the time rather than only in =20= > some situations. So, I don't completely understand this. The PMTU problem is actually =20= observable, so why are you saying it doesn't exist? There are =20 numerous zones for which this can be seen. Also, I think it is =20 important to note that a TC bit is commonly interpreted to mean, "do =20 TCP now." However, this does not need to be the case, and RFC 2671 =20 does not advocate that approach either. Maybe before this descends too quickly, would you mind clarifying why =20= you don't believe it is a problem? > > > (4) I believe the knowledge it would allow to be gathered -- that =20 > of which algorithms, hashes, etc. were in common use -- is very =20 > valuable. Perhaps a draft on "voluntary reporting of server =20 > capabilities" would be useful, where the data would be anonymous, =20 > infrequently (order days at least) reported, and collected into =20 > reports. Knowing that RSA/SHA1 is not used any longer is very good =20= > information to know in terms of deprecating protocols, but using =20 > that as a filter seems unwise to me. fwiw, this is available on the front page of: http://secspider.cs.ucla.edu/ under "Distribution of key algorithms in use." Is that not a =20 sufficient summary? Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkpxkisACgkQK/tq6CJjZQKB/ACeN6aqvjcsBEFOKaPaf2m3ioXO dIMAoIOR7rwumf5N6oE/TSmSb4IoA+qt =3Dr7Ia -----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 Jul 30 06:02:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215C63A6FB0; Thu, 30 Jul 2009 06:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.521 X-Spam-Level: X-Spam-Status: No, score=-101.521 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, 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 4K5Yx-838ZdE; Thu, 30 Jul 2009 06:02:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4620F3A69FA; Thu, 30 Jul 2009 06:02:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVDQ-000M4c-OM for namedroppers-data0@psg.com; Thu, 30 Jul 2009 12:58:36 +0000 Received: from [207.97.245.195] (helo=smtp195.iad.emailsrvr.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVDN-000M3O-0Y for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 12:58:34 +0000 Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9206E1B4023; Thu, 30 Jul 2009 08:58:26 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: schnizlein-AT-isoc.org) with ESMTPSA id 19B231B4018; Thu, 30 Jul 2009 08:58:25 -0400 (EDT) Cc: namedroppers@ops.ietf.org Message-Id: <405DE637-DF23-4B2D-AD95-B6BABFCBA198@isoc.org> From: John Schnizlein To: Joe Abley In-Reply-To: <1AD099C7-2F51-4363-A917-8E35881E6768@hopcount.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 14:58:24 +0200 References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> <7B2278E1-2A58-43CA-A84E-68C0DCBC1C9A@isoc.org> <1AD099C7-2F51-4363-A917-8E35881E6768@hopcount.ca> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2009Jul30, at 2:25 PM, Joe Abley wrote: > > On 30-Jul-2009, at 14:17, John Schnizlein wrote: > >> Signing with SHA-1 and then with SHA-2 as soon as it has a code >> point would enable cautious validators to do just SHA-2 at their >> earliest convenience. Having both would be the first part of the >> rollover anyway, wouldn't it? > > I think that during a normal KSK rollover we will see a dual-publish > interval of 30 days, in accordance with 5011. This seems > incompatible with what you are suggesting. I guess I read the 30 days as a minimum based on the following excerpt. Without urgency in removing the key-to-be-replaced, exploring both could be leisurely. 2.4.2. Remove Hold-Down Time The remove hold-down time is 30 days. This parameter is solely a key management database bookeeping parameter. Failure to remove information about the state of defunct keys from the database will not adversely impact the security of this protocol, but may end up with a database cluttered with obsolete key information. > > The inference is that an algorithm rollover would be timed > differently from a regular, scheduled KSK rollover. > > Perhaps that's to be expected, and it's not practical to execute a > key rollover with an algorithm change in the same schedule as a > normal key rollover, but I thought I'd call it out anyway. I confess not seeing why algorithm rollover (especially for key- length) needs to have different timing. I don't know if we have consensus that key-roll for compromise would use 5011, but using an execution path that is regularly exercised has a lot in its favor. John -- to unsubscribe send a message to namedroppers-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 Jul 30 06:02:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDAB28C1EE; Thu, 30 Jul 2009 06:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.683 X-Spam-Level: X-Spam-Status: No, score=-101.683 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRqiZC8AS79r; Thu, 30 Jul 2009 06:02:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ECA928C177; Thu, 30 Jul 2009 06:02:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVCp-000Lww-4I for namedroppers-data0@psg.com; Thu, 30 Jul 2009 12:57:59 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVCk-000Lun-DX for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 12:57:56 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id C02C1327A85; Thu, 30 Jul 2009 12:57:53 +0000 (UTC) Received: from [130.129.23.145] (dhcp-1791.meeting.ietf.org [130.129.23.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id C7041327A7F; Thu, 30 Jul 2009 12:57:52 +0000 (UTC) References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> Message-Id: From: Michael Graff To: Eric Osterweil In-Reply-To: <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Thu, 30 Jul 2009 14:57:48 +0200 Cc: "namedroppers@ops.ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I remain unconvinced that tcp is evil. Re secspider yes it is not as useful. It measures probed algorithms not reported ability to use algorithms. --Michael On Jul 30, 2009, at 14:29, Eric Osterweil wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Jul 29, 2009, at 12:56 PM, Michael Graff wrote: > >> Let me state some reasons I'm opposed to this draft's purpose, even >> though I think some part of it would be very interesting to pursue. >> >> (1) This becomes a meta-type in practice. It might prevent some >> lookups initially, but should a client ask for items that were not >> in the cache, the server would have to remember which algorithms it >> saw in the DNSKEY response to know which it could usefully retrieve >> with follow-on queries. For example, a particular stub might >> support more algorithms than the cache it asks, so additional >> queries (including additional queries for the DNSKEY to obtain its >> signatures) would have to be generated. >> >> (2) This solves a problem I do not fully believe is a problem, >> that of TCP fallback. I've said it before, but chat servers, web >> servers, and other types of TCP-based servers handle many, many >> connections/sec and many, many sustained clients today. I don't >> understand why DNS is different here, excepting perhaps that we >> have not encountered this situation until now. >> >> (3) It solves a problem that I do not fully believe is a problem, >> that of fragmented packets. There is no solid solution in this >> proposal that it WILL get packets through, only that it might have >> a better chance to do so. Key rollover will still cause large >> packets and/or TCP fallback, which means only during rollover >> events will badness occur. I'd rather it occur all the time rather >> than only in some situations. > > So, I don't completely understand this. The PMTU problem is > actually observable, so why are you saying it doesn't exist? There > are numerous zones for which this can be seen. Also, I think it is > important to note that a TC bit is commonly interpreted to mean, "do > TCP now." However, this does not need to be the case, and RFC 2671 > does not advocate that approach either. > > Maybe before this descends too quickly, would you mind clarifying > why you don't believe it is a problem? > >> >> >> (4) I believe the knowledge it would allow to be gathered -- that >> of which algorithms, hashes, etc. were in common use -- is very >> valuable. Perhaps a draft on "voluntary reporting of server >> capabilities" would be useful, where the data would be anonymous, >> infrequently (order days at least) reported, and collected into >> reports. Knowing that RSA/SHA1 is not used any longer is very good >> information to know in terms of deprecating protocols, but using >> that as a filter seems unwise to me. > > fwiw, this is available on the front page of: > http://secspider.cs.ucla.edu/ > under "Distribution of key algorithms in use." Is that not a > sufficient summary? > > Eric > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > > iEYEARECAAYFAkpxkisACgkQK/tq6CJjZQKB/ACeN6aqvjcsBEFOKaPaf2m3ioXO > dIMAoIOR7rwumf5N6oE/TSmSb4IoA+qt > =r7Ia > -----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 Jul 30 06:12:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5F23A686D; Thu, 30 Jul 2009 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrD9hlPLof0P; Thu, 30 Jul 2009 06:12:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9A043A6921; Thu, 30 Jul 2009 06:12:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVNW-000Ogg-O1 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 13:09:02 +0000 Received: from [2607:f010:3fe:102:101c:23ff:fed0:918c] (helo=out-66.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVNN-000OdG-7F for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 13:08:59 +0000 Received: from smtp-13.smtp.ucla.edu (smtp-13.smtp.ucla.edu [169.232.46.240]) by out-66.smtp.ucla.edu with ESMTP id n6UD8enG021848; Thu, 30 Jul 2009 06:08:47 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.145]) by smtp-13.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n6UD8enG021848; Thu, 30 Jul 2009 06:08:40 -0700 Received: from dhcp-158b.meeting.ietf.org (dhcp-158b.meeting.ietf.org [130.129.21.139]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n6UD8bEm002782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2009 06:08:39 -0700 Cc: "namedroppers@ops.ietf.org" Message-Id: <4CD557FA-C9E9-467D-895A-8D5F4BDDFCC8@CS.UCLA.EDU> From: Eric Osterweil To: Michael Graff In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Thu, 30 Jul 2009 15:08:37 +0200 References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 30, 2009, at 2:57 PM, Michael Graff wrote: > I remain unconvinced that tcp is evil. Maybe the.org folk can speak more directly to how the over-zealous use =20= of TCP affects their operations... Actually, does anyone here feel =20 that over use of TCP is detrimental? It seems wasteful to add load to =20= servers and latency to queries when it can be avoided, and I think =20 there is plenty of data to show that it can often be avoided. TCP may not be evil (indeed), but it is being overused here and that =20 can be avoided. Perhaps a better question, what would convince you? > > > Re secspider yes it is not as useful. It measures probed algorithms =20= > not reported ability to use algorithms. You asked for a list "which algorithms, hashes, etc. were in common =20 use..." This is exactly the answer to that question from the =20 authoritative name server side. Also, what does "prob[ing]" have to =20 do with anything? If you're strictly speaking about resolver =20 capabilities, then I think you should _also_ consider that the algos =20 served by name servers are important too. > > > --Michael > > > On Jul 30, 2009, at 14:29, Eric Osterweil wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On Jul 29, 2009, at 12:56 PM, Michael Graff wrote: >> >>> Let me state some reasons I'm opposed to this draft's purpose, =20 >>> even though I think some part of it would be very interesting to =20 >>> pursue. >>> >>> (1) This becomes a meta-type in practice. It might prevent some =20= >>> lookups initially, but should a client ask for items that were not =20= >>> in the cache, the server would have to remember which algorithms =20 >>> it saw in the DNSKEY response to know which it could usefully =20 >>> retrieve with follow-on queries. For example, a particular stub =20 >>> might support more algorithms than the cache it asks, so =20 >>> additional queries (including additional queries for the DNSKEY to =20= >>> obtain its signatures) would have to be generated. >>> >>> (2) This solves a problem I do not fully believe is a problem, =20 >>> that of TCP fallback. I've said it before, but chat servers, web =20= >>> servers, and other types of TCP-based servers handle many, many =20 >>> connections/sec and many, many sustained clients today. I don't =20 >>> understand why DNS is different here, excepting perhaps that we =20 >>> have not encountered this situation until now. >>> >>> (3) It solves a problem that I do not fully believe is a problem, =20= >>> that of fragmented packets. There is no solid solution in this =20 >>> proposal that it WILL get packets through, only that it might have =20= >>> a better chance to do so. Key rollover will still cause large =20 >>> packets and/or TCP fallback, which means only during rollover =20 >>> events will badness occur. I'd rather it occur all the time =20 >>> rather than only in some situations. >> >> So, I don't completely understand this. The PMTU problem is =20 >> actually observable, so why are you saying it doesn't exist? There =20= >> are numerous zones for which this can be seen. Also, I think it is =20= >> important to note that a TC bit is commonly interpreted to mean, =20 >> "do TCP now." However, this does not need to be the case, and RFC =20= >> 2671 does not advocate that approach either. >> >> Maybe before this descends too quickly, would you mind clarifying =20 >> why you don't believe it is a problem? >> >>> >>> >>> (4) I believe the knowledge it would allow to be gathered -- that =20= >>> of which algorithms, hashes, etc. were in common use -- is very =20 >>> valuable. Perhaps a draft on "voluntary reporting of server =20 >>> capabilities" would be useful, where the data would be anonymous, =20= >>> infrequently (order days at least) reported, and collected into =20 >>> reports. Knowing that RSA/SHA1 is not used any longer is very =20 >>> good information to know in terms of deprecating protocols, but =20 >>> using that as a filter seems unwise to me. >> >> fwiw, this is available on the front page of: >> http://secspider.cs.ucla.edu/ >> under "Distribution of key algorithms in use." Is that not a =20 >> sufficient summary? >> >> Eric >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.9 (Darwin) >> >> iEYEARECAAYFAkpxkisACgkQK/tq6CJjZQKB/ACeN6aqvjcsBEFOKaPaf2m3ioXO >> dIMAoIOR7rwumf5N6oE/TSmSb4IoA+qt >> =3Dr7Ia >> -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkpxm1UACgkQK/tq6CJjZQKCdACeJ7YlgwASZW5EeRGWKUyjk4g8 C+MAn2GXN2KrHzqp05OKuGku4eMSly0c =3DbnZb -----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 Jul 30 06:38:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381EA28C23B; Thu, 30 Jul 2009 06:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLrS+AgIqXSV; Thu, 30 Jul 2009 06:38:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4890028C258; Thu, 30 Jul 2009 06:38:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVjD-0003T8-9T for namedroppers-data0@psg.com; Thu, 30 Jul 2009 13:31:27 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVj9-0003S1-6g for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 13:31:25 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=X/jShOxt79DCyrSl7DDxTebI2qI1O907w0bybDRc3z4yCHkaac56eZ2/ucIigMoeB33DRyjmFS7Er5+Yz1YHIhpYpBYoiJtkgB1cxgTYDwesfQlSTg4i2fEfZfVuDdwT; Received: from [130.129.87.217] (helo=dhcp-57d9.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVj7-0002Qm-Av; Thu, 30 Jul 2009 13:31:21 +0000 Cc: namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: John Schnizlein In-Reply-To: <405DE637-DF23-4B2D-AD95-B6BABFCBA198@isoc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Thu, 30 Jul 2009 15:31:19 +0200 References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> <7B2278E1-2A58-43CA-A84E-68C0DCBC1C9A@isoc.org> <1AD099C7-2F51-4363-A917-8E35881E6768@hopcount.ca> <405DE637-DF23-4B2D-AD95-B6BABFCBA198@isoc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 30-Jul-2009, at 14:58, John Schnizlein wrote: > I confess not seeing why algorithm rollover (especially for key- > length) needs to have different timing. I think it has been suggested that a key rollover which involves an algorithm change might need to last as long as it takes for people to get confidence that there is deployed support for the new algorithm, before the departing key disappears. > I don't know if we have consensus that key-roll for compromise would > use 5011, but using an execution path that is regularly exercised > has a lot in its favor. I don't think we're talking about emergency key rollover. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 06:39:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDDB3A68E6; Thu, 30 Jul 2009 06:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 mIvjvA3BywQZ; Thu, 30 Jul 2009 06:39:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 292D928C292; Thu, 30 Jul 2009 06:38:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVit-0003Mj-E2 for namedroppers-data0@psg.com; Thu, 30 Jul 2009 13:31:07 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVio-0003Kw-NF for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 13:31: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 n6UDSsa1003644; Thu, 30 Jul 2009 13:28:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n6UDSs2X003643; Thu, 30 Jul 2009 13:28:54 GMT Date: Thu, 30 Jul 2009 13:28:54 +0000 From: bmanning@vacation.karoshi.com To: Eric Osterweil Cc: Michael Graff , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Message-ID: <20090730132854.GA2994@vacation.karoshi.com.> References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <4CD557FA-C9E9-467D-895A-8D5F4BDDFCC8@CS.UCLA.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD557FA-C9E9-467D-895A-8D5F4BDDFCC8@CS.UCLA.EDU> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: "Transport considerations for DNS DNS queries and responses are available over a variety of transports (UDP/TCP) and may be ported to use other transports in the future. Current use profiles show that most user generated DNS traffic prefers one transport over another. This historical usage pattern has or may lead to the presumption that any DNS traffic, regardless of transport, should be considered on equal footing. However, not all choices for transport share an equal cost to the DNS operator. This note is intended to inform and educate - that while all transport options MUST/(need to) be supported, because of the different cost and risk profiles of some transports, an operator may chose to apply different processing criteria to different transports, prefering some transport options over others." --bill On Thu, Jul 30, 2009 at 03:08:37PM +0200, Eric Osterweil wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Jul 30, 2009, at 2:57 PM, Michael Graff wrote: > > >I remain unconvinced that tcp is evil. > > Maybe the.org folk can speak more directly to how the over-zealous use > of TCP affects their operations... Actually, does anyone here feel > that over use of TCP is detrimental? It seems wasteful to add load to > servers and latency to queries when it can be avoided, and I think > there is plenty of data to show that it can often be avoided. > > TCP may not be evil (indeed), but it is being overused here and that > can be avoided. > > Perhaps a better question, what would convince you? > > > > > > >Re secspider yes it is not as useful. It measures probed algorithms > >not reported ability to use algorithms. > > You asked for a list "which algorithms, hashes, etc. were in common > use..." This is exactly the answer to that question from the > authoritative name server side. Also, what does "prob[ing]" have to > do with anything? If you're strictly speaking about resolver > capabilities, then I think you should _also_ consider that the algos > served by name servers are important too. > > > > > > >--Michael > > > > > >On Jul 30, 2009, at 14:29, Eric Osterweil wrote: > > > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >> > >>On Jul 29, 2009, at 12:56 PM, Michael Graff wrote: > >> > >>>Let me state some reasons I'm opposed to this draft's purpose, > >>>even though I think some part of it would be very interesting to > >>>pursue. > >>> > >>>(1) This becomes a meta-type in practice. It might prevent some > >>>lookups initially, but should a client ask for items that were not > >>>in the cache, the server would have to remember which algorithms > >>>it saw in the DNSKEY response to know which it could usefully > >>>retrieve with follow-on queries. For example, a particular stub > >>>might support more algorithms than the cache it asks, so > >>>additional queries (including additional queries for the DNSKEY to > >>>obtain its signatures) would have to be generated. > >>> > >>>(2) This solves a problem I do not fully believe is a problem, > >>>that of TCP fallback. I've said it before, but chat servers, web > >>>servers, and other types of TCP-based servers handle many, many > >>>connections/sec and many, many sustained clients today. I don't > >>>understand why DNS is different here, excepting perhaps that we > >>>have not encountered this situation until now. > >>> > >>>(3) It solves a problem that I do not fully believe is a problem, > >>>that of fragmented packets. There is no solid solution in this > >>>proposal that it WILL get packets through, only that it might have > >>>a better chance to do so. Key rollover will still cause large > >>>packets and/or TCP fallback, which means only during rollover > >>>events will badness occur. I'd rather it occur all the time > >>>rather than only in some situations. > >> > >>So, I don't completely understand this. The PMTU problem is > >>actually observable, so why are you saying it doesn't exist? There > >>are numerous zones for which this can be seen. Also, I think it is > >>important to note that a TC bit is commonly interpreted to mean, > >>"do TCP now." However, this does not need to be the case, and RFC > >>2671 does not advocate that approach either. > >> > >>Maybe before this descends too quickly, would you mind clarifying > >>why you don't believe it is a problem? > >> > >>> > >>> > >>>(4) I believe the knowledge it would allow to be gathered -- that > >>>of which algorithms, hashes, etc. were in common use -- is very > >>>valuable. Perhaps a draft on "voluntary reporting of server > >>>capabilities" would be useful, where the data would be anonymous, > >>>infrequently (order days at least) reported, and collected into > >>>reports. Knowing that RSA/SHA1 is not used any longer is very > >>>good information to know in terms of deprecating protocols, but > >>>using that as a filter seems unwise to me. > >> > >>fwiw, this is available on the front page of: > >> http://secspider.cs.ucla.edu/ > >>under "Distribution of key algorithms in use." Is that not a > >>sufficient summary? > >> > >>Eric > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v2.0.9 (Darwin) > >> > >>iEYEARECAAYFAkpxkisACgkQK/tq6CJjZQKB/ACeN6aqvjcsBEFOKaPaf2m3ioXO > >>dIMAoIOR7rwumf5N6oE/TSmSb4IoA+qt > >>=r7Ia > >>-----END PGP SIGNATURE----- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > > iEYEARECAAYFAkpxm1UACgkQK/tq6CJjZQKCdACeJ7YlgwASZW5EeRGWKUyjk4g8 > C+MAn2GXN2KrHzqp05OKuGku4eMSly0c > =bnZb > -----END PGP SIGNATURE----- > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 06:56:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506AE3A6FB0; Thu, 30 Jul 2009 06:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfxOfDLS2uU0; Thu, 30 Jul 2009 06:56:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D4233A6802; Thu, 30 Jul 2009 06:56:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWW4A-0008Ki-AP for namedroppers-data0@psg.com; Thu, 30 Jul 2009 13:53:06 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWW45-0008Ir-Ue for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 13:53:04 +0000 Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:7:1:216:6fff:fe46:b75d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 3B242E601C for ; Thu, 30 Jul 2009 13:53:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6UDqwLo003953 for ; Thu, 30 Jul 2009 23:52:58 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907301352.n6UDqwLo003953@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: [dnsext] Re: draft-kerr-ixfr-only-00.txt Date: Thu, 30 Jul 2009 23:52:58 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Old However, when a slave has multiple masters for a single zone, it is possible that not all masters has the same set of serials for that zone. In this case, if a slave attempts an IXFR from a master which does not have the serial in use by the slave, the master will fall back to a full zone transfer (AXFR). New However, when a slave has multiple masters for a single zone, it is possible that not all masters has the same set of serials for that zone. In this case, if a slave attempts an IXFR from a master which does not have the serial in use by the slave and the master has a serial which is greater than the slaves, the master will fall back to a full zone transfer (AXFR). Clients need to handle NODATA responses to IXFR-ONLY requests from ixfr-only unaware masters. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark@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 Jul 30 06:57:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739783A6FB1; Thu, 30 Jul 2009 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu+lwOeHBQgd; Thu, 30 Jul 2009 06:56:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6262A3A6802; Thu, 30 Jul 2009 06:56:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWW5Q-0008Wf-Ie for namedroppers-data0@psg.com; Thu, 30 Jul 2009 13:54:24 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWW5M-0008Vk-5H for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 13:54:22 +0000 Received: from [IPv6:2001:df8:0:16:222:43ff:fe24:8028] ([IPv6:2001:df8:0:16:222:43ff:fe24:8028]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6UDs76u023987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 15:54:08 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A71A5FF.2090704@NLnetLabs.nl> Date: Thu, 30 Jul 2009 15:54:07 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Joe Abley CC: John Schnizlein , namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <066DC8FD-33AF-42F7-B808-09C64B2F91E3@ICSI.Berkeley.EDU> <200907291610.n6TGAKAO064016@stora.ogud.com> <694F0E1A-9C87-49BC-B405-4605AC35DAC5@ICSI.Berkeley.EDU> <4A714758.2090902@gmail.com> <91FCB300-1CFC-4CDA-95B8-6B313DBE3324@hopcount.ca> <20090730093050.GB11490@shinkuro.com> <43E6DC36-3C68-4505-8EED-9D0E2F16A8EC@hopcount.ca> <7B2278E1-2A58-43CA-A84E-68C0DCBC1C9A@isoc.org> <1AD099C7-2F51-4363-A917-8E35881E6768@hopcount.ca> <405DE637-DF23-4B2D-AD95-B6BABFCBA198@isoc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 30 Jul 2009 15:54:09 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Abley wrote: > > On 30-Jul-2009, at 14:58, John Schnizlein wrote: > >> I confess not seeing why algorithm rollover (especially for >> key-length) needs to have different timing. > > I think it has been suggested that a key rollover which involves an > algorithm change might need to last as long as it takes for people to > get confidence that there is deployed support for the new algorithm, > before the departing key disappears. > well, if there's no significant support you might as well wait with the start of the roll until there is (unless you intend to just have both, which could be seen as a very long roll, then this may be true) but i think it comes from the idea that algorithm rollovers have to be handled differently from rollovers with the same algorithm, but i too am not sure that this would affect the actual timing issues >> I don't know if we have consensus that key-roll for compromise would >> use 5011, but using an execution path that is regularly exercised has >> a lot in its favor. > > I don't think we're talking about emergency key rollover. > if the projected fear about the imminent demise of sha-1 becomes a reality, maybe we should be. btw, count me in the camp for 'let's try a roll real soonish'. it will have to happen at one time in the future Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpxpfsACgkQ4nZCKsdOncW8YwCeOFN0G/2yDFDcLCcVPDAaB+r1 FY4AoNAOjHVrpXyDwn+eoolimRrKrDEm =2j/k -----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 Jul 30 08:01:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398EA3A693D; Thu, 30 Jul 2009 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 KHRnoJWslyZG; Thu, 30 Jul 2009 08:01:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0C943A71A4; Thu, 30 Jul 2009 08:01:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWX3r-000KLl-Kb for namedroppers-data0@psg.com; Thu, 30 Jul 2009 14:56:51 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWX3o-000KK6-2S for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 14:56:50 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6UEukLC009693 for ; Thu, 30 Jul 2009 10:56:46 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n6UEukaK009692 for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 10:56:46 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWVQx-000PL6-NQ for namedroppers@ops.ietf.org; Thu, 30 Jul 2009 13:12:37 +0000 Received: by ewy28 with SMTP id 28so656121ewy.41 for ; Thu, 30 Jul 2009 06:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=F4p1q38z4Q01qlKqEEG6Pt+aky5aNCI7gZRhVDrIFGQ=; b=kEXw44Ei+ludyLAFgYpYZiMdHN1D+BDidN0XWsB5ZBxX4fmR5evkh9BXv3TFkSIeTf 3ZcKmDsd4NgTC0XrA7cMlbfL/1hLTgPQYyd4hz4fddrgr1HMsZYJ9zQfg8wvhpDc/GeN /hbUjv+fxirbKfHqFKAFUlYIfs5vW9MZ4VO1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Wy+BKIS5wQbGeokVK6Dbjxdu8CDqjUsekIXeFOUG5SmTEW1Tp16ml4Wb4lHdBbH9wm TjOVyhLS/8GNmlvr6xoJhD1GHdW7wKlw624E9jX3USLjT7nOL1HBw7WODHeJWHlOLsRF Lqu6HOBc14CsmUXSt/2ypnAZhgDJmBSwwZbW8= MIME-Version: 1.0 Received: by 10.210.20.6 with SMTP id 6mr1656213ebt.73.1248959554100; Thu, 30 Jul 2009 06:12:34 -0700 (PDT) In-Reply-To: References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> From: bert hubert Date: Thu, 30 Jul 2009 15:12:14 +0200 X-Google-Sender-Auth: 7d78f125b0eaadd6 Message-ID: <3efd34cc0907300612q6bf803dbl5cee13398e547e8b@mail.gmail.com> Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 To: Michael Graff Cc: Eric Osterweil , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Thu, Jul 30, 2009 at 2:57 PM, Michael Graff wrote: > I remain unconvinced that tcp is evil. As an implementor, I'd tend to agree. Operators however may not be happy with their (forced) change of mission from '99.9% UDP' to 'far larger UDP packets plus heaps of TCP sessions'. Even if we do our job really well as implementors, it has to be admitted that blasting out UDP is a lot easier than doing millions of TCP/IP sessions. This might be offset by the fact that TCP tends to be highly optimised whereas UDP is sort of neglected in many kernels. But it is probably reasonable to say that a server that maxes out at n kpqs UDP will not attain that same query rate over TCP, no matter how hard we try. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 19:44:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD9528C144; Thu, 30 Jul 2009 19:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuwBRCSMlDJE; Thu, 30 Jul 2009 19:44:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23FD03A69AF; Thu, 30 Jul 2009 19:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWhsT-000Kh1-BU for namedroppers-data0@psg.com; Fri, 31 Jul 2009 02:29:49 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWhsF-000KfO-Oe for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 02:29:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2A053AB120 for ; Fri, 31 Jul 2009 02:29:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-Reply-To: Your message of "Thu, 30 Jul 2009 14:57:48 +0200." References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 31 Jul 2009 02:29:35 +0000 Message-ID: <26168.1249007375@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Michael Graff > Date: Thu, 30 Jul 2009 14:57:48 +0200 > > I remain unconvinced that tcp is evil. what would it take to convince you? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 20:12:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F963A6D1C; Thu, 30 Jul 2009 20:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 RhhwsewRcTt5; Thu, 30 Jul 2009 20:12:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2FD13A6B3F; Thu, 30 Jul 2009 20:12:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWiM0-000OdA-B4 for namedroppers-data0@psg.com; Fri, 31 Jul 2009 03:00:20 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWiLb-000OXD-1t for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 03:00:12 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n6V2v2sU002214; Fri, 31 Jul 2009 02:57:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n6V2v2FN002213; Fri, 31 Jul 2009 02:57:02 GMT Date: Fri, 31 Jul 2009 02:57:02 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Message-ID: <20090731025702.GA2194@vacation.karoshi.com.> References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26168.1249007375@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 31, 2009 at 02:29:35AM +0000, Paul Vixie wrote: > > From: Michael Graff > > Date: Thu, 30 Jul 2009 14:57:48 +0200 > > > > I remain unconvinced that tcp is evil. > > what would it take to convince you? > verifiable evidence of malevolent intent. and since some fo the TCP authors are still with us, we could ask them if TCP was designed to be evil. otherwise, i think I'm w/ Michael on this. the transport, in and of itself is not evil. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 30 20:45:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876C33A6CF3; Thu, 30 Jul 2009 20:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzlBXF10Qvvk; Thu, 30 Jul 2009 20:45:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 840273A6B8F; Thu, 30 Jul 2009 20:45:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWiw9-0003Co-7a for namedroppers-data0@psg.com; Fri, 31 Jul 2009 03:37:41 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWiw3-0003C9-Ok for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 03:37:39 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=NlfHLMfTBGdDaBrxsZiEs95ctrxKvxqjxrx6/JiX3PyFMCSIzLsm+6w6mZ52qpx1; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.99.186] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MWiw0-0006Ts-UR; Thu, 30 Jul 2009 23:37:33 -0400 Message-ID: <4A728209.C7F85DB0@ix.netcom.com> Date: Thu, 30 Jul 2009 22:32:57 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> <20090731025702.GA2194@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688be83091d01397a82e12fcabaf7661b78350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.99.186 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill and all, Of course TCP is not evil. And of course TCP can and is too often used in an evil manner or abused in many ways as to appear to be evil. Ergo those that abuse same or use same in an abusive manner may be viewed as evil or otherwise ill advised. bmanning@vacation.karoshi.com wrote: > On Fri, Jul 31, 2009 at 02:29:35AM +0000, Paul Vixie wrote: > > > From: Michael Graff > > > Date: Thu, 30 Jul 2009 14:57:48 +0200 > > > > > > I remain unconvinced that tcp is evil. > > > > what would it take to convince you? > > > > verifiable evidence of malevolent intent. > and since some fo the TCP authors are still with > us, we could ask them if TCP was designed to be evil. > > otherwise, i think I'm w/ Michael on this. the transport, > in and of itself is not evil. > > --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 00:24:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A7C3A6D34; Fri, 31 Jul 2009 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f914QY4Va-+V; Fri, 31 Jul 2009 00:24:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57AC93A67E3; Fri, 31 Jul 2009 00:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWmIl-0005T8-1E for namedroppers-data0@psg.com; Fri, 31 Jul 2009 07:13:15 +0000 Received: from [2607:f010:3fe:202:1013:72ff:fe5b:6108] (helo=out-11.smtp.ucla.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWmIY-0005QU-UM for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 07:13:08 +0000 Received: from smtp-2.smtp.ucla.edu (smtp-2.smtp.ucla.edu [169.232.47.240]) by out-11.smtp.ucla.edu with ESMTP id n6V7CZgt002016; Fri, 31 Jul 2009 00:12:38 -0700 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-2.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n6V7CZgt002016; Fri, 31 Jul 2009 00:12:36 -0700 Received: from host-78-64-88-32.homerun.telia.com (host-78-64-88-32.homerun.telia.com [78.64.88.32]) (authenticated bits=0) by mail.ucla.edu (8.14.3/8.14.3) with ESMTP id n6V7CRuX028652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2009 00:12:33 -0700 Cc: bmanning@vacation.karoshi.com, Paul Vixie , "namedroppers@ops.ietf.org" Message-Id: <023F435C-4DCE-459D-BA0B-F0E76E1857AF@cs.ucla.edu> From: Eric Osterweil To: "Jeffrey A. Williams" In-Reply-To: <4A728209.C7F85DB0@ix.netcom.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Fri, 31 Jul 2009 09:12:26 +0200 References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> <20090731025702.GA2194@vacation.karoshi.com.> <4A728209.C7F85DB0@ix.netcom.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.47.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No one, here, has maintained that TCP is evil. I know that I have not =20= said so. The assertion was merely that it is being used more often than =20 necessary, and it should be used more judiciously. Eric On Jul 31, 2009, at 7:32 AM, Jeffrey A. Williams wrote: > Bill and all, > > Of course TCP is not evil. And of course TCP can and is too > often used in an evil manner or abused in many ways as to appear > to be evil. Ergo those that abuse same or use same in an abusive > manner may be viewed as evil or otherwise ill advised. > > bmanning@vacation.karoshi.com wrote: > >> On Fri, Jul 31, 2009 at 02:29:35AM +0000, Paul Vixie wrote: >>>> From: Michael Graff >>>> Date: Thu, 30 Jul 2009 14:57:48 +0200 >>>> >>>> I remain unconvinced that tcp is evil. >>> >>> what would it take to convince you? >>> >> >> verifiable evidence of malevolent intent. >> and since some fo the TCP authors are still with >> us, we could ask them if TCP was designed to be evil. >> >> otherwise, i think I'm w/ Michael on this. the transport, >> in and of itself is not evil. >> >> --bill >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org =20= >> with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > Regards, > > Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > "YES WE CAN!" Barack ( Berry ) Obama > > "Credit should go with the performance of duty and not with what is > very often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > My Phone: 214-244-4827 > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org =20 > with > the word 'unsubscribe' in a single line as the message text body. > archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkpymVoACgkQK/tq6CJjZQJ4nwCglVL1c3KfLYhcYXseqA19PN/J Y48AnRZFXJnVMs4OzlOOHMfq07Qsdgbs =3DyN3P -----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 Jul 31 00:54:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1BA28C238; Fri, 31 Jul 2009 00:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGrZvq4DdEYx; Fri, 31 Jul 2009 00:54:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 815C83A6BCD; Fri, 31 Jul 2009 00:53:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWmlF-0009fe-9K for namedroppers-data0@psg.com; Fri, 31 Jul 2009 07:42:41 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWmlA-0009ev-PX for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 07:42:38 +0000 Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:16:216:6fff:fe46:b75d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id E8B14E608C for ; Fri, 31 Jul 2009 07:42:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n6V7gQf5002249 for ; Fri, 31 Jul 2009 17:42:26 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200907310742.n6V7gQf5002249@drugs.dv.isc.org> To: "namedroppers@ops.ietf.org" From: Mark Andrews References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <3efd34cc0907300612q6bf803dbl5cee13398e547e8b@mail.gmail.com> Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-reply-to: Your message of "Thu, 30 Jul 2009 15:12:14 +0200." <3efd34cc0907300612q6bf803dbl5cee13398e547e8b@mail.gmail.com> Date: Fri, 31 Jul 2009 17:42:26 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <3efd34cc0907300612q6bf803dbl5cee13398e547e8b@mail.gmail.com>, bert hubert writes: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > On Thu, Jul 30, 2009 at 2:57 PM, Michael Graff wrote: > > I remain unconvinced that tcp is evil. > > As an implementor, I'd tend to agree. Operators however may not be > happy with their (forced) change of mission from '99.9% UDP' to 'far > larger UDP packets plus heaps of TCP sessions'. The data doesn't back that up. 6000 UDP q/s results in 60 TCP q/s This is not heaps of TCP. HTTP servers start falling over at 10K TCP connections per second. You need to be responding to a million UDP queries/s on a single box to get 10K tcp connections/s on a single box. TCP fallback is still at noise levels. Mark > Even if we do our job really well as implementors, it has to be > admitted that blasting out UDP is a lot easier than doing millions of > TCP/IP sessions. > > This might be offset by the fact that TCP tends to be highly optimised > whereas UDP is sort of neglected in many kernels. > > But it is probably reasonable to say that a server that maxes out at n > kpqs UDP will not attain that same query rate over TCP, no matter how > hard we try. > > Bert > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 03:10:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041F33A6834; Fri, 31 Jul 2009 03:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1BCT2Duz9yU; Fri, 31 Jul 2009 03:10:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24EFF3A686D; Fri, 31 Jul 2009 03:10:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWozZ-0005PY-Ta for namedroppers-data0@psg.com; Fri, 31 Jul 2009 10:05:37 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWozV-0005Op-UA for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 10:05:35 +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 <0KNN00F0153G3B00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 11:05:32 +0100 (IST) Received: from [193.1.143.112] by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPA id <0KNN005NJ5D79JF0@cali.ucd.ie> for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 11:05:31 +0100 (IST) Date: Fri, 31 Jul 2009 11:05:31 +0100 From: Niall O'Reilly Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 In-reply-to: <200907310742.n6V7gQf5002249@drugs.dv.isc.org> To: "namedroppers@ops.ietf.org" Cc: Niall.oReilly@ucd.ie Message-id: <4A72C1EB.8050500@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <3efd34cc0907300612q6bf803dbl5cee13398e547e8b@mail.gmail.com> <200907310742.n6V7gQf5002249@drugs.dv.isc.org> User-Agent: Thunderbird 2.0.0.22 (X11/20090608) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > The data doesn't back that up. > > 6000 UDP q/s results in 60 TCP q/s > > This is not heaps of TCP. HTTP servers start falling over > at 10K TCP connections per second. > > You need to be responding to a million UDP queries/s on a single > box to get 10K tcp connections/s on a single box. Mark, You seem to be leaping from "[today's] data doesn't back that up" to discovering a fixed ratio relating the use of one type of transport to that of the other. I'ld be surprised to learn that there's data to back _that_ up. OTOH, this is not to say that > TCP fallback is still at noise levels. isn't true. Best regards, Niall O'Reilly -- to unsubscribe send a message to namedroppers-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 Jul 31 04:25:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9833A6C60; Fri, 31 Jul 2009 04:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 JRAFLmqr+bZF; Fri, 31 Jul 2009 04:25:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD0883A6B27; Fri, 31 Jul 2009 04:25:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWq5x-000IGk-Ln for namedroppers-data0@psg.com; Fri, 31 Jul 2009 11:16:17 +0000 Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWq5t-000IEr-8G for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 11:16:14 +0000 Received: by ewy28 with SMTP id 28so1446762ewy.41 for ; Fri, 31 Jul 2009 04:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ygI8Woc5nTNbOxVZTp8aug/sTdMHug+cfpJyTAwIxH4=; b=PNVM+K5oKdlUljR423QEI54fBVx/tlbKimsb3stnYy4wBUE7r85wMgSA8+9AwZT1ak zw93mH5d2bv+IMEOx2LMeVfZgJvvd0/NBZkWSGxzgrewVMu9BwVRG6ozdYoMoGF4w24l qOD/0EpDc1xBwX4eLXMGpL2uB0bebNZsfdAMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=CZGgEuxj/tfmvuzvCOCwlnkKqIpvNaFafkLbRerFJPGRZRwvMSbTv1QM0OBL7CDRfW kj0IsBcubXgPpkWzYqG9EU0IhzMdUWXEXzSsdLKdK1PV9G3gbpuquqDLVSh3YdBzmXWH Xf3n9//8tcMdvS1RNa+cgdUHgDK1NR/ZBJCiA= MIME-Version: 1.0 Received: by 10.211.179.6 with SMTP id g6mr2883104ebp.94.1249038972091; Fri, 31 Jul 2009 04:16:12 -0700 (PDT) In-Reply-To: <200907310742.n6V7gQf5002249@drugs.dv.isc.org> References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <3efd34cc0907300612q6bf803dbl5cee13398e547e8b@mail.gmail.com> <200907310742.n6V7gQf5002249@drugs.dv.isc.org> From: bert hubert Date: Fri, 31 Jul 2009 13:15:52 +0200 Message-ID: <3efd34cc0907310415j592e46f2l4ff7fa28c39c9709@mail.gmail.com> Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 To: Mark Andrews Cc: "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 31, 2009 at 9:42 AM, Mark Andrews wrote: >> As an implementor, I'd tend to agree. Operators however may not be >> happy with their (forced) change of mission from '99.9% UDP' to 'far >> larger UDP packets plus heaps of TCP sessions'. > > =A0 =A0 =A0 =A0The data doesn't back that up. > > =A0 =A0 =A0 =A06000 UDP q/s results in 60 TCP q/s I was talking about the brave new world that has such wonderfully large DNSKEY and RRSIG RRSETs in it. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 11:39:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3E53A65A5; Fri, 31 Jul 2009 11:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 WR1ayY2MSRI5; Fri, 31 Jul 2009 11:39:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86C5D28C2BA; Fri, 31 Jul 2009 11:39:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWwmh-000A9G-Tj for namedroppers-data0@psg.com; Fri, 31 Jul 2009 18:24:51 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWwme-000A8U-Aw for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 18:24:49 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 46425327A96; Fri, 31 Jul 2009 18:24:47 +0000 (UTC) Received: from [10.123.163.63] (unknown [32.141.183.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 26F7B327A90; Fri, 31 Jul 2009 18:24:46 +0000 (UTC) References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> Message-Id: From: Michael Graff To: Paul Vixie In-Reply-To: <26168.1249007375@nsa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Fri, 31 Jul 2009 13:24:38 -0500 Cc: "namedroppers@ops.ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 30, 2009, at 21:29, Paul Vixie wrote: >> > what would it take to convince you? I would like to see someonefind out two things. One, if the bottleneck and fear of something that gas been around for many years (DNS over tcp) is on the equipment, os, or DNS server code. Two, how is this not a ddos vector waiting to happen today? That is, provisioning against stress and planning on ddos, how would an admin react differently in server and network capacity planning? In short, why is the increase if tcp in real queries a real problem when in a properly chosen algorithm and with reasonable ttl values, it can be minimized? --Michael -- to unsubscribe send a message to namedroppers-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 Jul 31 11:59:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EEF3A6AC8; Fri, 31 Jul 2009 11:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 MrcBUpEr70fl; Fri, 31 Jul 2009 11:59:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36B3A3A6DF2; Fri, 31 Jul 2009 11:59:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWxAg-000Dc9-BS for namedroppers-data0@psg.com; Fri, 31 Jul 2009 18:49:38 +0000 Received: from [2001:4f8:3:ba:203:47ff:fe6c:4a31] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWxAa-000DbI-Gb for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 18:49:36 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id E1629327A9C; Fri, 31 Jul 2009 18:49:31 +0000 (UTC) Received: from [10.121.166.167] (unknown [32.140.44.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 1D6B8327A99; Fri, 31 Jul 2009 18:49:31 +0000 (UTC) References: <4A702AE1.10201@isc.org> <80C086A4-2FF5-4F76-9AF9-05986637C423@cs.ucla.edu> <26168.1249007375@nsa.vix.com> Message-Id: From: Michael Graff To: Michael Graff In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Subject: Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03 Date: Fri, 31 Jul 2009 13:49:24 -0500 Cc: Paul Vixie , "namedroppers@ops.ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Appologies to all for not catching that my iPhone is choosing words badly. --Michael -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 13:22:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FF33A6CA1; Fri, 31 Jul 2009 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-1.552, 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 cSyAJvP9IP5K; Fri, 31 Jul 2009 13:22:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F81B3A6BE5; Fri, 31 Jul 2009 13:22:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWyW1-0003ld-6b for namedroppers-data0@psg.com; Fri, 31 Jul 2009 20:15:45 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWyVx-0003ky-G7 for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 20:15:43 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6VKFeHL025129 for ; Fri, 31 Jul 2009 16:15:40 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n6VKFegH025128 for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 16:15:40 -0400 (EDT) (envelope-from namedroppers) Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWtmo-0006f6-Kp for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 15:12:48 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MWtmj-0006kp-TV for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 15:12:42 +0000 Received: from desk.marajade.sandelman.ca ([209.87.252.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Jul 2009 15:12:41 +0000 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Jul 2009 15:12:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Michael Richardson Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Fri, 31 Jul 2009 11:12:30 -0400 Lines: 37 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) In-Reply-To: X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Roy Arends wrote: > I fear that there will be a significant period where the root has to > support both algorithms, after event1. That means that the DNSKEY set > becomes larger. That means that there will be more signatures in a > response. The DNSKEY set will have a minimum of 4 DNSKEYs. Assuming > 2Kbit KSKs and 1K ZSKs. That is going to be 6Kbit in key material. > During a KSK (not algorithm) roll, add 2Kbit key material. This results > in 8Kbit key material + 6Kbit signature material, which results in > 14Kbit, or a response size of at least 1792 bytes. (obviously this will > be a lot larger as this number _just_ shows the crypto) 1792 bytes is too big. Silly question: once RSASHA256 is available, can we "weaken" the RSASHA1 key, i.e. reduce it from 2Kbit to 1536, for instance. Does that buy us enough room? (If you want more security, you should validate RSASHA256) 2048*2+1536*2+2*1024 = 9216 bits = 1152 bytes. Can we avoid rolling both keysets at the same time? 2048 + 1536*2 + 2*1024 = 896 bytes. 2048*2 + 1536*1 + 2*1024 = 960 bytes. > EDNS0 buffer size doesn't help here. The bulk of the resolvers will fall > back to tcp, or fail due to dropped fragments if incorrect edns buffer > sizes are announced. > > We can significantly move this problem of large response size further in > the future if the root is signed with RSASHA2. But, that's not the option. The decision is: 1) sign with RSASHA1 now 2) sign with RSASHA256 in 1-2 years. Only, in 2 years the discussion will just be: 1) sign with RSASHA256 now. 2) sign with SHA-3 in 1-2 years. -- to unsubscribe send a message to namedroppers-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 Jul 31 13:22:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54753A6DF2; Fri, 31 Jul 2009 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGiue45AQfFz; Fri, 31 Jul 2009 13:22:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C146F3A6CA1; Fri, 31 Jul 2009 13:22:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWyVu-0003ko-AM for namedroppers-data0@psg.com; Fri, 31 Jul 2009 20:15:38 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWyVo-0003k5-UX for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 20:15:36 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6VKFUQJ025119 for ; Fri, 31 Jul 2009 16:15:30 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n6VKFUbb025118 for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 16:15:30 -0400 (EDT) (envelope-from namedroppers) Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWtJp-0001aI-C3 for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 14:42:51 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MWtJm-0005TY-0I for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 14:42:46 +0000 Received: from desk.marajade.sandelman.ca ([209.87.252.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Jul 2009 14:42:45 +0000 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Jul 2009 14:42:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Michael Richardson Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Fri, 31 Jul 2009 10:42:24 -0400 Lines: 36 Message-ID: References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) In-Reply-To: X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Rose, Scott W. wrote: > On 7/29/09 9:07 AM, "Patrik Faltstrom" wrote: >>> I think the suggestion that we start with SHA-1 then roll to SHA-2 >>> makes a fair amount of sense. If algorithm roll at the root really is >>> that scary, we should not wait until an emergency to try it. >> FWIW: This makes sense to me. >> >> What we do need is, for pure interoperability reasons, _one_ algorithm >> that is "the algorithm that is in use", and then a mechanism for >> rollover algorithms when needed. >> > I would agree with this, but different groups have opinions about what > should be "the" algorithm in use. That will hamper DNSSEC deployment in > some areas. If that can be worked out to one agreed upon algorithm, I'd be > very happy. ;-) I think we all agree that SHA-2 is the best algorithm today, but it is not available in the timeframe available. So, we have to make an *ENGINEERING* decision to go with SHA-1 now. The move to SHA-2 can be announced well in advance (we could make the announcement of a date now if we could coordinate with enough of the long-devel/deployment cycle vendors/operators. I'm thinking like Dec.31, 2012 or something like that) (The NIST replacement will be available by then, and maybe we would move directly to that, but I doubt it) This means that we can, as Rob points out, do this as a non-emergency key rollover. I do not believe that SHA-2 signatures are necessarily bigger than SHA-1 signatures (it's the number of bits of the RSA key that determines the size), but having two signatures for any length of time on things like ".com IN NS" may be a concern. (have most of the ccTLDs max'ed out the number of NS returns that fit into 576 bytes?) -- to unsubscribe send a message to namedroppers-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 Jul 31 14:16:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E9C3A6D2B; Fri, 31 Jul 2009 14:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSoSNZRCWdE1; Fri, 31 Jul 2009 14:16:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B1D73A6CCD; Fri, 31 Jul 2009 14:16:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzOz-000ChV-4w for namedroppers-data0@psg.com; Fri, 31 Jul 2009 21:12:33 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzOs-000Cgr-N3 for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 21:12:30 +0000 Received: from [10.31.200.165] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n6VLCM68025711; Fri, 31 Jul 2009 17:12:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 31 Jul 2009 17:12:12 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Issue with RFC 4034, section 3 and section 4 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I'm doing a review of RFC 4034 and found something I'm concerned about. Not a protocol issue but a specification issue. Section 3 The RRSIG Resource Record 3rd paragraph reads: # Because every authoritative RRset in a zone must be protected by a # digital signature, RRSIG RRs must be present for names containing a # CNAME RR. This is a change to the traditional DNS specification # [RFC1034], which stated that if a CNAME is present for a name, it is # the only type allowed at that name. A RRSIG and NSEC (see Section 4) # MUST exist for the same name as a CNAME resource record in a signed # zone. The text I am concerned about is "RRSIG RRs must be present for names containing a CNAME RR." My concern is over the word "containing" with DNAME's CNAME-synthesis in the back of my mind. I'd suggest a clarification be made (and carried in any appropriate document vehicle) to say: ..., even an explicitly defined CNAME RR(set) MUST have an a set of associated RRSIG(s). ("Explicitly defined" excludes CNAME RRsets that result from a wild card synthesis [RFC4592] or DNAME synthesis [RFC2672/bis].) Note that in the orginal text, "must" is not capitalized. I am supposing that is due to an editorial oversight. 4. The NSEC Resource Record 2nd paragraph reads: # Because every authoritative name in a zone must be part of the NSEC # chain, NSEC RRs must be present for names containing a CNAME RR. # This is a change to the traditional DNS specification [RFC1034], # which stated that if a CNAME is present for a name, it is the only # type allowed at that name. An RRSIG (see Section 3) and NSEC MUST # exist for the same name as does a CNAME resource record in a signed # zone. Again, "must" appears in small letters. The text that needs to be cleaned up is "An RRSIG (see Section 3) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone." But in this case, the clean up is not so important. Bearing in mind 4034 predates 5155 and any update won't: Domain names that own an explicit CNAME (excluding synthesized as a result of a wild card or DNAME) MUST have an NSEC RRset and its associated RRSIG (see section 3) records, if the zone uses NSEC-style negative answers. Editorial note to that: 1, we have to define "NSEC-style negative answers" in a glossary as "a configuration of DNSSEC in which a zone uses NSEC records whenever a negative result is needed to be expressed" - as opposed to NSEC3-style which has to expand the definition to treat opt-out. 2, The text does not mention NSEC3 because NSEC3 would be owned by a hash name, not a name with CNAME unless the hash name manages to be a name that would have a CNAME. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 14:35:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445FF3A6962; Fri, 31 Jul 2009 14:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+9odzrQTNGo; Fri, 31 Jul 2009 14:35:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC7093A67B7; Fri, 31 Jul 2009 14:35:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzfJ-000FDb-8r for namedroppers-data0@psg.com; Fri, 31 Jul 2009 21:29:25 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzfE-000FDB-AL for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 21:29:22 +0000 Received: from crankycanuck.ca (host-78-64-88-85.homerun.telia.com [78.64.88.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 321962FE8ED6; Fri, 31 Jul 2009 21:29:16 +0000 (UTC) Date: Fri, 31 Jul 2009 17:29:13 -0400 From: Andrew Sullivan To: dnsext-ads@tools.ietf.org Cc: namedroppers@ops.ietf.org, iesg-secretary@ietf.org Subject: [dnsext] Publication request for draft-ietf-dnsext-dnssec-rsasha256-14.txt Message-ID: <20090731212911.GF14838@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Esteemed Area Directors, This note requests publication of the following draft: Title : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-14.txt Date : 2009-07-30 Document shepherd: Andrew Sullivan The publication request includes a note for IANA, in section 1.d below. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Andrew Sullivan; yes; yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes; no. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document editor sent the document to the security directorate requesting review. A response was received from one member of the security directorate. It might be good if someone else also from the security directorate reviewed the document, because the person responding is also active in the DNSEXT working group. In particular, there was a question about the utility of the SHA-512 definition in here, and particularly whether that definition is acceptable given the limit on key size. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are two items to note. First, in making a final-pass check, I note that the examples in section 6 have (by mistake) actual algorithm numbers in them instead of {TBD1} and {TBD2}. Because these are just examples, I judge that they may be fixed as an editorial matter, so I didn't want to issue another version of the draft. As a matter for IANA, we would in fact like TBD1 to be 8 and TBD2 to be 10. This is because an early implementation used those two typecodes already. Secondly there is the question about SHA-512 in 1.c. Despite useful and considered feedback received from one commentator, we decided to go ahead leaving that section in because we believed that it does no real harm and because it has taken a surprisingly long time to build consensus around the document in the WG. I found no IPR disclosure in the database. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I judge the consensus to be strong and broad. A previous version of this document used algorithm aliases for NSEC and NSEC3 application, but several participants strongly objected to that strategy. This version of the document uses one algorithm identifier for both NSEC and NSEC3. The effect of this is that implementations that do not support NSEC3 will not be able to use SHA-2 either. The WG consensus is that, because of announced deployment of NSEC3 in large zones near the root of the DNS, it will be infeasible for a modern DNSSEC implementation not to support NSEC3. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The Shepherd has checked the nits. There are no other reviews to perform for this document as far as I understand. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes; No; Not a downref, but a reference to a non-RFC standard: [FIPS.180-3.2008] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008. As near as the Document Shepherd can tell, there is no RFC that outlines FIPS PUB 180-3, but that's what defines SHA-2, so we need the normative reference. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration does exist. There are reservatiions in a registry requested. The requested algorithm identifiers are marked as {TBD1} and {TBD 2}. See the remarks under item (1.d) above for a request for the actual numbers to be assigned. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No such formal language sections are in this document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Technical Summary 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). Working Group Summary The DNS Extensions Working Group had consensus to publish the document. A strong objection to an aliasing strategy for algorithm identifiers was lodged at one point, and that has been addressed in this version. Nobody has objected to this change. Document Quality The document received thorough review, and it is expected that vendors supporting DNSSEC will implement SHA-2 once the document is published. The document went through a large number of revisions before submission, reflecting the extensive feedback and detailed comments received. Best regards, Andrew Sullivan DNS Extensions WG Co-Chair -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 14:41:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5DF3A6A95; Fri, 31 Jul 2009 14:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWKGyw2ke4oA; Fri, 31 Jul 2009 14:41:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 302383A69A7; Fri, 31 Jul 2009 14:41:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzoS-000GcL-VZ for namedroppers-data0@psg.com; Fri, 31 Jul 2009 21:38:52 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzoI-000GbU-Gn for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 21:38:50 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=Bd4RfVDcjw6EhS2jzwz5PoPuHwzHQ5z50y6xQ+WqOh2V+c0GYZYvGPZxStXSf+QAmrC2Ys7QqWqMFFEYufR4xidCeAzEs9pyPqFFfTGxW9PjY+DElnwCERNeR4dpe1mZ; Received: from [74.12.26.19] (helo=[10.255.253.117]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MWzn3-000KEO-Gd; Fri, 31 Jul 2009 21:37:25 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> From: Joe Abley To: Michael Richardson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Date: Fri, 31 Jul 2009 17:37:24 -0400 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 31-Jul-2009, at 10:42, Michael Richardson wrote: > but having two signatures for any length of time on things like > ".com IN NS" may be a concern. Note that delegation NS RRSets in the root zone (and glue A and AAAA RRSets) will not be signed. Those sets get signed in the zones which are authoritative for them. 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 Jul 31 15:03:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF693A6AB2; Fri, 31 Jul 2009 15:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ashOLCDDIv9t; Fri, 31 Jul 2009 15:03:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1AC73A68DF; Fri, 31 Jul 2009 15:03:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX08M-000JQb-3t for namedroppers-data0@psg.com; Fri, 31 Jul 2009 21:59:26 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX08I-000JPq-6Y for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 21:59:23 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 833801C6CF; Fri, 31 Jul 2009 22:59:20 +0100 (BST) Cc: Michael Richardson , namedroppers@ops.ietf.org Message-Id: <64D84C2D-9F19-471F-BB25-554531D31744@rfc1035.com> From: Jim Reid To: Joe Abley In-Reply-To: <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] operational impact of signed responses/referrals Date: Fri, 31 Jul 2009 22:59:20 +0100 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 31 Jul 2009, at 22:37, Joe Abley wrote: > Note that delegation NS RRSets in the root zone (and glue A and AAAA > RRSets) will not be signed. Those sets get signed in the zones which > are authoritative for them. True, but it doesn't detract from the point Michael was making about the operational impact of bloat in signed replies from busy name servers. It'll just be the TLD name servers which have to contend this issue instead of the root servers when the TLD's NS RRset is signed. I'm not sure if that's a help or hindrance operationally. On the one hand, it should mean the root servers would get fewer TCP retries and/ or EDNS0 jumbograms than first thought. On the other, that load will hit TLD name server infrastructure which in most cases isn't as robust as the root servers. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 15:07:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED453A6ACD; Fri, 31 Jul 2009 15:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5WKQCwTgc-P; Fri, 31 Jul 2009 15:07:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59A6F3A6ABC; Fri, 31 Jul 2009 15:07:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX0D4-000KG0-6D for namedroppers-data0@psg.com; Fri, 31 Jul 2009 22:04:18 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX0Cv-000KEb-P5 for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 22:04:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=Oe9sljCt2L05Nf57WyzCCFuY5FMB7YAhbeGJJNuTa0MT8YxTPijxt9evs9EoasBogvhi0do3/dGpW9tpAuw05X4ZUYaqroNolmhIqopg/8VPk1R3QEHHrNDfMYtZydDz; Received: from [74.12.26.19] (helo=[10.255.253.117]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX0Cu-000KQM-42; Fri, 31 Jul 2009 22:04:08 +0000 Cc: Michael Richardson , namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: Jim Reid In-Reply-To: <64D84C2D-9F19-471F-BB25-554531D31744@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Re: operational impact of signed responses/referrals Date: Fri, 31 Jul 2009 18:04:07 -0400 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> <64D84C2D-9F19-471F-BB25-554531D31744@rfc1035.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 31-Jul-2009, at 17:59, Jim Reid wrote: > On 31 Jul 2009, at 22:37, Joe Abley wrote: > >> Note that delegation NS RRSets in the root zone (and glue A and >> AAAA RRSets) will not be signed. Those sets get signed in the zones >> which are authoritative for them. > > True, but it doesn't detract from the point Michael was making 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 Jul 31 16:02:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528BA3A6A67; Fri, 31 Jul 2009 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0CaJ3aqnFkR; Fri, 31 Jul 2009 16:02:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C64F3A6973; Fri, 31 Jul 2009 16:02:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX100-0001a0-VR for namedroppers-data0@psg.com; Fri, 31 Jul 2009 22:54:52 +0000 Received: from [209.85.219.228] (helo=mail-ew0-f228.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX0zv-0001ZS-7z for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 22:54:49 +0000 Received: by ewy28 with SMTP id 28so1917571ewy.41 for ; Fri, 31 Jul 2009 15:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ABzNDLMcdHUDQ/2Pb2BebppzmU2w/GxyT+EvKNz1Yeo=; b=wkFLIRUIkazNwL95K/obPwQ0Jn8gGK0gbrUS9wEyW+Hsy/Wq7sK5Jt5w+R5WznGySO VIDXmyPPswxt/UfKOz+Vq6WvuLkHfEbfFya9e43oBP2I51AXfSBMx9QzLA+4dNb1ViBw ydxl5i6zefM7cQpu0lyridwmjKDO32MufsM+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=qHCNpOtD3JaGzoqWEi9OISEq/PImjkKean9zP73QhCLuW1zirlAtNDoaiy6DMoRbhh vYLQ1Iw5o0eoJZ0oOtjwGJrtOcCMUL6DcQBL349ax8D1EIyG2DfifllHLKYiZe2vVN6J hjRB0dyMT/x1C77c5AeUf+SRZE8rm+Gk+9p+4= MIME-Version: 1.0 Received: by 10.210.143.17 with SMTP id q17mr3747044ebd.97.1249080885083; Fri, 31 Jul 2009 15:54:45 -0700 (PDT) In-Reply-To: <64D84C2D-9F19-471F-BB25-554531D31744@rfc1035.com> References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <7ECD9D0F-81ED-4A3C-8BD4-A6BBC0B6E402@hopcount.ca> <64D84C2D-9F19-471F-BB25-554531D31744@rfc1035.com> From: bert hubert Date: Sat, 1 Aug 2009 00:54:25 +0200 Message-ID: <3efd34cc0907311554r255fc1c2l51b5360f2a774c86@mail.gmail.com> Subject: Re: [dnsext] operational impact of signed responses/referrals To: Jim Reid Cc: Joe Abley , Michael Richardson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 31, 2009 at 11:59 PM, Jim Reid wrote: > True, but it doesn't detract from the point Michael was making about the > operational impact of bloat in signed replies from busy name servers. It'll > just be the TLD name servers which have to contend this issue instead of the > root servers when the TLD's NS RRset is signed. I'm not sure if that's a > help or hindrance operationally. On the one hand, it should mean the root > servers would get fewer TCP retries and/or EDNS0 jumbograms than first Much love for introducing me to the word 'jumbogram' :-) The wikipedia even has a page on it. But seriously, it would be really great if the .ORG operators could provide us with more operational details on the ratio of UDP/TCP queries, TC responses etc. Because so far we are discussing a lot based on suppositions, and not on data. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 31 16:34:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AE03A68F1; Fri, 31 Jul 2009 16:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO9vh8WzQdu0; Fri, 31 Jul 2009 16:34:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51BEA3A689C; Fri, 31 Jul 2009 16:33:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX1RB-0005tj-2p for namedroppers-data0@psg.com; Fri, 31 Jul 2009 23:22:57 +0000 Received: from [209.85.132.245] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX1R5-0005t6-Sv for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 23:22:54 +0000 Received: by an-out-0708.google.com with SMTP id c3so1217786ana.26 for ; Fri, 31 Jul 2009 16:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kKIxr/Ekn4nntxZYVg14VogUY+jCLbldwpsPf8DujNE=; b=s4dVbb1pxgkaUtff/Rhhdm/jwNt1a0vGyyjdeP5Q+h2Y8CEcOKfBcMPRfDkbukdUyJ Jch9Z+scGNpNMjaSN89+TYrNrlVW0CNmvz6Sy1WFPZf83jH6UWGgCmjNGq6SKxgCmTJi B+emppOXVuOPMU7zOxH8YvXQ1x+HS3mUhJ4YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=e2o4EdsexchRumytLr6DNWQAgizu+5iW8uLEoAEGSMtCBubOJi/6KEmPLb8aL19nNG 5dpXE2EU0e/XK+83WaAHPi5ytA+p06Qi34J0QZengPaZXKgafCHEyeEu9GZpgVI4+cKL SkzohQXPJvY3JWuC3wLDWe38dpHYFGDtOZoHA= Received: by 10.100.232.17 with SMTP id e17mr2932546anh.107.1249082570512; Fri, 31 Jul 2009 16:22:50 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id b14sm1180163ana.16.2009.07.31.16.22.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 16:22:49 -0700 (PDT) Message-ID: <4A737CC7.4060902@gmail.com> Date: Fri, 31 Jul 2009 19:22:47 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Michael Richardson wrote: > I think we all agree that SHA-2 is the best algorithm today, but it is > not available in the timeframe available. So, we have to make an > *ENGINEERING* decision to go with SHA-1 now. > I agree. At the beginning of the thread, I was my usual conservative on security self, thinking "Bite the bullet, deploy the stronger algorithm." Then, I read that the only pre-release code had been backed out. Let's remember the mantra: "rough consensus and RUNNING CODE." Since there's no running code for SHA-2, deploy SHA-1 now. It's not likely to be broken for this threat class anytime in the next year. After all, we know of threats that such minimal signing will prevent NOW! > The move to SHA-2 can be announced well in advance (we could make the > announcement of a date now if we could coordinate with enough of the > long-devel/deployment cycle vendors/operators. I'm thinking like > Dec.31, 2012 or something like that) > Oh, I'd be even more aggressive. Start the phase-in exactly 30 days after two interoperable implementations become available. Treat it like an actual threat. Push hard, to test the process. Then, 30 days after that, the old SHA-1 root key will go away. Aim for 2 interoperable implementations by February 1st. Aim for starting rollover on March 1st. Aim for retiring SHA-1 by April 1st. -- to unsubscribe send a message to namedroppers-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 Jul 31 16:52:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4893A68F1; Fri, 31 Jul 2009 16:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP96TOKWV1AX; Fri, 31 Jul 2009 16:52:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C99A3A67F6; Fri, 31 Jul 2009 16:52:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX1n6-0009OG-SB for namedroppers-data0@psg.com; Fri, 31 Jul 2009 23:45:36 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX1my-0009Lj-Bj for namedroppers@ops.ietf.org; Fri, 31 Jul 2009 23:45:33 +0000 Received: from crankycanuck.ca (host-78-64-88-85.homerun.telia.com [78.64.88.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D53542FE8ED6 for ; Fri, 31 Jul 2009 23:45:26 +0000 (UTC) Date: Fri, 31 Jul 2009 19:45:24 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2 Message-ID: <20090731234524.GL14838@shinkuro.com> References: <36267B58-AC3A-492D-A5F1-BD53A07B220B@cisco.com> <4A737CC7.4060902@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A737CC7.4060902@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 31, 2009 at 07:22:47PM -0400, William Allen Simpson wrote: > Aim for retiring SHA-1 by April 1st. One is tempted to read that suggestion as significant. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: