From minuetish@a54321.com Sun Feb 1 10:26: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 9C36828C10C for ; Sun, 1 Feb 2009 10:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.407 X-Spam-Level: X-Spam-Status: No, score=-47.407 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_PACBELL_D=3.944, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 2LJBEsKQWrrX for ; Sun, 1 Feb 2009 10:26:56 -0800 (PST) Received: from adsl-69-109-168-8.dsl.pltn13.pacbell.net (adsl-69-109-168-8.dsl.pltn13.pacbell.net [69.109.168.8]) by core3.amsl.com (Postfix) with SMTP id 4051E3A6807 for ; Sun, 1 Feb 2009 10:26:54 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090201182655.4051E3A6807@core3.amsl.com> Date: Sun, 1 Feb 2009 10:26:54 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.squarehard.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://squarehard.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 9, B144. 084 Clements Road. London. SE12 8DG

From mcomiske@acuraofriverside.com Sun Feb 1 13:02:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1613A6A44 for ; Sun, 1 Feb 2009 13:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.795 X-Spam-Level: X-Spam-Status: No, score=-9.795 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_AU=0.377, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 djEJzhhBTb4b for ; Sun, 1 Feb 2009 13:02:58 -0800 (PST) Received: from 189-92-5-102.3g.claro.net.br (189-93-40-210.3g.claro.net.br [189.93.40.210]) by core3.amsl.com (Postfix) with SMTP id 99F783A6BA0 for ; Sun, 1 Feb 2009 13:02:27 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090201210234.99F783A6BA0@core3.amsl.com> Date: Sun, 1 Feb 2009 13:02:27 -0800 (PST)

From dnsea@yahoo.com.tw Sun Feb 1 17:23: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 84D193A6849 for ; Sun, 1 Feb 2009 17:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.212 X-Spam-Level: X-Spam-Status: No, score=-31.212 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_GET_MEDS=2.75, FH_RELAY_NODNS=1.451, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, 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, RDNS_NONE=0.1, TVD_QUAL_MEDS=3.568, 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 9ZGVjJpW3JkZ for ; Sun, 1 Feb 2009 17:23:21 -0800 (PST) Received: from amerblind.outbound.ed10.com (unknown [41.196.80.192]) by core3.amsl.com (Postfix) with SMTP id 230E43A677C for ; Sun, 1 Feb 2009 17:23:20 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: dnsext-archive@ietf.org Subject: RE: US Pharmacy Message 57374 From: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090202012321.230E43A677C@core3.amsl.com> Date: Sun, 1 Feb 2009 17:23:20 -0800 (PST) Dear dnsext-archive@ietf.org! Want to be a perfect lover? Want to boost your sexual power twice? Look our price! http://uvz.beyrepep.cn?uq We do guarantee high-quality medications, instant worldwide delivery and friendly support! Pfizer is a licensee of the TRUSTe Privacy Program! From mysstampsn@absolutecollection.com Mon Feb 2 07:08: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 36CBD3A67E6 for ; Mon, 2 Feb 2009 07:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.185 X-Spam-Level: X-Spam-Status: No, score=-44.185 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58HNTIg9ihUv for ; Mon, 2 Feb 2009 07:08:51 -0800 (PST) Received: from adah172.neoplus.adsl.tpnet.pl (adah172.neoplus.adsl.tpnet.pl [83.11.243.172]) by core3.amsl.com (Postfix) with SMTP id 332413A680E for ; Mon, 2 Feb 2009 07:08:43 -0800 (PST) To: Subject: Invoice from itunes.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090202150845.332413A680E@core3.amsl.com> Date: Mon, 2 Feb 2009 07:08:43 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.acceptancefun.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://acceptancefun.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 1, B053. 462 Clements Road. London. SE41 3DG

From mdromeros@3a-grupo.com Mon Feb 2 08:34: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 674DF3A6BB5 for ; Mon, 2 Feb 2009 08:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.268 X-Spam-Level: X-Spam-Status: No, score=-45.268 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRMOnAwl9TwN for ; Mon, 2 Feb 2009 08:34:15 -0800 (PST) Received: from aank149.neoplus.adsl.tpnet.pl (aank149.neoplus.adsl.tpnet.pl [83.5.92.149]) by core3.amsl.com (Postfix) with SMTP id 1C5193A6828 for ; Mon, 2 Feb 2009 08:34:11 -0800 (PST) To: Subject: Customer Receipt/Purchase Confirmation From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090202163413.1C5193A6828@core3.amsl.com> Date: Mon, 2 Feb 2009 08:34:11 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.surfacecollect.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://surfacecollect.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 2, B818. 422 Clements Road. London. SE22 0DG

From karmutlu@anadolu.edu.tr Mon Feb 2 19:15: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 E345228C228 for ; Mon, 2 Feb 2009 19:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_AT=0.424, HELO_EQ_DSL=1.129, HOST_EQ_AT=0.745, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_32=1.778, 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_XBL=3.033, TVD_RCVD_IP=1.931, 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 cTYpMmWIJ+Q4 for ; Mon, 2 Feb 2009 19:15:08 -0800 (PST) Received: from 85-124-58-170.static.xdsl-line.inode.at (85-124-58-170.static.xdsl-line.inode.at [85.124.58.170]) by core3.amsl.com (Postfix) with SMTP id 294483A6BE3 for ; Mon, 2 Feb 2009 19:15:05 -0800 (PST) To: Subject: Customer Receipt/Purchase Confirmation From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090203031507.294483A6BE3@core3.amsl.com> Date: Mon, 2 Feb 2009 19:15:05 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 8, B248. 762 Clements Road. London. SE60 4DG

From owner-namedroppers@ops.ietf.org Tue Feb 3 03:33: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 5DF043A6991; Tue, 3 Feb 2009 03:33:49 -0800 (PST) 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 P2PASyK9ueZM; Tue, 3 Feb 2009 03:33:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F07C3A67B2; Tue, 3 Feb 2009 03:33:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LUJNa-000Obp-GE for namedroppers-data0@psg.com; Tue, 03 Feb 2009 11:23:46 +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 1LUJNX-000ObS-D8 for namedroppers@ops.ietf.org; Tue, 03 Feb 2009 11:23:44 +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 n13BNXsJ003566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 12:23:34 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49882935.5080705@nlnetlabs.nl> Date: Tue, 03 Feb 2009 12:23:33 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Michael StJohns CC: David Blacka , namedroppers@ops.ietf.org, weiler@tislabs.com Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit References:

<49704490.20906@nlnetlabs.nl> <8F6E3F48-C3A9-4497-96FC-785B1EF5F160@verisign.com> <200901170829.n0H8TmVf035052@omval.tednet.nl> In-Reply-To: <200901170829.n0H8TmVf035052@omval.tednet.nl> 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.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 03 Feb 2009 12:23:35 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael StJohns wrote: > At 02:59 PM 1/16/2009, David Blacka wrote: >> Or to put this another way, how does CD change a response? If it does >> anything, it changes a DNSSEC response to a SERVFAIL, which isn't >> cached. > > This is the point that I keep trying to forget about DNSSEC - and I think I succeeded too well this time. David is absolutely correct. :-) Delete anything I said about setting the CD bit in response to what's in cache. OK >> I do think that the dnssec-bis-updates draft section 4.7 could say: >> >> When processing a request with the CD bit set, the resolver MUST set >> the CD bit on its upstream queries. >> >> Furthermore, if the validating recursive resolver has a trust >> anchor covering a request, it >> SHOULD set the CD bit on its upstream query regardless of the CD >> bit setting of the request. > > MUST or SHOULD here? I think if you've configured a trust anchor you've accepted responsibility to resolve according to local policy so I'd put this as a MUST. > > I can't think of a reasonable reason why you would set a trust anchor and not set the CD bit in the upstream. [OK - I can think of an unreasonable reason - local resolver has .COM trust anchor, upstream resolver has FOO.COM trust anchor, but not .COM - upstream filters FOO.COM if data is bad but passes through the rest of .COM. I don't think this makes a lot of sense though - the local resolver doesn't necessarily have a clue what trust anchors are configured in the upstream resolver so it can't really make a decent decision on whether to set/not set the CD bit. The local resolver would have to know that the upstream resolver has a FOO.COM trust anchor and to not set the bit for those queries - seems complicated ] > > I can live with the text as above, and will bow to the consensus with respect to MUST or SHOULD. I can live with the text too. For SHOULD or MUST - I can imagine deployment where servers do not set upstream CD bit because the operator wants simple caches to forward queries towards a validating server (that has all the keys) - and thus SHOULD. If you need explanatory text: 'If so configured, a recursive resolver could opt to not set the CD bit to allow upstream validation'. I do not think this explanatory text is needed (for dnssec-bis updates). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmIKTQACgkQkDLqNwOhpPiZGQCfar4f3tCba2bJlCJaSaLPnJRX QSMAn3spCJyjKrbMVmNNcKNyKpPGdCeJ =5W5t -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 3 04:17: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 EF4063A68FF; Tue, 3 Feb 2009 04:17:25 -0800 (PST) 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 8y+JSRp2VLz7; Tue, 3 Feb 2009 04:17:25 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C8523A63EB; Tue, 3 Feb 2009 04:17:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LUK9E-0001zi-OX for namedroppers-data0@psg.com; Tue, 03 Feb 2009 12:13:00 +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 1LUK9B-0001z9-FB for namedroppers@ops.ietf.org; Tue, 03 Feb 2009 12:12: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 n13CCl6Z007702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 13:12:47 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <498834BF.2080607@nlnetlabs.nl> Date: Tue, 03 Feb 2009 13:12:47 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ralph Droms CC: Stephane Bortzmeyer , =?ISO-8859-1?Q?Ond=3Fej_Su?= =?ISO-8859-1?Q?r=FD?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 References: <20090121074629.GA5280@nic.fr> <20090123113617.GA23702@nic.fr> <0CDC72D7-0690-44FF-9C5F-5DA5143D1B5E@cisco.com> In-Reply-To: <0CDC72D7-0690-44FF-9C5F-5DA5143D1B5E@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 03 Feb 2009 13:12:47 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Do implementations in the various client devices support short DHCP lease times? I think in a typical customer scenario, the devices boot within seconds of one another. Giving a resolver address in DHCP makes the customer device at least try to send DNS queries to the proxy - and most importantly have a timeout on that, show some blinking icon that it is busy connecting. When the WAN goes up, the proxy can deliver those queries - I guess the proxy also has resends and timeouts. After the WAN goes up the reply is sent from the proxy (cannot route that reply since the client device does not yet know the upstream DNS server it came from). If the client device got no DNS address, it would likely show an instant failure (network not available or something) to the user. So with the DNS proxy the edge router starts supporting DNS usage about one second (or more if longer timeouts) before the WAN goes up, from a user-experience point of view. Best regards, Wouter Ralph Droms wrote: > Yes, no DHCP and link-local addresses are another possibility. However, > there may be other information to be delivered to the clients via DHCP, > and some hosts/applications may not do well with a switch from > link-local to routable addresses once DHCP actually runs. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmINL4ACgkQkDLqNwOhpPg8CgCfQea52De3/xtjToHKWEbHSD0a 9kwAn1+aglvNq1efChT8rvq4wofhzRui =7Wyd -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 3 04:20: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 48C773A69BA; Tue, 3 Feb 2009 04:20:19 -0800 (PST) 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 yxM9RwtU16QW; Tue, 3 Feb 2009 04:20:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 584CC3A67B2; Tue, 3 Feb 2009 04:20:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LUKBS-00027u-TZ for namedroppers-data0@psg.com; Tue, 03 Feb 2009 12:15:18 +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 1LUKBP-00027d-Ut for namedroppers@ops.ietf.org; Tue, 03 Feb 2009 12:15:17 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n13CF463007775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 13:15:06 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49883548.10209@nlnetlabs.nl> Date: Tue, 03 Feb 2009 13:15:04 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Andreas Gustafsson CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] axfr-clarify-10 section 3.2, Delegation Records References: <18816.27993.86589.976941@guava.gson.org> In-Reply-To: <18816.27993.86589.976941@guava.gson.org> 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.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 03 Feb 2009 13:15:06 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 (if +1s are appreciated). Andreas Gustafsson wrote: > The quoted paragraph appears to be a somewhat mangled version of text > I suggested. Perhaps the following would be clearer: > > 4) This requirement is necessary to ensure that retrieving a given > (zone,serial) pair by AXFR yields the exact same set of resource > records no matter which of the zone's authoritative servers is > chosen as the source of the transfer. > > If an AXFR server were allowed to respond with the authoritative > NS RRset of a child zone instead of a glue NS RRset in the zone > being transferred, the set of records returned could vary depending > on whether or not the server happens to also be authoritative for > the child zone. > > The property that a given (zone,serial) pair corresponds to a > single, well-defined set of records is necessary for the correct > operation of incremental transfer protocols such as IXFR > [RFC1995]. For example, a client may retrieve a zone by AXFR from > one server, and then apply an incremental change obtained by IXFR > from a different server. If the two servers have different ideas > of the zone contents, the client can end up attempting to > incrementally add records that already exist or to delete records > that do not exist. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmINUgACgkQkDLqNwOhpPg40wCfeK1C3tBUesQkdkMjdJ9UinfY heQAnjMzR8f9DyoyqBveeybsHdEGDh94 =F6cL -----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 laufer5@aig.com Tue Feb 3 12: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 9590A28C153 for ; Tue, 3 Feb 2009 12:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.384 X-Spam-Level: X-Spam-Status: No, score=-23.384 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, 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 mIBX4PcE0tky for ; Tue, 3 Feb 2009 12:04:07 -0800 (PST) Received: from affirm.org.au (unknown [200.186.114.158]) by core3.amsl.com (Postfix) with SMTP id E38BB28C1B6 for ; Tue, 3 Feb 2009 12:04:01 -0800 (PST) To: Subject: Outsourcing Inside From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090203200401.E38BB28C1B6@core3.amsl.com> Date: Tue, 3 Feb 2009 12:04:01 -0800 (PST)

Special Offers by email

Dear our client,

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

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

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

Best regards,

First Online Business Brothers.

From owner-namedroppers@ops.ietf.org Tue Feb 3 13: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 E4CE73A6904; Tue, 3 Feb 2009 13:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 z3f2E359xV3D; Tue, 3 Feb 2009 13:34:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 007C23A680C; Tue, 3 Feb 2009 13:34:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LUSm6-000AKw-NC for namedroppers-data0@psg.com; Tue, 03 Feb 2009 21:25:42 +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 1LUSm4-000AKf-Mp for namedroppers@ops.ietf.org; Tue, 03 Feb 2009 21:25:41 +0000 Received: from [69.94.197.79] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n13LPOTo053046; Tue, 3 Feb 2009 16:25:28 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <49883548.10209@nlnetlabs.nl> References: <18816.27993.86589.976941@guava.gson.org> <49883548.10209@nlnetlabs.nl> Date: Tue, 3 Feb 2009 16:25:21 -0500 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: [dnsext] axfr-clarify-10 section 3.2, Delegation Records Cc: Andreas Gustafsson , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 13:15 +0100 2/3/09, W.C.A. Wijngaards wrote: >+1 (if +1s are appreciated). Editors always appreciate +1's ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 3 13:54:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFFE3A6904; Tue, 3 Feb 2009 13:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1CNbbqWLLhm; Tue, 3 Feb 2009 13:54:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80A493A68A2; Tue, 3 Feb 2009 13:54:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LUT93-000BlL-V6 for namedroppers-data0@psg.com; Tue, 03 Feb 2009 21:49:25 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LUT8z-000BkP-So for namedroppers@ops.ietf.org; Tue, 03 Feb 2009 21:49:23 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id D697C11402B; Tue, 3 Feb 2009 21:49:19 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 2A532E6069; Tue, 3 Feb 2009 21:49: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 n13LnFbS049385; Wed, 4 Feb 2009 08:49:15 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200902032149.n13LnFbS049385@drugs.dv.isc.org> To: Edward Lewis Cc: "W.C.A. Wijngaards" , Andreas Gustafsson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] axfr-clarify-10 section 3.2, Delegation Records In-reply-to: Your message of "Tue, 03 Feb 2009 16:25:21 CDT." Date: Wed, 04 Feb 2009 08:49:15 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Edward Lewis writes: > At 13:15 +0100 2/3/09, W.C.A. Wijngaards wrote: > > >+1 (if +1s are appreciated). > > Editors always appreciate +1's ;) For the record there are also non IXFR related examples where the the master of the parent zone is a slave of the child zone and the other parents don't the changes added to the parent zone as the child zone has not yet transferred. Possible cause: email notifying parent arrives before refresh timer goes off. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From dnsdurling@dmci.net Wed Feb 4 07:54: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 269A53A6A59 for ; Wed, 4 Feb 2009 07:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.991 X-Spam-Level: X-Spam-Status: No, score=-33.991 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S2fWKmBWO2g for ; Wed, 4 Feb 2009 07:54:40 -0800 (PST) Received: from amerblind.outbound.ed10.com (unknown [194.44.160.178]) by core3.amsl.com (Postfix) with SMTP id CB2E33A692F for ; Wed, 4 Feb 2009 07:54:39 -0800 (PST) To: Subject:RE:Pharmacy Message 50178 From:dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html;"charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20090204155439.CB2E33A692F@core3.amsl.com> Date: Wed, 4 Feb 2009 07:54:39 -0800 (PST)

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2009 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

From momohime@agate.plala.or.jp Thu Feb 5 05:05:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D55F3A6AFE for ; Thu, 5 Feb 2009 05:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.01 X-Spam-Level: X-Spam-Status: No, score=-26.01 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZOI3xOVdTpa for ; Thu, 5 Feb 2009 05:05:10 -0800 (PST) Received: from cpc2-amer1-0-0-cust455.watf.cable.ntl.com (cpc2-amer1-0-0-cust455.watf.cable.ntl.com [81.110.161.200]) by core3.amsl.com (Postfix) with SMTP id 4C6F93A6909 for ; Thu, 5 Feb 2009 05:05:08 -0800 (PST) To: Subject: Get a Digital Shipping Today! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090205130509.4C6F93A6909@core3.amsl.com> Date: Thu, 5 Feb 2009 05:05:08 -0800 (PST)

If you dont see text or image please see this email as a webpage.

February 2009

WorldWide Digital Shipping
Only best for you

Get a Digital Shipping Postal Scale to Save Time, Money!

Thank you for use to WorldWide DS' programm.

You gave WorldWide DS permission to send you this email. Please add vus to your address book or safe sender list.
Conservation International 4863 Crystal Drive, Suite 667, Arlington, VA 15470, USA
Review our Privacy Policy and Acceptable Use Policy.
Unsubscribe or manage your Subscription Preferences

Crafted and delivered by WorldWide DS' Mail Dog!

From mielir@aidala.com Thu Feb 5 05:32: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 228A03A6909 for ; Thu, 5 Feb 2009 05:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.607 X-Spam-Level: X-Spam-Status: No, score=-27.607 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, HELO_EQ_BR=0.955, HOST_EQ_BR=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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_RECV_VIRTUACOMBR=1.193, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 UNisB-W5fAA6 for ; Thu, 5 Feb 2009 05:32:11 -0800 (PST) Received: from c906c3c6.virtua.com.br (c906c3c6.virtua.com.br [201.6.195.198]) by core3.amsl.com (Postfix) with SMTP id 131753A681D for ; Thu, 5 Feb 2009 05:32:09 -0800 (PST) To: Subject: Messgage number 18520 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090205133210.131753A681D@core3.amsl.com> Date: Thu, 5 Feb 2009 05:32:09 -0800 (PST)

If you dont see text or image please see this email as a webpage.

February 2009

WorldWide Digital Shipping
Only best for you

Get a Digital Shipping Postal Scale to Save Time, Money!

Thank you for use to WorldWide DS' programm.

You gave WorldWide DS permission to send you this email. Please add vus to your address book or safe sender list.
Conservation International 0611 Crystal Drive, Suite 412, Arlington, VA 82284, USA
Review our Privacy Policy and Acceptable Use Policy.
Unsubscribe or manage your Subscription Preferences

Crafted and delivered by WorldWide DS' Mail Dog!

From onno@alexanderschool.nl Fri Feb 6 16: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 A67ED3A6B3F for ; Fri, 6 Feb 2009 16:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 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_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 DNNTVALok8hg for ; Fri, 6 Feb 2009 16:11:34 -0800 (PST) Received: from adsl-69-155-134-181.dsl.hstntx.swbell.net (adsl-69-155-134-181.dsl.hstntx.swbell.net [69.155.134.181]) by core3.amsl.com (Postfix) with SMTP id B7CAE3A6A30 for ; Fri, 6 Feb 2009 16:11:32 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090207001133.B7CAE3A6A30@core3.amsl.com> Date: Fri, 6 Feb 2009 16:11:32 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.excitelucid.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://excitelucid.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B548. 918 Clements Road. London. SE04 2DG

From mendozsm@ah.org Fri Feb 6 19:30: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 A81673A6988 for ; Fri, 6 Feb 2009 19:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.962 X-Spam-Level: X-Spam-Status: No, score=-20.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt9ahSrvtA5N for ; Fri, 6 Feb 2009 19:30:37 -0800 (PST) Received: from admtl.com (unknown [190.158.56.222]) by core3.amsl.com (Postfix) with SMTP id 6F2573A68A9 for ; Fri, 6 Feb 2009 19:30:36 -0800 (PST) To: Subject: Outsourcing Inside From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090206-0, 06/02/2009), Outbound message X-Antivirus-Status: Not-Tested Message-Id: <20090207033036.6F2573A68A9@core3.amsl.com> Date: Fri, 6 Feb 2009 19:30:36 -0800 (PST)

Special Offers by email

Dear our client,

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

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

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

Best regards,

First Online Business Brothers.

From dnsbuilding@tiscali.co.uk Sun Feb 8 18:29: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 ADEE13A69E3 for ; Sun, 8 Feb 2009 18:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.105 X-Spam-Level: X-Spam-Status: No, score=-32.105 tagged_above=-999 required=5 tests=[AWL=22.647, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, 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, RDNS_DYNAMIC=0.1, 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 ViulTAuSAZWn for ; Sun, 8 Feb 2009 18:29:12 -0800 (PST) Received: from amerblind.outbound.ed10.com (ppp-58-9-175-199.revip2.asianet.co.th [58.9.175.199]) by core3.amsl.com (Postfix) with SMTP id 0F18B3A69A6 for ; Sun, 8 Feb 2009 18:29:08 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: dnsext-archive@ietf.org Subject: RE: Pharmacy Message 4765087 From: MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090209022911.0F18B3A69A6@core3.amsl.com> Date: Sun, 8 Feb 2009 18:29:08 -0800 (PST) You can save 54% with us!

Your discount code #VNM.3388984 From jbdfinger@amtelecom.net Tue Feb 10 03:55: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 C50A43A67F5 for ; Tue, 10 Feb 2009 03:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_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 BlSQOSIKZxTV for ; Tue, 10 Feb 2009 03:55:07 -0800 (PST) Received: from aacps.org (unknown [85.106.136.94]) by core3.amsl.com (Postfix) with SMTP id D46933A67A7 for ; Tue, 10 Feb 2009 03:55:05 -0800 (PST) To: Subject: from admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090210115505.D46933A67A7@core3.amsl.com> Date: Tue, 10 Feb 2009 03:55:05 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.mendfull.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://mendfull.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B127. 078 Clements Road. London. SE16 7DG

From mahoneym@allkids.org Tue Feb 10 06:49:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8CDD3A69CA for ; Tue, 10 Feb 2009 06:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.262 X-Spam-Level: X-Spam-Status: No, score=-43.262 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjxsN6UvyadP for ; Tue, 10 Feb 2009 06:49:06 -0800 (PST) Received: from 3bd.com (unknown [59.178.163.69]) by core3.amsl.com (Postfix) with SMTP id 9A99E3A6A55 for ; Tue, 10 Feb 2009 06:49:04 -0800 (PST) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090210144904.9A99E3A6A55@core3.amsl.com> Date: Tue, 10 Feb 2009 06:49:04 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.lightvital.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://lightvital.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 6, B483. 352 Clements Road. London. SE83 5DG

From dnsfopp@verizon.net Tue Feb 10 11:32: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 594A73A6BD3 for ; Tue, 10 Feb 2009 11:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.195 X-Spam-Level: X-Spam-Status: No, score=-45.195 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_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HOST_EQ_BROADBND=1.118, HOST_EQ_RU=0.875, 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, 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 kG55yGCDfmXd for ; Tue, 10 Feb 2009 11:32:17 -0800 (PST) Received: from amerblind.outbound.ed10.com (89-178-174-178.broadband.corbina.ru [89.178.174.178]) by core3.amsl.com (Postfix) with SMTP id 1C1803A69E9 for ; Tue, 10 Feb 2009 11:32:16 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: dnsext-archive@ietf.org Subject:RE: Pharmacy Message 5259809 From: MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090210193217.1C1803A69E9@core3.amsl.com> Date: Tue, 10 Feb 2009 11:32:16 -0800 (PST)

Tue, 10 Feb 2009 10:32:14 +0300

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2009 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

From owner-namedroppers@ops.ietf.org Wed Feb 11 05:11: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 897B33A6971; Wed, 11 Feb 2009 05:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHurviJ7tC0x; Wed, 11 Feb 2009 05:11:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FFA03A68A5; Wed, 11 Feb 2009 05:11:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXEk5-000FM2-J9 for namedroppers-data0@psg.com; Wed, 11 Feb 2009 13:03:05 +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 1LXEk1-000FLl-MZ for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 13:03:03 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1BD2x91074052 for ; Wed, 11 Feb 2009 08:03:00 -0500 (EST) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n1BD2xeQ074051 for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 08:02:59 -0500 (EST) (envelope-from namedroppers) Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXE6Y-000DEY-G3 for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 12:22:15 +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=BDkiKETmxNE2PPfW9k9n7a05nCrbUNZMmSxQ/sRk2Kmq7IDt9tg4/psi +tWKrys4Edz0PEvxvTnz6mk0l5bn9h10TypdFmpMYtIn5BlhiCJ7/Qdjh YqsymPrjGvL4Mtc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Alexd@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1234354934; x=1265890934; 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:=20Alexd@nominet.org.uk|Subject:=20Unknown=20DNSKEY =20flags|Date:=20Wed,=2011=20Feb=202009=2012:22:13=20+000 0|Message-ID:=20|To:=20namedroppers@ops. ietf.org|MIME-Version:=201.0; bh=QXNxbQjamt7zdF57q4oK+mY2+tHW61jjTMSIXahM8Pg=; b=eaX6DCHvhXxG589IUl7O0wK5QrHB4yP767MOl5/sPS/fjf336b/P0IYm NCKiuFp0nL8pVwTyS1uDbkxZCowFKIKpL1bMYVK40XSSwdIBY2bURmOF2 mDPT2wwS3V0n5G1; X-IronPort-AV: E=Sophos;i="4.38,191,1233532800"; d="scan'208";a="8422095" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 11 Feb 2009 12:22:12 +0000 To: namedroppers@ops.ietf.org Subject: [dnsext] Unknown DNSKEY flags MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008 Message-ID: From: Alexd@nominet.org.uk Date: Wed, 11 Feb 2009 12:22:13 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/02/2009 12:22:12 PM, Serialize complete at 11/02/2009 12:22:12 PM Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Hi - I'm developing a DNSSEC validating resolver in Ruby (using my dnsruby library). I was slightly confused by some of the wording in RFC 4034, and was hoping for guidance. Basically, I'm not quite sure what to do if I receive a DNSKEY RR with unknown flag bits set. RFC 4034 (section 2.1.1) says : Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR and MUST be ignored upon receipt. So, do I ignore these bits, and still use the key to verify RRSIGs? The RFC seems to suggest that Postel's law is appropriate here. Or do I decide that the key is in some way dodgy, and, after accepting it, refuse to use it to verify RRSIGs? Thanks! Alex. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 05: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 F12483A6872; Wed, 11 Feb 2009 05:36:43 -0800 (PST) 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=[AWL=0.000, 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 MMAuFgU8aNH8; Wed, 11 Feb 2009 05:36:43 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2A753A686A; Wed, 11 Feb 2009 05:36:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXFC7-000GpG-E4 for namedroppers-data0@psg.com; Wed, 11 Feb 2009 13:32:03 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXFC4-000Gp1-QU for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 13:32:02 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 15A04272CA4; Wed, 11 Feb 2009 14:32:00 +0100 (CET) Received: from [192.168.254.3] (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 4F04C272C61; Wed, 11 Feb 2009 14:31:54 +0100 (CET) Message-ID: <4992D349.5070902@nlnetlabs.nl> Date: Wed, 11 Feb 2009 14:31:53 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Alexd@nominet.org.uk CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Unknown DNSKEY flags References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8979/Wed Feb 11 13:23:15 2009 on rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alex, Use the key without looking at the bits. Thus, you verify RRSIGs and do other stuff as usual. This is how I read 4034, implemented in unbound. Best regards, Wouter Alexd@nominet.org.uk wrote: > So, do I ignore these bits, and still use the key to verify RRSIGs? The > RFC seems to suggest that Postel's law is appropriate here. Yes > Or do I decide that the key is in some way dodgy, and, after accepting it, > refuse to use it to verify RRSIGs? No -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmS00kACgkQkDLqNwOhpPjFmwCgmFXh6+267TRSXr3b/27OLZgK +4gAn0ofbBwN2kcsgHYCtvSh18aRstZ4 =jPGp -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 05:38: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 A00B53A6A89; Wed, 11 Feb 2009 05:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MoeE6sz-Jov; Wed, 11 Feb 2009 05:38:38 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A3713A686A; Wed, 11 Feb 2009 05:38:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXFEp-000GzV-Nl for namedroppers-data0@psg.com; Wed, 11 Feb 2009 13:34:51 +0000 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXFEn-000GzF-HV for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 13:34:50 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 72ABB13142B for ; Wed, 11 Feb 2009 14:34:48 +0100 (CET) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id ACCB1CF984 for ; Wed, 11 Feb 2009 14:37:40 +0100 (CET) Message-ID: <4992D3F8.5030905@NLnetLabs.nl> Date: Wed, 11 Feb 2009 14:34:48 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt References: <200901142303.n0EN3cHD008118@drugs.dv.isc.org> In-Reply-To: <200901142303.n0EN3cHD008118@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Do people think it is useful to include these tables in the document? I don't want it to appear to define things about existing algorithms, but leaving those out and just including 256 and 512 makes the tables a bit superfluous imo Jelte Mark Andrews wrote: > > The table below documements when a zone is to be treated as > secure (S) or insecure (I) depending apon which algorithms > are supported by the validator. > > NSEC ONLY NSEC3 ONLY NSEC + NSEC3 > RSAMD5 S I S > DSA S I S > RSASHA1 S I S > NSEC3DSA I I S > NSEC3RSASHA1 I I S > RSASHA256 I I S > RSASHA512 I I S > > The table below documents which zones that can be served > by a authortative server that understand the following > algorithms. > > NSEC ONLY NSEC3 ONLY NSEC + NSEC3 > RSAMD5/NSEC Y N Y > DSA/NSEC Y N Y > RSASHA1/NSEC Y N Y > NSEC3DSA/NSEC Y N Y > NSEC3DSA/NSEC3 N Y Y > NSEC3RSASHA1/NSEC Y N Y > NSEC3RSASHA1/NSEC3 N Y Y > RSASHA256/NSEC Y N Y > RSASHA256/NSEC3 N Y Y > RSASHA512/NSEC Y N Y > RSASHA512/NSEC3 N Y Y > > Mark > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmS0/cACgkQ4nZCKsdOncV1oQCeKHfcN/Vtd+nFKKYWJDsyIMQ1 hpoAnRtTa24WDjzuaFUxhOTf5szvNNtB =N3X5 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 06:49: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 23B7B3A68FA; Wed, 11 Feb 2009 06:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UroEJX68ej4a; Wed, 11 Feb 2009 06:49:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2DABC3A680B; Wed, 11 Feb 2009 06:49:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXGGN-000Kor-IN for namedroppers-data0@psg.com; Wed, 11 Feb 2009 14:40:31 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXGGK-000Kob-22 for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 14:40:30 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Edld1b00a16LCl058egU6B; Wed, 11 Feb 2009 14:40:28 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA06.westchester.pa.mail.comcast.net with comcast id EegV1b00J4LCBKY3SegViM; Wed, 11 Feb 2009 14:40:30 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Feb 2009 09:40:27 -0500 To: "W.C.A. Wijngaards" From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit Cc: David Blacka ,namedroppers@ops.ietf.org, weiler@tislabs.com In-Reply-To: <49882935.5080705@nlnetlabs.nl> References:

<49704490.20906@nlnetlabs.nl> <8F6E3F48-C3A9-4497-96FC-785B1EF5F160@verisign.com> <200901170829.n0H8TmVf035052@omval.tednet.nl> <49882935.5080705@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 06:23 AM 2/3/2009, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Michael StJohns wrote: >>> Furthermore, if the validating recursive resolver has a trust >>> anchor covering a request, it >>> SHOULD set the CD bit on its upstream query regardless of the CD >>> bit setting of the request. >> >> MUST or SHOULD here? I think if you've configured a trust anchor you've accepted responsibility to resolve according to local policy so I'd put this as a MUST. >> >> I can't think of a reasonable reason why you would set a trust anchor and not set the CD bit in the upstream. [OK - I can think of an unreasonable reason - local resolver has .COM trust anchor, upstream resolver has FOO.COM trust anchor, but not .COM - upstream filters FOO.COM if data is bad but passes through the rest of .COM. I don't think this makes a lot of sense though - the local resolver doesn't necessarily have a clue what trust anchors are configured in the upstream resolver so it can't really make a decent decision on whether to set/not set the CD bit. The local resolver would have to know that the upstream resolver has a FOO.COM trust anchor and to not set the bit for those queries - seems complicated ] >> >> I can live with the text as above, and will bow to the consensus with respect to MUST or SHOULD. > >I can live with the text too. > >For SHOULD or MUST - I can imagine deployment where servers do not set >upstream CD bit because the operator wants simple caches to forward >queries towards a validating server (that has all the keys) - and thus >SHOULD. If you need explanatory text: 'If so configured, a recursive >resolver could opt to not set the CD bit to allow upstream validation'. > I do not think this explanatory text is needed (for dnssec-bis updates). I still don't really care about must v should here, but I don't think this argument holds water. If you want the upstream resolver to do all the validation, all you have to do is delete all the trust anchors at the intermediate resolver. So is there a *real* case where the intermediate resolver has a trust anchor for some.zone where you wouldn't set the CD bit for a query to example.what.who.some.zone? I think for the purposes of this discussion, you can't make any assumptions about trust anchors for any upstream resolver...you can't even make assumptions about who will answer the query a priori. Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 07:17: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 38AEF3A6A6D; Wed, 11 Feb 2009 07:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 P7Ecxt2YomwU; Wed, 11 Feb 2009 07:17:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 497D13A67B4; Wed, 11 Feb 2009 07:17:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXGkx-000N5L-K2 for namedroppers-data0@psg.com; Wed, 11 Feb 2009 15:12:07 +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 1LXGkv-000N52-Gs for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 15:12:06 +0000 Received: from [10.31.200.181] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1BFBqUq075288; Wed, 11 Feb 2009 10:11:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4992D349.5070902@nlnetlabs.nl> References: <4992D349.5070902@nlnetlabs.nl> Date: Wed, 11 Feb 2009 10:08:32 -0500 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: [dnsext] Unknown DNSKEY flags Cc: Alexd@nominet.org.uk, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:31 +0100 2/11/09, W.C.A. Wijngaards wrote: >Alexd@nominet.org.uk wrote: >> So, do I ignore these bits, and still use the key to verify RRSIGs? The >> RFC seems to suggest that Postel's law is appropriate here. > >Yes The logic is - if in the future the bits take on meaning and keys appear with a set of the bits set to 1 the software written now will not alter what it does. Furthermore, the new semantics assigned to the bits will (have to) be backwards compatible with old software. > >> Or do I decide that the key is in some way dodgy, and, after accepting it, >> refuse to use it to verify RRSIGs? > >No No, no. Software "trying too hard" to be helpful has proven to cause problems in the past. Overly tightened security can make a system brittle and crack, like over tightening nuts and bolts can cause problems (strip the bolt threads, bolt head, tear the fabric [wood/metal] it is binding, etc.). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 07:35: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 682CD3A6D02; Wed, 11 Feb 2009 07:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM1y7NNolDbD; Wed, 11 Feb 2009 07:35:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACC253A6CFE; Wed, 11 Feb 2009 07:35:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXH0A-000OSX-43 for namedroppers-data0@psg.com; Wed, 11 Feb 2009 15:27: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 1LXH05-000OSD-Gb for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 15:27:48 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 837B7327A71; Wed, 11 Feb 2009 15:27:44 +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 C6BE4327A5A; Wed, 11 Feb 2009 15:27:43 +0000 (UTC) Message-ID: <4992EE6F.3030307@isc.org> Date: Wed, 11 Feb 2009 09:27:43 -0600 From: Michael Graff User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Edward Lewis CC: "W.C.A. Wijngaards" , Alexd@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] Unknown DNSKEY flags References: <4992D349.5070902@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Lewis wrote: > At 14:31 +0100 2/11/09, W.C.A. Wijngaards wrote: > >> Alexd@nominet.org.uk wrote: >>> So, do I ignore these bits, and still use the key to verify RRSIGs? The >>> RFC seems to suggest that Postel's law is appropriate here. >> >> Yes > > The logic is - if in the future the bits take on meaning and keys appear > with a set of the bits set to 1 the software written now will not alter > what it does. Furthermore, the new semantics assigned to the bits will > (have to) be backwards compatible with old software. What if a bit is defined which means "this key is revoked." For instance, what happened in RFC 5011? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmS7m8ACgkQLdqv0r6eD6a/0QCeIggGlnf6ba+cV9fNIVyELRX9 plEAn0Ly4Gp+Cxmgx7wVB4IBZe44yIYo =A8dv -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 08:18:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C373A6816; Wed, 11 Feb 2009 08:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 pM4w6vF5GBSk; Wed, 11 Feb 2009 08:18:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C87BC3A691D; Wed, 11 Feb 2009 08:18:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXHhF-0001Q4-F0 for namedroppers-data0@psg.com; Wed, 11 Feb 2009 16:12:21 +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 1LXHhC-0001Pk-Nr for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 16:12:20 +0000 Received: from [10.31.200.181] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1BGBrPL075822; Wed, 11 Feb 2009 11:11:53 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4992EE6F.3030307@isc.org> References: <4992D349.5070902@nlnetlabs.nl> <4992EE6F.3030307@isc.org> Date: Wed, 11 Feb 2009 11:03:02 -0500 To: Michael Graff From: Edward Lewis Subject: Re: [dnsext] Unknown DNSKEY flags Cc: Edward Lewis , "W.C.A. Wijngaards" , Alexd@nominet.org.uk, namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-977753783==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-977753783==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:27 -0600 2/11/09, Michael Graff wrote: >What if a bit is defined which means "this key is revoked." When we did the background for DNSSEC, we considered such possibilities - that is - tightening security once something was fielded. We knew that it is not possible to tighten something, only loosen it when faced with an open source/open audience software distribution. This is one reason RFC 3008 was written - tightening the authority model - before there was a chance of widespread deployment. Now, seriously, we know in the year 2000 we were still way ahead of any dnssec deployment but at the time we thought it would come faster. When designing a protocol, a correct design will be slightly tighter than needed and loosened as required. The same principle of over tightening applies. But you also have to give clients incentive to upgrade older versions - an incentive is less security hassles, a disincentive is more restriction. (Admittedly, if we could get the fit right...but then that is why hardware stores sell "shims." [Yes, undergoing house renovations now and there are shims helping install doors in the house.]) >For instance, what happened in RFC 5011? Note from the abstract: This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. It's arguable that this addition goes against the principles above, but splitting hairs, it doesn't. (I.e., a long thread can go back and forth on this, but I don't really have the time.) Current resolver management is manual, this defines the first automated mechanism for this. So in a way this isn't a retrenchment. The incentive to upgrade is to remove the manual labor. This doesn't chance the validation process, a trust anchor is still a trust anchor. The same considerations are written into the first specification of the SEP bit (RFC 3757): The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. From the abstract. We knew then that the SEP bit couldn't help the old validators out there. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. --============_-977753783==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Unknown DNSKEY flags

At 9:27 -0600 2/11/09, Michael Graff wrote:

>What if a bit is defined which means "this key is revoked."

When we did the background for DNSSEC, we considered such possibilities - that is - tightening security once something was fielded. We knew that it is not possible to tighten something, only loosen it when faced with an open source/open audience software distribution.

This is one reason RFC 3008 was written - tightening the authority model - before there was a chance of widespread deployment. Now, seriously, we know in the year 2000 we were still way ahead of any dnssec deployment but at the time we thought it would come faster.

When designing a protocol, a correct design will be slightly tighter than needed and loosened as required. The same principle of over tightening applies. But you also have to give clients incentive to upgrade older versions - an incentive is less security hassles, a disincentive is more restriction.

(Admittedly, if we could get the fit right...but then that is why hardware stores sell "shims." [Yes, undergoing house renovations now and there are shims helping install doors in the house.])

>For instance, what happened in RFC 5011?

Note from the abstract:

This mechanism will require changes to resolver management behavior
(but not resolver resolution behavior), and the addition of a single

flag bit to the DNSKEY record.

It's arguable that this addition goes against the principles above, but splitting hairs, it doesn't. (I.e., a long thread can go back and forth on this, but I don't really have the time.)

Current resolver management is manual, this defines the first automated mechanism for this. So in a way this isn't a retrenchment. The incentive to upgrade is to remove the manual labor. This doesn't chance the validation process, a trust anchor is still a trust anchor.

The same considerations are written into the first specification of the SEP bit (RFC 3757):

   The flag bit is intended to assist in operational procedures to
   correctly generate DS resource records, or to indicate what DNSKEYs
   are intended for static configuration. The flag bit is not to be
   used in the DNS verification protocol.

From the abstract. We knew then that the SEP bit couldn't help the old validators out there.

--

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

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

Never confuse activity with progress. Activity pays more.

--============_-977753783==_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 Feb 11 08:48: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 27CC53A693C; Wed, 11 Feb 2009 08:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-0.589, 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 zpf7wruc6SUY; Wed, 11 Feb 2009 08:48:25 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D9A93A67E9; Wed, 11 Feb 2009 08:48:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXIBp-0003Dx-NO for namedroppers-data0@psg.com; Wed, 11 Feb 2009 16:43:57 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXIBf-0003Cp-GE for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 16:43:48 +0000 Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id BAFCE39A1FD; Wed, 11 Feb 2009 08:43:46 -0800 (PST) From: Wes Hardaker To: Edward Lewis Cc: "W.C.A. Wijngaards" , Alexd@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] Unknown DNSKEY flags Organization: Sparta References: <4992D349.5070902@nlnetlabs.nl> Date: Wed, 11 Feb 2009 08:43:46 -0800 In-Reply-To: (Edward Lewis's message of "Wed\, 11 Feb 2009 10\:08\:32 -0500") 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 Wed, 11 Feb 2009 10:08:32 -0500, Edward Lewis said: EL> The logic is - if in the future the bits take on meaning and keys EL> appear with a set of the bits set to 1 the software written now will EL> not alter what it does. Furthermore, the new semantics assigned to EL> the bits will (have to) be backwards compatible with old software. The other way commonly used to talk about extensions is "criticality". All the DNSSKEY bits are "non-critical" and don't need to be understood. Unlike other protocols/data-structures that have a way to flag extensions as "critical" which means "you must fail if you don't understand this". DNSKEYs don't have a mechanism to signal a critical-bit. They're all non-critical. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 09:26: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 B2D3C3A6B62; Wed, 11 Feb 2009 09:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 s4gADokXHwDV; Wed, 11 Feb 2009 09:26:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E38C73A68E6; Wed, 11 Feb 2009 09:26:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXIkF-0005mz-47 for namedroppers-data0@psg.com; Wed, 11 Feb 2009 17:19:31 +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 1LXIk3-0005ke-A4 for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 17:19:29 +0000 Received: from [IPv6:2001:7b8:206:1:21b:63ff:fe94:3816] ([IPv6:2001:7b8:206:1:21b:63ff:fe94:3816]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n1BHJ9Kb051920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Feb 2009 18:19:10 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Cc: Alexd@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: From: Olaf Kolkman To: "W.C.A. Wijngaards" In-Reply-To: <4992D349.5070902@nlnetlabs.nl> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-29-514994092" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Unknown DNSKEY flags Date: Wed, 11 Feb 2009 18:19:08 +0100 References: <4992D349.5070902@nlnetlabs.nl> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 11 Feb 2009 18:19:10 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-29-514994092 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit How about the KeyID? If you do not pay attention to the unknown flags do you allow them to be varied during their lifetime or do you assume to be 'fixed' (are not modified during their lifetime) I would assume that what-ever the flags are they will be 'fixed' during the lifetime of the key or, when changed, the keys cannot for validation by any implementation that is not aware of the meaning of the flag. correct assumption? [top-post] --Olaf On 11 feb 2009, at 14:31, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alex, > > Use the key without looking at the bits. Thus, you verify RRSIGs and > do > other stuff as usual. > > This is how I read 4034, implemented in unbound. > > Best regards, > Wouter > > Alexd@nominet.org.uk wrote: >> So, do I ignore these bits, and still use the key to verify RRSIGs? >> The >> RFC seems to suggest that Postel's law is appropriate here. > > Yes > >> Or do I decide that the key is in some way dodgy, and, after >> accepting it, >> refuse to use it to verify RRSIGs? > > No > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkmS00kACgkQkDLqNwOhpPjFmwCgmFXh6+267TRSXr3b/27OLZgK > +4gAn0ofbBwN2kcsgHYCtvSh18aRstZ4 > =jPGp > -----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: ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. --Apple-Mail-29-514994092 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. iEYEARECAAYFAkmTCIwACgkQtN/ca3YJIofvMQCgkthNdLxoxFSjOaFY65V3s6vz a7kAoPADGXtjXDdmXkqJ/DozR3M1IfM4 =+YYw -----END PGP SIGNATURE----- --Apple-Mail-29-514994092-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 11 09: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 5C8703A68FE; Wed, 11 Feb 2009 09:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 slcDV0+UTT-I; Wed, 11 Feb 2009 09:54:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4DD53A6D10; Wed, 11 Feb 2009 09:54:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXJB9-0007fY-5p for namedroppers-data0@psg.com; Wed, 11 Feb 2009 17:47: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 1LXJB2-0007ep-LY for namedroppers@ops.ietf.org; Wed, 11 Feb 2009 17:47:17 +0000 Received: from [10.31.200.181] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1BHl1t0076540; Wed, 11 Feb 2009 12:47:01 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4992D349.5070902@nlnetlabs.nl> Date: Wed, 11 Feb 2009 12:46:59 -0500 To: Olaf Kolkman From: Edward Lewis Subject: Re: [dnsext] Unknown DNSKEY flags Cc: "W.C.A. Wijngaards" , Alexd@nominet.org.uk, namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-977748076==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-977748076==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" In algorithm 1, the key's identifier (KeyID or keytag) isn't derived from the flags. I don't know the history of why the newer algorithms have different derivations of this. From section 4.1.6. of RFC 2535 (since obsoleted): "For algorithm 1 (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order. For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR as described in Appendix C." I faintly recollect there was a discussion whether the keytag was to be the RDATA or just the key guts. But I wasn't working on the icky crypto. ;) But yeah, that's an issue... At 18:19 +0100 2/11/09, Olaf Kolkman wrote: >How about the KeyID? > >If you do not pay attention to the unknown flags do you allow them >to be varied during their lifetime or do you assume to be 'fixed' >(are not modified during their lifetime) > >I would assume that what-ever the flags are they will be 'fixed' >during the lifetime of the key or, when changed, the keys cannot for >validation by any implementation that is not aware of the meaning of >the flag. > >correct assumption? > >[top-post] > >--Olaf > >On 11 feb 2009, at 14:31, W.C.A. Wijngaards wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Alex, >> >> Use the key without looking at the bits. Thus, you verify RRSIGs and do >> other stuff as usual. >> >> This is how I read 4034, implemented in unbound. >> >> Best regards, >> Wouter >> >> Alexd@nominet.org.uk wrote: >>> So, do I ignore these bits, and still use the key to verify RRSIGs? The >>> RFC seems to suggest that Postel's law is appropriate here. >> >> Yes >> >>> Or do I decide that the key is in some way dodgy, and, after accepting it, >>> refuse to use it to verify RRSIGs? >> >> No >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkmS00kACgkQkDLqNwOhpPjFmwCgmFXh6+267TRSXr3b/27OLZgK >> +4gAn0ofbBwN2kcsgHYCtvSh18aRstZ4 >> =jPGp >> -----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: > >----------------------------------------------------------- >Olaf M. Kolkman NLnet Labs > Science Park 140, >http://www.nlnetlabs.nl/ 1098 XG Amsterdam > >NB: The street at which our offices are located has been >renamed to the above. > > > > > > >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 > >Attachment converted: Macintosh HD:PGP 676.sig (pgDS/ ) (00309E10) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. --============_-977748076==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Unknown DNSKEY flags

In algorithm 1, the key's identifier (KeyID or keytag) isn't derived from the flags. I don't know the history of why the newer algorithms have different derivations of this.

From section 4.1.6. of RFC 2535 (since obsoleted):

   "For algorithm 1
   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
   octets of the public key modulus needed to decode the signature
   field. That is to say, the most significant 16 of the least
   significant 24 bits of the modulus in network (big endian) order. For
   all other algorithms, including private algorithms, it is calculated
   as a simple checksum of the KEY RR as described in Appendix C."

I faintly recollect there was a discussion whether the keytag was to be the RDATA or just the key guts. But I wasn't working on the icky crypto. ;)

But yeah, that's an issue...

At 18:19 +0100 2/11/09, Olaf Kolkman wrote:

>How about the KeyID?
>
>If you do not pay attention to the unknown flags do you allow them to be varied during their lifetime or do you assume to be 'fixed' (are not modified during their lifetime)
>
>I would assume that what-ever the flags are they will be 'fixed' during the lifetime of the key or, when changed, the keys cannot for validation by any implementation that is not aware of the meaning of the flag.
>
>correct assumption?
>
>[top-post]
>
>--Olaf
>
>On 11 feb 2009, at 14:31, W.C.A. Wijngaards wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Alex,
>>
>> Use the key without looking at the bits. Thus, you verify RRSIGs and do
>> other stuff as usual.
>>
>> This is how I read 4034, implemented in unbound.
>>
>> Best regards,
>>   Wouter
>>
>> Alexd@nominet.org.uk wrote:
>>> So, do I ignore these bits, and still use the key to verify RRSIGs? The
>>> RFC seems to suggest that Postel's law is appropriate here.
>>
>> Yes
>>
>>> Or do I decide that the key is in some way dodgy, and, after accepting it,
>>> refuse to use it to verify RRSIGs?
>>
>> No
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkmS00kACgkQkDLqNwOhpPjFmwCgmFXh6+267TRSXr3b/27OLZgK
>> +4gAn0ofbBwN2kcsgHYCtvSh18aRstZ4
>> =jPGp
>> -----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: <http://ops.ietf.org/lists/namedroppers/>
>
>-----------------------------------------------------------
>Olaf M. Kolkman                        NLnet Labs
>                                       Science Park 140,
>http://www.nlnetlabs.nl/               1098 XG Amsterdam
>
>NB: The street at which our offices are located has been
>renamed to the above.
>
>
>
>
>
>
>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
>
>Attachment converted: Macintosh HD:PGP 676.sig (pgDS/    ) (00309E10)

--

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

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

Never confuse activity with progress. Activity pays more.

--============_-977748076==_ma============-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 09:06: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 EAC9D3A6AC1; Thu, 12 Feb 2009 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8oDnh2oHlQl; Thu, 12 Feb 2009 09:06:21 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1429F3A6813; Thu, 12 Feb 2009 09:06:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXer0-0007BC-GD for namedroppers-data0@psg.com; Thu, 12 Feb 2009 16:55:58 +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 1LXeqy-0007AR-1y for namedroppers@ops.ietf.org; Thu, 12 Feb 2009 16:55:57 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1CGtoSO087226; Thu, 12 Feb 2009 11:55:51 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200901080115.n081F9ko096614@drugs.dv.isc.org> <496605EA.2000602@nlnetlabs.nl> Date: Thu, 12 Feb 2009 11:55:48 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] AXFR Clarify -- open issue w/ 'zone loading' Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: For -11, is this wording okay or is the whole thing just too much garbage. (This would be the second paragraph of section 6 as seen in -10.) If a server rejects data contained in an AXFR session, the server SHOULD remember the serial number and MAY attempt to retrieve the same zone version again. The reason the same retrieval could make sense is that the reason for the rejection could be rooted in an implementation detail of one AXFR server used for the zone and not in another AXFR server used for the zone. At 10:12 -0500 1/8/09, Edward Lewis wrote: ... >Is this a better version? > >| "If an AXFR client rejects the zone data contained in an otherwise >| successfully completed AXFR session, it SHOULD attempt to retrieve >| the same zone version again." > >"SHOULD" - "MAY" - ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 13:22: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 E804028C258; Thu, 12 Feb 2009 13:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 GnOVWCGkiazS; Thu, 12 Feb 2009 13:22:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C850E28C20E; Thu, 12 Feb 2009 13:22:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXiqN-000Jez-7H for namedroppers-data0@psg.com; Thu, 12 Feb 2009 21:11:35 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXiqK-000Jem-OM for namedroppers@ops.ietf.org; Thu, 12 Feb 2009 21:11:33 +0000 Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1CLBRot089499; Thu, 12 Feb 2009 16:11:27 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200812310040.mBV0ehYM005985@drugs.dv.isc.org> References: <200812310040.mBV0ehYM005985@drugs.dv.isc.org> Date: Thu, 12 Feb 2009 16:11:24 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] single-ton AXFRs, was Re: -10 Cc: Edward Lewis Content-Type: multipart/alternative; boundary="============_-977649409==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-977649409==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" In going through some noted from Alfred... >> What is done about old servers that put one RR per message into AXFR >> responses? How does this play with the words about complete RR sets? At 11:40 +1100 12/31/08, Mark Andrews wrote: > > The answer is the set of messages which make up the AXFR > response. As long as the set of messages contains the > complete RRset there is no problem. The question is how do we patch up this inconsistency?: [RFC 2181] 9. The TC (truncated) header bit The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. If the recipient of the reply needs the omitted data, it can construct a query for that data and send that separately. Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. This says an incomplete RRSet triggers a TC bit. Should AXFR clarify say that DNS clarify's words on TC setting to not apply to AXFR? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. --============_-977649409==_ma============ Content-Type: text/html; charset="us-ascii" single-ton AXFRs, was Re: -10

In going through some noted from Alfred...

>> What is done about old servers that put one RR per message into AXFR
>> responses? How does this play with the words about complete RR sets?

At 11:40 +1100 12/31/08, Mark Andrews wrote:

>
> The answer is the set of messages which make up the AXFR
> response. As long as the set of messages contains the

> complete RRset there is no problem.

The question is how do we patch up this inconsistency?:

[RFC 2181]

9. The TC (truncated) header bit

   The TC bit should be set in responses only when an RRSet is required
   as a part of the response, but could not be included in its entirety.
   The TC bit should not be set merely because some extra information
   could have been included, but there was insufficient room. This
   includes the results of additional section processing. In such cases
   the entire RRSet that will not fit in the response should be omitted,
   and the reply sent as is, with the TC bit clear. If the recipient of
   the reply needs the omitted data, it can construct a query for that
   data and send that separately.

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response. When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

This says an incomplete RRSet triggers a TC bit. Should AXFR clarify say that DNS clarify's words on TC setting to not apply to AXFR?

--

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

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

Never confuse activity with progress. Activity pays more.

--============_-977649409==_ma============-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 15:27: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 BD90C28C0ED; Thu, 12 Feb 2009 15:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.75 X-Spam-Level: ** X-Spam-Status: No, score=2.75 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgYcvzI2IbJW; Thu, 12 Feb 2009 15:27:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E69B63A6C16; Thu, 12 Feb 2009 15:27:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXksV-000Q0P-Uh for namedroppers-data0@psg.com; Thu, 12 Feb 2009 23:21:55 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXksS-000Pzv-Fy for namedroppers@ops.ietf.org; Thu, 12 Feb 2009 23:21:53 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA118430803; Fri, 13 Feb 2009 00:20:03 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA13247 for namedroppers@ops.ietf.org; Fri, 13 Feb 2009 00:20:03 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200902122320.AAA13247@TR-Sys.de> Subject: Re: [dnsext] AXFR Clarify -- open issue w/ 'zone loading' To: namedroppers@ops.ietf.org Date: Fri, 13 Feb 2009 00:20:02 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 12 Feb 2009 11:55:48 -0500, Edward Lewis wrote: > For -11, is this wording okay or is the whole thing just too much garbage. > > (This would be the second paragraph of section 6 as seen in -10.) > >| If a server rejects data contained in an AXFR session, the server >| SHOULD remember the serial number and MAY attempt to retrieve the >| same zone version again. The reason the same retrieval could make >| sense is that the reason for the rejection could be rooted in an >| implementation detail of one AXFR server used for the zone and not >| in another AXFR server used for the zone. I agree with the new text (a bit more emphasized above). It leaves most aspects of AXFR invocation strategies to the meta / management (level decided to be out-of-scope of the draft), and it grants flexibility without affecting the on-the-wire AXFR protocol. Alfred. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 16:11: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 70EF728C11A; Thu, 12 Feb 2009 16:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.8 X-Spam-Level: *** X-Spam-Status: No, score=3.8 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_51=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 FGtUxmVDDWvF; Thu, 12 Feb 2009 16:11:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 592D63A6B20; Thu, 12 Feb 2009 16:11:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXlYn-0002J7-Ey for namedroppers-data0@psg.com; Fri, 13 Feb 2009 00:05:37 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXlYc-0002IO-Cj for namedroppers@ops.ietf.org; Fri, 13 Feb 2009 00:05:33 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA118553416; Fri, 13 Feb 2009 01:03:36 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA13279; Fri, 13 Feb 2009 01:03:35 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200902130003.BAA13279@TR-Sys.de> Subject: [dnsext] single-ton AXFRs, was Re: -10 To: Ed.Lewis@neustar.biz, namedroppers@ops.ietf.org Date: Fri, 13 Feb 2009 01:03:35 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 12 Feb 2009 16:11:24 -0500 , Edward Lewis wrote: > In going through some noted from Alfred... > >>> What is done about old servers that put one RR per message into AXFR >>> responses? How does this play with the words about complete RR sets? > > At 11:40 +1100 12/31/08, Mark Andrews wrote: > >> The answer is the set of messages which make up the AXFR >> response. As long as the set of messages contains the >> complete RRset there is no problem. > > The question is how do we patch up this inconsistency?: > > ... [quote from RFC 2181, section 9 stripped off] > > This says an incomplete RRSet triggers a TC bit. > Should AXFR clarify say that DNS clarify's words on TC setting > to not apply to AXFR? The TC rules of RFC 2181, section 9, seem to be not 100% applicable, since AXFR already operates on a TCP connection; as such, a signal to switch to TCP does not make sense. The basic question I cannot answer is: After all the software updates performed in the recent past, how many servers are still deployed that exhibit that bad behavior? I strongly suspect that it can be expected that the authoritative servers for a zone are (at least) to some degree under cooperative management, and for many many zones today AXFR is administratively restricted to this group, or a slightly larger group of AXFR clients. However the strong guideline from RFC 1034 to always send entire RRsets in the Answer Section pertain, and the use of 'single-ton' or otherwise overly short AXFR response messages is a rather bad and inefficient behavior that should not be encouraged. Therefore, I suggest -- and IIRC the WG consensus on that point already had been achieved --, that new AXFR server implementations SHOULD conform to this general requirement and MUST NOT set the TC bit in any case. For "turnkey DNS implementations" (cf. section 1.2 of the AXFR draft) supporting AXFR, this even could be stated as a MUST. For "general purpose DNS implementations" we might conclude that the population of deployed AXFR clients still warrants a MAY for the 'single-ton' behavior, based on configuration and/or adaptive behavior (if the AXFR server indeed wants to maintain client state), but we should emphasize that this MUST NOT be the default behavior. In support of Postel's Principle, I suggest that it would be wise to request that _all_ AXFR clients MUST ignore the TC bit and SHOULD accept the zone data split into any (otherwise legal) sets of entire resource records per AXFR response message, as only the concatenation of all the RRs in these Answer sections counts -- after removal of the duplicate SOA RR from the last resonse message it must represent the zone content, and that is independent of its partitioning for transfer. The quote from Mark above should perhaps be read as: >> ... As long as the set of messages contains the >> complete RRset^W _collection of RRsets_ there is no problem. Kind regards, Alfred. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 16:20: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 964FB3A680C; Thu, 12 Feb 2009 16:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJvARo9JFQRa; Thu, 12 Feb 2009 16:20:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23E7A3A6803; Thu, 12 Feb 2009 16:20:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXlhL-0003Fc-Sh for namedroppers-data0@psg.com; Fri, 13 Feb 2009 00:14:27 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXlhB-0003F3-KF for namedroppers@ops.ietf.org; Fri, 13 Feb 2009 00:14:23 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id E246F11401C; Fri, 13 Feb 2009 00:14:06 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 1F94EE6072; Fri, 13 Feb 2009 00:14: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 n1D0E2Yn005135; Fri, 13 Feb 2009 11:14:03 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200902130014.n1D0E2Yn005135@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] single-ton AXFRs, was Re: -10 In-reply-to: Your message of "Thu, 12 Feb 2009 16:11:24 CDT." Date: Fri, 13 Feb 2009 11:14:02 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The DNS is missing the ability to return a QUERY response with arbitrary number of records. AXFR is a reponse to that. Note we don't define what you do when you have to set TC in a TCP response. In message , Edward Lewis writes: > --============_-977649409==_ma============ > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > In going through some noted from Alfred... > > >> What is done about old servers that put one RR per message into AXFR > >> responses? How does this play with the words about complete RR sets? > > At 11:40 +1100 12/31/08, Mark Andrews wrote: > > > > > The answer is the set of messages which make up the AXFR > > response. As long as the set of messages contains the > > complete RRset there is no problem. > > The question is how do we patch up this inconsistency?: > > [RFC 2181] > 9. The TC (truncated) header bit > > The TC bit should be set in responses only when an RRSet is required > as a part of the response, but could not be included in its entirety. > The TC bit should not be set merely because some extra information > could have been included, but there was insufficient room. This > includes the results of additional section processing. In such cases > the entire RRSet that will not fit in the response should be omitted, > and the reply sent as is, with the TC bit clear. If the recipient of > the reply needs the omitted data, it can construct a query for that > data and send that separately. > > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. > > This says an incomplete RRSet triggers a TC bit. Should AXFR clarify > say that DNS clarify's words on TC setting to not apply to AXFR? > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Never confuse activity with progress. Activity pays more. > --============_-977649409==_ma============ > Content-Type: text/html; charset="us-ascii" > > > single-ton AXFRs, was Re: -10 >

In going through some noted from Alfred...

>> What is done about old servers that put one RR per > message into AXFR
> >> responses? How does this play with the words about > complete RR sets?
>

At 11:40 +1100 12/31/08, Mark Andrews wrote:

>
> > The answer is the > set of messages which make up the AXFR
> > response. > As long as the set of messages contains the

> complete > RRset there is no problem.

The question is how do we patch up this inconsistency?:

[RFC 2181]

9. The TC (truncated) header bit
>
>    The TC bit should be set in responses only when an RRSet > is required
>    as a part of the response, but could not be included in > its entirety.
>    The TC bit should not be set merely because some extra > information
>    could have been included, but there was insufficient > room. This
>    includes the results of additional section processing. > In such cases
>    the entire RRSet that will not fit in the response should > be omitted,
>    and the reply sent as is, with the TC bit clear. If > the recipient of
>    the reply needs the omitted data, it can construct a > query for that
>    data and send that separately.
>
>    Where TC is set, the partial RRSet that would not > completely fit may
>    be left in the response. When a DNS client receives > a reply with TC
>    set, it should ignore that response, and query again, > using a
>    mechanism, such as a TCP connection, that will permit > larger replies.
>

This says an incomplete RRSet triggers a TC bit. Should > AXFR clarify say that DNS clarify's words on TC setting to not apply > to AXFR?

-- 
>

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >-=-=-=-

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

Never confuse activity with progress. Activity pays > more.

> > > --============_-977649409==_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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 16:30:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC24B3A68F9; Thu, 12 Feb 2009 16:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 3pkDVL9qDdrI; Thu, 12 Feb 2009 16:30:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A4723A680C; Thu, 12 Feb 2009 16:30:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXlsR-0003q6-6h for namedroppers-data0@psg.com; Fri, 13 Feb 2009 00:25:55 +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 1LXlsO-0003pt-9F for namedroppers@ops.ietf.org; Fri, 13 Feb 2009 00:25:53 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1D0PXpE091296; Thu, 12 Feb 2009 19:25:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200902130014.n1D0E2Yn005135@drugs.dv.isc.org> References: <200902130014.n1D0E2Yn005135@drugs.dv.isc.org> Date: Thu, 12 Feb 2009 19:25:26 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: [dnsext] single-ton AXFRs, was Re: -10 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:14 +1100 2/13/09, Mark Andrews wrote: > The DNS is missing the ability to return a QUERY response > with arbitrary number of records. AXFR is a reponse to > that. Note we don't define what you do when you have to > set TC in a TCP response. I get the meaning of the last sentence but not the first two. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 12 17:15: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 6D7373A6886; Thu, 12 Feb 2009 17:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3D1UZk8B3Dy; Thu, 12 Feb 2009 17:15:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57C9A3A684A; Thu, 12 Feb 2009 17:15:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXmZw-0005tZ-LZ for namedroppers-data0@psg.com; Fri, 13 Feb 2009 01:10:52 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXmZu-0005tK-7A for namedroppers@ops.ietf.org; Fri, 13 Feb 2009 01:10:51 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id CCC7A11402C; Fri, 13 Feb 2009 01:10:41 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 4BA46E6064; Fri, 13 Feb 2009 01:10:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n1D1Abqn006493; Fri, 13 Feb 2009 12:10:38 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200902130110.n1D1Abqn006493@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] single-ton AXFRs, was Re: -10 In-reply-to: Your message of "Thu, 12 Feb 2009 19:25:26 CDT." Date: Fri, 13 Feb 2009 12:10:37 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Edward Lewis writes: > At 11:14 +1100 2/13/09, Mark Andrews wrote: > > The DNS is missing the ability to return a QUERY response > > with arbitrary number of records. AXFR is a reponse to > > that. Note we don't define what you do when you have to > > set TC in a TCP response. > > I get the meaning of the last sentence but not the first two. If foo.example has 4096 A records the DNS, as currently specified, provides no mechanism to return that RRset to the caller other than issuing a AXFR query and extracting the records. I believe this is a gap in the protocol specification. I have seen PTR query responses set TC because the entire RRset could not fit into a 64K messsage. If the DNS had a mechanism to return those 4096 A records, then there would not have been a need to specify a special transport method for AXFR as it would have just been treated like any other big query response. Note: Now that DNSSEC is being deployed the response to ANY queries at zone apex are starting to exceed the capabilities of the DNS protocol. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Never confuse activity with progress. Activity pays more. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From johnnyx@akcb.com Fri Feb 13 23:13: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 11C8C3A6A72 for ; Fri, 13 Feb 2009 23:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.848 X-Spam-Level: **** X-Spam-Status: No, score=4.848 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, HOST_EQ_BR=1.295, 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_UNI=0.591, TVD_RCVD_IP=1.931, 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 mUGbBcQA+3qd for ; Fri, 13 Feb 2009 23:13:21 -0800 (PST) Received: from 189-31-31-83.bsaco700.dsl.brasiltelecom.net.br (189-31-31-83.bsaco700.dsl.brasiltelecom.net.br [189.31.31.83]) by core3.amsl.com (Postfix) with SMTP id 696963A65A5 for ; Fri, 13 Feb 2009 23:13:14 -0800 (PST) To: Subject: Mail 30452 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090214071316.696963A65A5@core3.amsl.com> Date: Fri, 13 Feb 2009 23:13:14 -0800 (PST)

If you dont see text or image please see this email as a webpage.

February 2009

WorldWide Digital Shipping
Only best for you

Thank you for use to WorldWide DS' programm.

You gave WorldWide DS permission to send you this email. Please add vus to your address book or safe sender list.
Conservation International 7306 Crystal Drive, Suite 879, Arlington, VA 53183, USA
Review our Privacy Policy and Acceptable Use Policy.
Unsubscribe or manage your Subscription Preferences

Crafted and delivered by WorldWide DS' MailDog!

From mail@aas-sz.com Sat Feb 14 23:56: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 E1B4A3A6A44 for ; Sat, 14 Feb 2009 23:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.63 X-Spam-Level: * X-Spam-Status: No, score=1.63 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_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 dK3vTIK6JLr5 for ; Sat, 14 Feb 2009 23:55:58 -0800 (PST) Received: from 185.233-225-89.dsl.completel.net (185.233-225-89.dsl.completel.net [89.225.233.185]) by core3.amsl.com (Postfix) with SMTP id C5F153A69E0 for ; Sat, 14 Feb 2009 23:55:55 -0800 (PST) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090215075556.C5F153A69E0@core3.amsl.com> Date: Sat, 14 Feb 2009 23:55:55 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.pleasurevintage.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://pleasurevintage.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B567. 190 Clements Road. London. SE67 0DG

From judy@accord.com.tw Sun Feb 15 10:35: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 93C213A67B5 for ; Sun, 15 Feb 2009 10:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.443 X-Spam-Level: X-Spam-Status: No, score=-24.443 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, 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 PFYQaYdTl3Nx for ; Sun, 15 Feb 2009 10:34:59 -0800 (PST) Received: from adsl-dyn118.78-99-114.t-com.sk (adsl-dyn118.78-99-114.t-com.sk [78.99.114.118]) by core3.amsl.com (Postfix) with SMTP id D8BFC3A6824 for ; Sun, 15 Feb 2009 10:34:41 -0800 (PST) To: Subject: Re: answer 9 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090215183443.D8BFC3A6824@core3.amsl.com> Date: Sun, 15 Feb 2009 10:34:41 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.contributingdear.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://contributingdear.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B502. 195 Clements Road. London. SE41 6DG

From martino@alghisello.it Mon Feb 16 10:30: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 C34C63A684B for ; Mon, 16 Feb 2009 10:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.512 X-Spam-Level: X-Spam-Status: No, score=-31.512 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_32=1.778, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 B6gVec-MDzMD for ; Mon, 16 Feb 2009 10:30:34 -0800 (PST) Received: from host81-154-189-122.range81-154.btcentralplus.com (host81-154-189-122.range81-154.btcentralplus.com [81.154.189.122]) by core3.amsl.com (Postfix) with SMTP id 1F5953A68EF for ; Mon, 16 Feb 2009 10:30:31 -0800 (PST) To: Subject: Re: answer 0 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090216183033.1F5953A68EF@core3.amsl.com> Date: Mon, 16 Feb 2009 10:30:31 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.cloudharmonys.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://cloudharmonys.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B778. 370 Clements Road. London. SE21 7DG

From mcressx@adt.com Mon Feb 16 17:03: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 6E1A63A68B5 for ; Mon, 16 Feb 2009 17:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.167 X-Spam-Level: X-Spam-Status: No, score=-24.167 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 I0qXXm1hsD0Z for ; Mon, 16 Feb 2009 17:03:30 -0800 (PST) Received: from 3hoek.com (unknown [200.186.223.130]) by core3.amsl.com (Postfix) with SMTP id 83E1A3A6838 for ; Mon, 16 Feb 2009 17:03:27 -0800 (PST) To: Subject: Sales Receipt from Amazon From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090217010328.83E1A3A6838@core3.amsl.com> Date: Mon, 16 Feb 2009 17:03:27 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.sincerewood.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://sincerewood.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B865. 849 Clements Road. London. SE26 3DG

From mancheste@advantagelogisticsusa.com Tue Feb 17 09:28: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 0F2DA3A6D1A for ; Tue, 17 Feb 2009 09:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.488 X-Spam-Level: X-Spam-Status: No, score=-21.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ntvj0DY5LXt0 for ; Tue, 17 Feb 2009 09:28:13 -0800 (PST) Received: from a-i-c.co.jp (unknown [196.205.130.140]) by core3.amsl.com (Postfix) with SMTP id EAAA328C16F for ; Tue, 17 Feb 2009 09:28:09 -0800 (PST) To: Subject: Message number 98038 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090217172811.EAAA328C16F@core3.amsl.com> Date: Tue, 17 Feb 2009 09:28:09 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.breadbelieving.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://breadbelieving.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B743. 670 Clements Road. London. SE88 2DG

From nasirfagiri@algosaibi-gtb.com Tue Feb 17 11:39: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 82C5528C0F3 for ; Tue, 17 Feb 2009 11:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.519 X-Spam-Level: X-Spam-Status: No, score=-16.519 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_32=1.778, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 mT2r+w0PXHY8 for ; Tue, 17 Feb 2009 11:39:09 -0800 (PST) Received: from c-76-123-147-35.hsd1.ms.comcast.net (c-76-123-147-35.hsd1.ms.comcast.net [76.123.147.35]) by core3.amsl.com (Postfix) with SMTP id 2DDC63A6D0F for ; Tue, 17 Feb 2009 11:39:06 -0800 (PST) To: Subject: Hi From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090217193908.2DDC63A6D0F@core3.amsl.com> Date: Tue, 17 Feb 2009 11:39:06 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.deliciousthrilling.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://deliciousthrilling.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B297. 843 Clements Road. London. SE10 1DG

From owner-namedroppers@ops.ietf.org Tue Feb 17 12:24: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 F34883A68DE; Tue, 17 Feb 2009 12:24:00 -0800 (PST) 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=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=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 lu1GlDnz2qm7; Tue, 17 Feb 2009 12:24:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 083703A67E6; Tue, 17 Feb 2009 12:23:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZWMH-000CcS-R7 for namedroppers-data0@psg.com; Tue, 17 Feb 2009 20:15: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 1LZWME-000Cc7-O8 for namedroppers@ops.ietf.org; Tue, 17 Feb 2009 20:15:56 +0000 Received: from [10.31.200.176] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1HKFY6j044629; Tue, 17 Feb 2009 15:15:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200902130110.n1D1Abqn006493@drugs.dv.isc.org> References: <200902130110.n1D1Abqn006493@drugs.dv.isc.org> Date: Tue, 17 Feb 2009 15:15:30 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: [dnsext] single-ton AXFRs, was Re: -10 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Digesting this now - I forget what this has to do with AXFR. Maybe that the TC bit is never set or needed in AXFR. At 12:10 +1100 2/13/09, Mark Andrews wrote: >In message , Edward Lewis writes: >> At 11:14 +1100 2/13/09, Mark Andrews wrote: >> > The DNS is missing the ability to return a QUERY response >> > with arbitrary number of records. AXFR is a reponse to >> > that. Note we don't define what you do when you have to >> > set TC in a TCP response. >> >> I get the meaning of the last sentence but not the first two. > > If foo.example has 4096 A records the DNS, as currently > specified, provides no mechanism to return that RRset to > the caller other than issuing a AXFR query and extracting > the records. I believe this is a gap in the protocol > specification. > > I have seen PTR query responses set TC because the entire > RRset could not fit into a 64K messsage. > > If the DNS had a mechanism to return those 4096 A records, > then there would not have been a need to specify a special > transport method for AXFR as it would have just been treated > like any other big query response. > > Note: Now that DNSSEC is being deployed the response to ANY > queries at zone apex are starting to exceed the capabilities > of the DNS protocol. > > Mark >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis >> NeuStar You can leave a voice message at +1-571-434-5468 >> >> Never confuse activity with progress. Activity pays more. >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jaravenad@alusa.cl Tue Feb 17 13:18:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABEE3A67E6 for ; Tue, 17 Feb 2009 13:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.114 X-Spam-Level: X-Spam-Status: No, score=-25.114 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, 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_PBL=0.905, RCVD_IN_XBL=3.033, 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 zXkR8a3bK5EQ for ; Tue, 17 Feb 2009 13:18:18 -0800 (PST) Received: from 3E33B49F.dslaccess.aol.com (3E33B49F.dslaccess.aol.com [62.51.180.159]) by core3.amsl.com (Postfix) with SMTP id 168AC3A67A4 for ; Tue, 17 Feb 2009 13:18:15 -0800 (PST) To: Subject: Invoice from itunes.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090217211817.168AC3A67A4@core3.amsl.com> Date: Tue, 17 Feb 2009 13:18:15 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.proudsecond.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://proudsecond.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 8, B018. 722 Clements Road. London. SE18 9DG

From owner-namedroppers@ops.ietf.org Wed Feb 18 11:33: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 6704C3A69EE; Wed, 18 Feb 2009 11:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNmRnDHlUVkM; Wed, 18 Feb 2009 11:33:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94C793A6917; Wed, 18 Feb 2009 11:33:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZs2N-000GiB-Af for namedroppers-data0@psg.com; Wed, 18 Feb 2009 19:24: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 1LZs2J-000GhV-AD for namedroppers@ops.ietf.org; Wed, 18 Feb 2009 19:24:48 +0000 Received: from [10.31.200.176] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1IJOeA0054822; Wed, 18 Feb 2009 14:24:41 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 18 Feb 2009 14:24:38 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] type=ANY Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-977137415==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-977137415==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Someone new to DNS asked me to explain the semantics of QTYPE=ANY in a caching/recursive server. Stop me if you've heard this one before... One thing I noticed is that the documentation covering QTYPE=* and QCLASS=* is asymmetric. And, more to the point, the documents on QTYPE=* seem to be unclear. When I try to explain the semantics of some DNS parameter, I start with the IANA registry page (http://www.iana.org/assignments/dns-parameters). That page lists this: (Cutting some things like the hexadecimal out for clarity) # Registry Name: DNS CLASSes # Registry: # Decimal # Hexadecimal Name Reference # ------------- ------------------------------ --------- # 255 QCLASS * (ANY) [RFC1035] # Registry Name: Resource Record (RR) TYPEs # Reference: [RFC5395][RFC1035] # Registry: # TYPE Value and meaning Reference # ----------- --------------------------------------------- --------- # * 255 A request for all records [RFC1035] Note that the (Q)TYPE "*" is defined as "all records" here, but in class "any" is used. From RFC 1035: # 3.2.3. QTYPE values # * 255 A request for all records # 3.2.5. QCLASS values # * 255 any class My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a request for all records, but whatever records a server has on hand. Trying this out with popular implementations, that is what it appears to be. If a server is authoritative, then any is all. If a server is a cache, if it has anything cached for a name then the response has whatever it has, if there is nothing cached for the name, a recursive query is issued and that is used (essentially) for the response. The first question - is there an update to these definitions that documents the behavior we experience today? (I know we've talked this over on the list.) Second question, should (specifically) the IANA registry "Value and Meaning" be altered to be more meaningful? Why this matters - customer and customer support desks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. --============_-977137415==_ma============ Content-Type: text/html; charset="us-ascii" type=ANY

Someone new to DNS asked me to explain the semantics of QTYPE=ANY in a caching/recursive server.

Stop me if you've heard this one before...

One thing I noticed is that the documentation covering QTYPE=* and QCLASS=* is asymmetric. And, more to the point, the documents on QTYPE=* seem to be unclear.

When I try to explain the semantics of some DNS parameter, I start with the IANA registry page (http://www.iana.org/assignments/dns-parameters). That page lists this:

(Cutting some things like the hexadecimal out for clarity)

# Registry Name: DNS CLASSes
# Registry:

# Decimal

# Hexadecimal Name Reference

# ------------- ------------------------------ ---------

# 255 QCLASS * (ANY) [RFC1035]

# Registry Name: Resource Record (RR) TYPEs

# Reference: [RFC5395][RFC1035]

# Registry:
# TYPE Value and meaning Reference

# ----------- --------------------------------------------- ---------

# * 255 A request for all records [RFC1035]

Note that the (Q)TYPE "*" is defined as "all records" here, but in class "any" is used.

From RFC 1035:

# 3.2.3. QTYPE values

# * 255 A request for all records

# 3.2.5. QCLASS values
# * 255 any class

My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a request for all records, but whatever records a server has on hand. Trying this out with popular implementations, that is what it appears to be.

If a server is authoritative, then any is all. If a server is a cache, if it has anything cached for a name then the response has whatever it has, if there is nothing cached for the name, a recursive query is issued and that is used (essentially) for the response.

The first question - is there an update to these definitions that documents the behavior we experience today? (I know we've talked this over on the list.)

Second question, should (specifically) the IANA registry "Value and Meaning" be altered to be more meaningful?

Why this matters - customer and customer support desks.

--

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

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

Never confuse activity with progress. Activity pays more.

--============_-977137415==_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 Feb 18 13:44:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED7428C20C; Wed, 18 Feb 2009 13:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.246 X-Spam-Level: X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 6KeL2BnUcHnt; Wed, 18 Feb 2009 13:44:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64EAF3A6999; Wed, 18 Feb 2009 13:44:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZu7B-000PuY-68 for namedroppers-data0@psg.com; Wed, 18 Feb 2009 21:37:57 +0000 Received: from [216.240.18.37] (helo=mx2.netapp.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZu76-000PuC-I5 for namedroppers@ops.ietf.org; Wed, 18 Feb 2009 21:37:55 +0000 X-IronPort-AV: E=Sophos;i="4.38,230,1233561600"; d="scan'208,217";a="129147449" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 18 Feb 2009 13:37:51 -0800 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n1ILbkki005102; Wed, 18 Feb 2009 13:37:51 -0800 (PST) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Feb 2009 13:37:48 -0800 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.112]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Feb 2009 16:37:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99211.004DECF7" Subject: RE: [dnsext] type=ANY Date: Wed, 18 Feb 2009 16:36:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] type=ANY Thread-Index: AcmSAfl9HVisGNn3QQ+QRqZ8V281kwADm5Mw References: From: "Everhart, Craig" To: "Edward Lewis" , X-OriginalArrivalTime: 18 Feb 2009 21:37:43.0806 (UTC) FILETIME=[21ED29E0:01C99211] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C99211.004DECF7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe you've captured the current state accurately: ANY for an authoritative server means "all", while to a caching server it means "whatever you have." And if the caching server has nothing for the given domain, it forwards the ANY query to its upstream server, which may then load "all" of the records into the cache. Otherwise, you might have a few specifically-asked-for types (e.g., "A") for the domain lying around in the caching server's cache. =20 I've used this semantics to obtain multiple types for a domain, but you can't tell about the absence of a specific type of RR unless you either ask for that specific type or ask the authoritative server. =20 Craig ________________________________ From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Wednesday, February 18, 2009 2:25 PM To: namedroppers@ops.ietf.org Cc: ed.lewis@neustar.biz Subject: [dnsext] type=3DANY =09 =09 Someone new to DNS asked me to explain the semantics of QTYPE=3DANY in a caching/recursive server. Stop me if you've heard this one before... One thing I noticed is that the documentation covering QTYPE=3D* and QCLASS=3D* is asymmetric. And, more to the point, the documents on QTYPE=3D* seem to be unclear. When I try to explain the semantics of some DNS parameter, I start with the IANA registry page (http://www.iana.org/assignments/dns-parameters). That page lists this: (Cutting some things like the hexadecimal out for clarity) # Registry Name: DNS CLASSes # Registry: # Decimal =20 # Hexadecimal Name Reference # ------------- ------------------------------ --------- # 255 QCLASS * (ANY) [RFC1035] # Registry Name: Resource Record (RR) TYPEs # Reference: [RFC5395][RFC1035] # Registry: # TYPE Value and meaning Reference # ----------- --------------------------------------------- --------- # * 255 A request for all records [RFC1035] Note that the (Q)TYPE "*" is defined as "all records" here, but in class "any" is used. From RFC 1035: # 3.2.3. QTYPE values # * 255 A request for all records =09 # 3.2.5. QCLASS values # * 255 any class =09 My understanding is that QTYPE=3D*, aka, QTYPE=3DANY, is not a request for all records, but whatever records a server has on hand. Trying this out with popular implementations, that is what it appears to be. If a server is authoritative, then any is all. If a server is a cache, if it has anything cached for a name then the response has whatever it has, if there is nothing cached for the name, a recursive query is issued and that is used (essentially) for the response. The first question - is there an update to these definitions that documents the behavior we experience today? (I know we've talked this over on the list.) Second question, should (specifically) the IANA registry "Value and Meaning" be altered to be more meaningful? Why this matters - customer and customer support desks. --=20 =09 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=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 =20 NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. ------_=_NextPart_001_01C99211.004DECF7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable type=3DANY

I believe you've captured the current state = accurately: ANY=20 for an authoritative server means "all", while to a caching server it = means=20 "whatever you have." And if the caching server has nothing for the = given=20 domain, it forwards the ANY query to its upstream server, which may then = load=20 "all" of the records into the cache. Otherwise, you might have a = few=20 specifically-asked-for types (e.g., "A") for the domain lying around in = the=20 caching server's cache.

I've used this semantics to obtain multiple = types for a=20 domain, but you can't tell about the absence of a specific type of RR = unless you=20 either ask for that specific type or ask the authoritative=20 server.

= Craig

From: Edward Lewis=20 [mailto:Ed.Lewis@neustar.biz]
Sent: Wednesday, February 18, = 2009=20 2:25 PM
To: namedroppers@ops.ietf.org
Cc:=20 ed.lewis@neustar.biz
Subject: [dnsext] = type=3DANY

Someone new to DNS asked me to explain the semantics of = QTYPE=3DANY in a=20 caching/recursive server.

Stop me if you've heard this one before...

One thing I noticed is that the documentation covering QTYPE=3D* = and=20 QCLASS=3D* is asymmetric. And, more to the point, the documents = on QTYPE=3D*=20 seem to be unclear.

When I try to explain the semantics of some DNS parameter, I = start with=20 the IANA registry page = (http://www.iana.org/assignments/dns-parameters). =20 That page lists this:

(Cutting some things like the hexadecimal out for clarity)

# Registry Name: DNS CLASSes
# Registry:

# Decimal

# Hexadecimal   =20 = Name                           =20 Reference

# ------------- ------------------------------ =20 ---------

# = 255           =20 QCLASS *=20 = (ANY)                 =20 [RFC1035]

# Registry Name: Resource Record (RR) TYPEs

# Reference: [RFC5395][RFC1035]

# Registry:
# = TYPE        =20 Value and=20 = meaning          =            =         =20 Reference

# ----------- = --------------------------------------------- =20 ---------

# = *            255=20 A request for all=20 = records          =        =20 [RFC1035]

Note that the (Q)TYPE "*" is defined as "all records" here, but = in class=20 "any" is used.

From RFC 1035:

# 3.2.3. QTYPE values

#=20 = *           =    =20 255 A request for all records

# 3.2.5. QCLASS values
#=20 = *            =   =20 255 any class

My understanding is that QTYPE=3D*, aka, QTYPE=3DANY, is not a = request for=20 all records, but whatever records a server has on hand. Trying = this out=20 with popular implementations, that is what it appears to be.

If a server is authoritative, then any is all. If a server = is a=20 cache, if it has anything cached for a name then the response has = whatever it=20 has, if there is nothing cached for the name, a recursive query is = issued and=20 that is used (essentially) for the response.

The first question - is there an update to these definitions that = documents the behavior we experience today? (I know we've talked = this=20 over on the list.)

Second question, should (specifically) the IANA registry "Value = and=20 Meaning" be altered to be more meaningful?

Why this matters - customer and customer support = desks.
--=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-=3D-=3D-

Edward=20 = Lewis
NeuStar      &nb= sp;         &nb= sp;  =20 You can leave a voice message at +1-571-434-5468

Never confuse activity with progress. Activity pays=20 more.

------_=_NextPart_001_01C99211.004DECF7-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 18 14: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 ADFB63A68D8; Wed, 18 Feb 2009 14:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVtEAcp8vjnd; Wed, 18 Feb 2009 14:11:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95CB83A682F; Wed, 18 Feb 2009 14:11:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZuYR-00028w-S8 for namedroppers-data0@psg.com; Wed, 18 Feb 2009 22:06:07 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZuYL-00027y-PR for namedroppers@ops.ietf.org; Wed, 18 Feb 2009 22:06:03 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1LZuYI-0004gB-N1 for namedroppers@ops.ietf.org; Wed, 18 Feb 2009 23:05:58 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7696C4B450; Wed, 18 Feb 2009 23:06:11 +0100 (CET) Date: Wed, 18 Feb 2009 23:06:11 +0100 From: bert hubert To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] type=ANY Message-ID: <20090218220611.GB28575@outpost.ds9a.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Feb 18, 2009 at 02:24:38PM -0500, Edward Lewis wrote: > Someone new to DNS asked me to explain the semantics of QTYPE=ANY in > a caching/recursive server. It just keeps on coming back :-) http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00454.html Chapter and verse can be found in the link above. > My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a request > for all records, but whatever records a server has on hand. Trying > this out with popular implementations, that is what it appears to be. Indeed, and this is all one can count on. PowerDNS Recursor will go out to the net for you if there is *nothing* in the cache, though. But only in that case. > Second question, should (specifically) the IANA registry "Value and > Meaning" be altered to be more meaningful? > > Why this matters - customer and customer support desks. I find that calls to support desks are rarely prevented by updating IANA registries though :-) But it might make sense to put the authoritative (haha) answer somewhere. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 18 22:56: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 C5A583A6A18; Wed, 18 Feb 2009 22:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_53=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 N51xSeoYWPrE; Wed, 18 Feb 2009 22:56:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D9513A6A0A; Wed, 18 Feb 2009 22:56:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1La2fV-0004ZV-Pq for namedroppers-data0@psg.com; Thu, 19 Feb 2009 06:45:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1La2fR-0004Z0-RH for namedroppers@ops.ietf.org; Thu, 19 Feb 2009 06:45:55 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n1J6ji01026476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 08:45:44 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n1J6jhpS026473; Thu, 19 Feb 2009 08:45:44 +0200 Date: Thu, 19 Feb 2009 08:45:43 +0200 (EET) From: Pekka Savola To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] type=ANY In-Reply-To: