(no subject)
Peter Losher
Peter_Losher at isc.org
Wed Oct 20 22:09:59 UTC 2004
--
Peter_Losher at isc.org | ISC | OpenPGP Key E8048D08 | "The bits must flow"
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 74485677EA
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 16:08:57 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id EED61284F9
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 16:08:56 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 820265C8C8
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 16:08:56 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id E6D815C8DD
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 16:08:55 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 16:08:55 +0000 (UTC)
Date: Wed, 20 Oct 2004 16:08:55 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: Ed.Lewis at neustar.biz
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004160855.83734.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BIZ_TLD,DONT_DELETE
autolearn=no version=2.64
Content-Type:
X-UID: 6316
X-Length: 6803
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 41768D97:14716.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 16:08:55 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id 730665C8C8
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 16:08:55 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id D85EF284F9; Wed, 20 Oct 2004 16:08:54 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKItJ-000F01-QA
for namedroppers-data at psg.com; Wed, 20 Oct 2004 16:00:45 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKItI-000Ezj-O0
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 16:00:45 +0000
Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id i9KG0crd082514
for <namedroppers at ops.ietf.org>; Wed, 20 Oct 2004 12:00:39 -0400 (EDT)
(envelope-from Ed.Lewis at neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis at 127.0.0.1
Message-Id: <a06110406bd9c394c873d@[192.35.166.53]>
In-Reply-To: <20041020153806.C2B9913E12 at sa.vix.com>
References: <20041020153806.C2B9913E12 at sa.vix.com>
Date: Wed, 20 Oct 2004 12:00:45 -0400
To: namedroppers at ops.ietf.org
From: Edward Lewis <Ed.Lewis at neustar.biz>
Subject: A/AAAA was Re: I-D ACTION:draft-iab-dns-choices-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
At 11:38 -0400 10/20/04, Paul Vixie wrote:
>the proposal didn't put the AAAA into the additional section, it put A RR's
>there on qtype=AAAA. just like A RR's go into the additional section on
>qtype=MX (though there it's the target rather than the owner name). are
>you reading what i'm writing, ed?
Yes. Although I was around during the discussions then, I didn't get
all that into the topic. After starting in on DNSSEC in 1996 (and
having a history in other lookup systems), I can now say that I
didn't really come to understand the DNS protocol until about 2002 or
2003. I'm still not sure I really understand all of it now.
I mention this to say that I don't bear scars of those discussions.
I may have caused some.
>i don't like your summary. "fear was mongered, several good solutions were
>quashed, and we got our comeuppance" is a much better summary. but it's
>just possible that i'm bitter about this, or twisted, or perhaps both.
And that may well be - and for justifiable reasons. What I've
learned is to have a short memory when it comes to the debate over
arriving at a solution.
A decision was made a while back. It's water under the bridge. The
question that we need to focus on is, as always in engineering "where
do we go from here?"
Do we want to revive the effort to "fix" the situation?
Do we want to revive the effort to "fix" the situation *now*?
Personally - I think the answer to the last question is no - not
*now* - as we try to determine if DNSSECbis is a success. I think we
can live with the hit we see now.
(But that is not what tipped off the thread.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"Now under neu management"
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 41768D97:14716.1:pbzccebgbpbyfqaffgq
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: pekkas at netcore.fi post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 74B6C677E9
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 07:45:58 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id C28B32854C
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 07:45:57 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 64C7F5C8DA
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 07:45:57 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id F11195C8DD
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 07:45:56 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 07:45:56 +0000 (UTC)
Date: Wed, 20 Oct 2004 07:45:56 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: pekkas at netcore.fi
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004074556.74302.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: pekkas at netcore.fi post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,DONT_DELETE autolearn=no
version=2.64
Content-Type:
X-UID: 6307
X-Length: 6524
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 417617B4:1223E.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 07:45:56 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id 6AC515C8DA
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 07:45:56 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id C08A62854C; Wed, 20 Oct 2004 07:45:55 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKAyu-0000w4-7r
for namedroppers-data at psg.com; Wed, 20 Oct 2004 07:34:00 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKAyt-0000vk-0J
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 07:33:59 +0000
Received: from localhost (pekkas at localhost)
by netcore.fi (8.11.6/8.11.6) with ESMTP id i9K7Xol05803;
Wed, 20 Oct 2004 10:33:52 +0300
Date: Wed, 20 Oct 2004 10:33:50 +0300 (EEST)
From: Pekka Savola <pekkas at netcore.fi>
To: "D. J. Bernstein" <djb at cr.yp.to>
Cc: namedroppers at ops.ietf.org
Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt
In-Reply-To: <20041020045937.29931.qmail at cr.yp.to>
Message-ID: <Pine.LNX.4.44.0410201026260.5296-100000 at netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
On 20 Oct 2004, D. J. Bernstein wrote:
> We already have encouragement. I already quoted the relevant sections of
> RFC 1034 and RFC 1123. I wouldn't object to yet another document making
> crystal clear that BIND and NSD and Microsoft screwed up and that we
> really want to get rid of this problem before 2010.
>
> However, until the bug has actually been fixed on every machine we can
> see, it's irresponsible to tell people to use new record types.
FWIW,
Depending on what we want to achieve, defining new RR's might make
perfect sense.
If a lot of prominent operators started using MARID-like techniques
using those RRs, this would actually provide a really significant
incentives for the vendors and the operators of broken equipment to
get their act together and fix their crap.
Unless we use it, nothing is going to change in the next 10 years.
There's a lot evidence that things just don't get fixed unless there
is some pressure (examples: firewalls breaking on ECN,
servers/balancers mistreating AAAA records, etc.). Maybe this would
be a good apportunity to get that broken gear fixed.
By the way, as it appears a lot of people are breaking DNS
specifications pretty badly, I wonder if it would make sense to try to
come up with some kind DNS implementation requirements document,
similar to "host requirements" a long time ago, but updated with
respect to new specs.. this would be a lot of work, but it might be
worth it if we want to decrease the amount of completely broken DNS
implementations out there.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 417617B4:1223E.1:pbzccebgbpbyfqaffgq
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: alex at alex.org.uk post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id AA701677E9
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 08:05:21 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id 10FFF28574
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 08:05:21 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id A3CC45C8DE
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 08:05:20 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 237EF5C8EA
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 08:05:20 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 08:05:19 +0000 (UTC)
Date: Wed, 20 Oct 2004 08:05:19 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: alex at alex.org.uk
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004080519.74756.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: alex at alex.org.uk post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,DONT_DELETE autolearn=no
version=2.64
Content-Type:
X-UID: 6308
X-Length: 6155
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 41761C3F:12404.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 08:05:19 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id 8D7F85C8DE
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 08:05:19 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id 1004128574; Wed, 20 Oct 2004 08:05:19 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKBNu-0003ux-UZ
for namedroppers-data at psg.com; Wed, 20 Oct 2004 07:59:50 +0000
Received: from [195.82.114.197] (helo=shed.alex.org.uk)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKBNu-0003uW-0N
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 07:59:50 +0000
Received: from [192.168.100.25] (localhost [127.0.0.1])
by shed.alex.org.uk (Postfix) with ESMTP
id 183A0C2DA9; Wed, 20 Oct 2004 08:59:46 +0100 (BST)
Date: Wed, 20 Oct 2004 08:59:36 +0100
From: Alex Bligh <alex at alex.org.uk>
Reply-To: Alex Bligh <alex at alex.org.uk>
To: "D. J. Bernstein" <djb at cr.yp.to>, namedroppers at ops.ietf.org
Cc: Alex Bligh <alex at alex.org.uk>
Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt
Message-ID: <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]>
In-Reply-To: <20041020045937.29931.qmail at cr.yp.to>
References: <16756.3478.675039.839347 at giles.gnomon.org.uk>
<20041018223155.A14DC13E14 at sa.vix.com> <20041019122130.GA13615 at nic.fr>
<1E357E7BA785EFB0D7718B31@[192.168.0.16]>
<20041019173246.87621.qmail at cr.yp.to>
<5A4B5BBC14254F3C218BD764@[192.168.100.25]>
<20041020045937.29931.qmail at cr.yp.to>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
--On 20 October 2004 04:59 +0000 "D. J. Bernstein" <djb at cr.yp.to> wrote:
> That's a much worse solution than pure TXT records, for several obvious
> reasons: (1) for interoperability, everyone will have to provide TXT
> records anyway
I don't see lots of people providing both A records and MX records for
this purpose (now).
> so the new RR type is extra work for the administrator;
> (2) the new-then-TXT approach is more work for software authors than
> pure TXT; (3) when networks are overloaded, the new-then-TXT approach
> fails more often than pure TXT; (4) the new-then-TXT approach is often
> slower, and never faster, than pure TXT.
I think the point is that you only try one if the other fails. Therefore
it can only be faster and MORE resilient to network congestion (etc.),
EXCEPT in the case of non-existent records, which I would suggest are
the minority.
Alex
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 41761C3F:12404.1:pbzccebgbpbyfqaffgq
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 6412D677EA
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 13:43:09 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id E78C4284F7
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 13:43:08 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 8173B5C8C8
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 13:43:05 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id E56715C8DD
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 13:43:04 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 13:43:04 +0000 (UTC)
Date: Wed, 20 Oct 2004 13:43:04 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: Ed.Lewis at neustar.biz
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004134304.81153.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BIZ_TLD,DONT_DELETE
autolearn=no version=2.64
Content-Type:
X-UID: 6309
X-Length: 6317
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 41766B68:13D01.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 13:43:04 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id 5D1E15C8C8
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 13:43:04 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id D9745284CA; Wed, 20 Oct 2004 13:43:03 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKGa6-000J05-EW
for namedroppers-data at psg.com; Wed, 20 Oct 2004 13:32:46 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKGa5-000Izo-Bj
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 13:32:45 +0000
Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id i9KDWZ7s081855
for <namedroppers at ops.ietf.org>; Wed, 20 Oct 2004 09:32:39 -0400 (EDT)
(envelope-from Ed.Lewis at neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis at 127.0.0.1 (Unverified)
Message-Id: <a06110400bd9c18432b0f@[192.168.1.100]>
In-Reply-To: <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]>
References: <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]>
Date: Wed, 20 Oct 2004 09:32:37 -0400
To: namedroppers at ops.ietf.org
From: Edward Lewis <Ed.Lewis at neustar.biz>
Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
At 3:59 -0400 10/20/04, Alex Bligh wrote:
>I think the point is that you only try one if the other fails. Therefore
>it can only be faster and MORE resilient to network congestion (etc.),
>EXCEPT in the case of non-existent records, which I would suggest are
>the minority.
Speaking from the experience of talking with the MARID group and also
from observing the behavior of one popular DNS implementation,
relying on a strategy of "try one, if it fails, try the other" is not
going to be well received.
The problem is that this causes a latency hit for the application.
Packets and bandwidth are cheap, a user's time isn't. Application
designers want to avoid long activity-dependency chains.
When searching for glue records, one DNS implementation asks for AAAA
and asks for A simultaneously at all steps. There's no real
alternative - it's not like you can ask for just the A and then get
the AAAA when you get an authoritative answer (positive or negative)
- or vice versa. That's because it's a waste of sending the last
query, especially when the domain name sought has just one or the
other address type.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"Now under neu management"
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 41766B68:13D01.1:pbzccebgbpbyfqaffgq
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 85C7A677E7
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 15:29:22 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id 035F728534
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 15:29:21 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id A8CEF5C8C8
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 15:29:21 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 31EF95C8DD
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 15:29:21 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 15:29:20 +0000 (UTC)
Date: Wed, 20 Oct 2004 15:29:20 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: Ed.Lewis at neustar.biz
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004152920.83160.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BIZ_TLD,DONT_DELETE
autolearn=no version=2.64
Content-Type:
X-UID: 6313
X-Length: 7090
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 41768450:144D8.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 15:29:20 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id AFFA15C8C8
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 15:29:20 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id 4546828532; Wed, 20 Oct 2004 15:29:20 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKIEc-0008K7-5d
for namedroppers-data at psg.com; Wed, 20 Oct 2004 15:18:42 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKIEb-0008Jk-1e
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 15:18:41 +0000
Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id i9KFIRo9082323;
Wed, 20 Oct 2004 11:18:29 -0400 (EDT)
(envelope-from Ed.Lewis at neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis at 127.0.0.1
Message-Id: <a06110402bd9c27abc7b2@[192.35.166.53]>
In-Reply-To: <20041020135101.6AE5A13E12 at sa.vix.com>
References: <20041020135101.6AE5A13E12 at sa.vix.com>
Date: Wed, 20 Oct 2004 11:17:59 -0400
To: Paul Vixie <paul at vix.com>
From: Edward Lewis <Ed.Lewis at neustar.biz>
Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt
Cc: namedroppers at ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
At 9:51 -0400 10/20/04, Paul Vixie wrote:
>what do you all think NOW?
Since you've asked. ;)
I think that it's not all bad. The current practice does achieve the
goals of minimizing latency, allowing the migration from v4 to v6
(and vice versa) to occur at the edges, is backward compatible with
older software, and is resilient. That's a lot of good. There is
that nasty cost of double the traffic though, that's a waste.
Hindsight isn't always 20-20.
Had we pursued multiple queries in a message, we'd have had to deal
with the issue of partial results - like, if one query was for
(foo.example. IN A) and the other was for (bar.example. IN A) and
foo.example. existed and bar.example. did not, how is a half name
error returned? Who knows - had we travelled down that road would
the WG be wrapped around the axle over AAAAbis by now?
Had we thrown the AAAA in the additional section, we may have had
problems with the older pass-through servers that might not have
known to add the AAAA's when it was needed (answering from a
non-authoritative source). We'd have been creating a new type with
"special considerations."
Summarizing the above - we now have empirical evidence of a pitfall
of the option chosen (which I prefer over anticipated concerns) and
we have two other options that haven't faced a test.
One untried option is a new RR type (e.g., NSADDR) which may have all
the glue in one RDATA (one large RDATA section). EDNS0 solves size
problems and we could do this as a "try this one, then fallback" for
backwards compat. Oops - there's that phrase "then fallback". Maybe
not wise course either.
I'd say that I'm happy with the bird in hand, even if it leaves me
with guano, than the two birds in the tree. I would be happier with
the two birds in the tree, but I have to keep asking if the effort to
obtain them is worth it considering what I already have.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"Now under neu management"
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 41768450:144D8.1:pbzccebgbpbyfqaffgq
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: vixie at vix.com post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id F3825677E9
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 15:48:55 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id 6BF6C284F9
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 15:48:55 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 005D15C8C8
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 15:48:54 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 660135C8DD
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 15:48:54 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 15:48:54 +0000 (UTC)
Date: Wed, 20 Oct 2004 15:48:54 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: vixie at vix.com
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004154854.83470.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: vixie at vix.com post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BIZ_TLD,DONT_DELETE
autolearn=no version=2.64
Content-Type:
X-UID: 6314
X-Length: 16141
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 417688E6:1460E.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 15:48:54 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id 674D15C8C8
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 15:48:53 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id 9E2A1284F7; Wed, 20 Oct 2004 15:48:52 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKIXY-000B9U-8o
for namedroppers-data at psg.com; Wed, 20 Oct 2004 15:38:16 +0000
Received: from [204.152.187.1] (helo=sa.vix.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKIXP-000B8L-0X
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 15:38:07 +0000
Received: from sa.vix.com (localhost [127.0.0.1])
by sa.vix.com (Postfix) with ESMTP id C2B9913E12
for <namedroppers at ops.ietf.org>; Wed, 20 Oct 2004 15:38:06 +0000 (GMT)
(envelope-from vixie at sa.vix.com)
From: Paul Vixie <vixie at vix.com>
To: namedroppers at ops.ietf.org
Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt
In-Reply-To: Message from Edward Lewis <Ed.Lewis at neustar.biz>
of "Wed, 20 Oct 2004 11:17:59 -0400."
<a06110402bd9c27abc7b2@[192.35.166.53]>
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Date: Wed, 20 Oct 2004 15:38:06 +0000
Message-Id: <20041020153806.C2B9913E12 at sa.vix.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
> >what do you all think NOW?
>
> Since you've asked. ;)
>
> I think that it's not all bad. The current practice does achieve the
> goals of minimizing latency, allowing the migration from v4 to v6 (and
> vice versa) to occur at the edges, is backward compatible with older
> software, and is resilient.
if a AAAA response comes in without A RRs in the additional data section
and you happen to need them then (and only then) do you have to do another
query (for the A RRset).
if the servers you're talking to don't support qdcount>1 then you'll have
to do multiple queries.
both proposals were opportunistic and ended in good balance other than the
leftover complexity of having to support qdcount>1 even after IPv4's dead;
however, other possibilities exist, like querying for both MX+AAAA, or
SRV+AAAA, in various applications like mail transports. so the complexity
would not have been truly wasted even after IPv4's dead.
> Had we pursued multiple queries in a message, we'd have had to deal with
> the issue of partial results - like, if one query was for (foo.example. IN
> A) and the other was for (bar.example. IN A) and foo.example. existed and
> bar.example. did not, how is a half name error returned? Who knows - had
> we travelled down that road would the WG be wrapped around the axle over
> AAAAbis by now?
the proposal was for qdcount>1, all qname's the same, all qclass's the same,
and variant qtype. so your multiple-qname scenario was under prior restraint.
> Had we thrown the AAAA in the additional section, we may have had problems
> with the older pass-through servers that might not have known to add the
> AAAA's when it was needed (answering from a non-authoritative source).
> We'd have been creating a new type with "special considerations."
the proposal didn't put the AAAA into the additional section, it put A RR's
there on qtype=AAAA. just like A RR's go into the additional section on
qtype=MX (though there it's the target rather than the owner name). are
you reading what i'm writing, ed?
> Summarizing the above - we now have empirical evidence of a pitfall of the
> option chosen (which I prefer over anticipated concerns) and we have two
> other options that haven't faced a test.
i don't like your summary. "fear was mongered, several good solutions were
quashed, and we got our comeuppance" is a much better summary. but it's just
possible that i'm bitter about this, or twisted, or perhaps both.
> One untried option is a new RR type (e.g., NSADDR) which may have all
> the glue in one RDATA (one large RDATA section). EDNS0 solves size
> problems and we could do this as a "try this one, then fallback" for
> backwards compat. Oops - there's that phrase "then fallback". Maybe
> not wise course either.
>
> I'd say that I'm happy with the bird in hand, even if it leaves me with
> guano, than the two birds in the tree. I would be happier with the two
> birds in the tree, but I have to keep asking if the effort to obtain them
> is worth it considering what I already have.
there are really two questions here. one is just out of bitterness and it
goes something "did we do the right thing?" and we all agree it's irrelevant.
the other question, though, is relevant: "should we do something different?"
with that in mind, here's the current EDNS1 draft, last revised two years
ago, containing the qdcount>1 proposal. the historians among y'all know
that this text was excised from EDNS0 in order to trim down EDNS0 into
something the world could understand and agree on. i apologize for the
length -- it's three pages. but the third page is just the references.
note that ISC's name has changed since this was last troff'd.
---
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-ietf-dnsext-edns1-03.txt> August, 2002
Extensions to DNS (EDNS1)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a number of extensions within the Extended
DNS framework defined by [EDNS0], including several new extended
label types and the ability to ask multiple questions in a single
request.
1 - Rationale and Scope
1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see
[RFC1035]) which provides for larger message sizes, additional label
types, and new message flags.
1.2. This document makes use of the EDNS extension mechanisms to add the
ability to ask multiple questions in a single request.
Expires March 2003 [Page 1]
INTERNET-DRAFT EDNS1 August, 2002
2 - Affected Protocol Elements
2.1. Multiple queries in a question section have not been supported in
DNS due the applicability of some DNS Message Header flags (such as AA)
and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
Multiple questions per request are desirable, and some way of asking
them must be made available.
3 - OPT pseudo-RR Flags and Options
3.1. The extended RCODE and flags are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | extended-rcode | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: |md |FM |RRD|lm | z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
VERSION Indicates the implementation level of whoever sets it. Full
conformance with the draft standard version of this
specification is version ``1.'' Note that both requestors and
responders should set this to the highest level they implement,
that responders should send back RCODE=BADVERS and that
requestors should be prepared to probe using lower version
numbers if they receive an RCODE=BADVERS.
FM ``First match'' flag. Notable only when multiple questions are
present. If set in a request, questions will be processed in
wire order and the first question whose answer would have
NOERROR AND ANCOUNT>0 is treated as if it were the only
question in the query message. Otherwise, questions can be
processed in any order and all possible answer records will be
included in the response. Response FM should be ignored by
requestors.
RRD ``Recursion really desired'' flag. Notable only when a request
is processed by an intermediate name server (``forwarder'') who
is not authoritative for the zone containing QNAME, and where
QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate
name server can only answer using unexpired cached answers
(either positive or negative) which were atomically acquired
using (a) the same QTYPE or set of QTYPEs present in the
current question and whose TTLs were each minimized to the
Expires March 2003 [Page 2]
INTERNET-DRAFT EDNS1 August, 2002
smallest among them when first cached, and (b) the same FM and
LM settings present in the current question.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
4 - Multiple Questions for QUERY
4.1. If QDCOUNT>1, multiple questions are present. All questions must
be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It
is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
4.2. RCODE and AA apply to all RRs in the answer section having the
QNAME that is shared by all questions in the question section. AA
applies to all matching answers, and will not be set unless the exact
original request was processed by an authoritative server and the
response forwarded in its entirety.
4.3. If a multiple question request is processed by an intermediate
server and the authority server does not support multiple questions, the
intermediate server must generate an answer iteratively by making
multiple requests of the authority server. In this case, AA must never
be set in the final answer due to lack of atomicity of the contributing
authoritative responses.
4.4. If iteratively processing a multiple question request using an
authority server which can only process single question requests, if any
contributing request generates a SERVFAIL response, then the final
response's RCODE should be SERVFAIL.
4.5. An authority server processing a query for which QDCOUNT>1 will
respond with a delegation or referral if any of the multiple QTYPEs
present would yield such a response when QDCOUNT==1.
4.6. An initiator can infer the absence of any RRs for one of the QTYPEs
where QDCOUNT>1 if the response contains no RRs of that type but some
RRs for one of the other QTYPEs present.
Expires March 2003 [Page 3]
INTERNET-DRAFT EDNS1 August, 2002
5 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
[RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
IETF DNSIND, September 1998
6 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1.650.779.7001
<vixie at isc.org>
Expires March 2003 [Page 4]
---
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 417688E6:1460E.1:pbzccebgbpbyfqaffgq
-- Attached file included as plaintext by Ecartis --
-- File: forwarded message
-- Desc: ISC Mailing List Manager <ecartis at isc.org>: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
Return-Path: <ecartis at isc.org>
X-Original-To: plosher at farside.isc.org
Delivered-To: plosher at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 15422677E7
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 15:57:37 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP id 8D742284F9
for <plosher at farside.isc.org>; Wed, 20 Oct 2004 15:57:36 +0000 (UTC)
(envelope-from ecartis at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 054F85C8C8
for <Peter_Losher at isc.org>; Wed, 20 Oct 2004 15:57:35 +0000 (UTC)
(envelope-from ecartis at isc.org)
X-Original-To: comp-protocols-dns-std-moderators at isc.org
Delivered-To: comp-protocols-dns-std-moderators at rc3.isc.org
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id 80EB95C8DD
for <comp-protocols-dns-std-moderators at isc.org>; Wed, 20 Oct 2004 15:57:35 +0000 (UTC)
(envelope-from Peter_Losher at isc.org)
Received: from isc.org by isc.org (ECARTIS/1.0.0);
Wed, 20 Oct 2004 15:57:35 +0000 (UTC)
Date: Wed, 20 Oct 2004 15:57:35 +0000 (UTC)
From: ISC Mailing List Manager <ecartis at isc.org>
Reply-To: Ed.Lewis at neustar.biz
To: comp-protocols-dns-std-moderators at isc.org
Message-ID: <ecartis-10202004155735.83579.1 at isc.org>
X-ecartis-antiloop: isc.org
Precedence: list
Subject: comp-protocols-dns-std: Ed.Lewis at neustar.biz post needs approval
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on farside.isc.org
X-Spam-Level: *
X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BIZ_TLD,DONT_DELETE
autolearn=no version=2.64
Content-Type:
X-UID: 6315
X-Length: 6981
This message was received for a list you are a moderator on, and
was marked for moderation due to the following reason:
Non-member submission to closed-post list.
To approve this message and have it go out on the list, forward this to
comp-protocols-dns-std-repost at isc.org
If you wish to decline the post, change the 'apppost' below to 'delpost'.
If you wish to edit the post, change it to 'modpost' and edit the message
as needed - not all mail programs will work with modpost.
DO NOT DELETE THE FOLLOWING LINE. Ecartis needs it.
// apppost 41768AEF:1467B.1:pbzccebgbpbyfqaffgq
>From owner-namedroppers at ops.ietf.org Wed Oct 20 15:57:35 2004
Return-Path: <owner-namedroppers at ops.ietf.org>
X-Original-To: comp-protocols-dns-std at rc3.isc.org
Delivered-To: comp-protocols-dns-std at rc3.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by rc3.isc.org (Postfix) with ESMTP id F10695C8C8
for <comp-protocols-dns-std at rc3.isc.org>; Wed, 20 Oct 2004 15:57:34 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sf1.isc.org (Postfix) with ESMTP
id 1EDBE284F9; Wed, 20 Oct 2004 15:57:34 +0000 (UTC)
(envelope-from owner-namedroppers at ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
id 1CKIcO-000BsS-05
for namedroppers-data at psg.com; Wed, 20 Oct 2004 15:43:16 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.41 (FreeBSD))
id 1CKIcM-000Bs7-QK
for namedroppers at ops.ietf.org; Wed, 20 Oct 2004 15:43:15 +0000
Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id i9KFh8ir082435
for <namedroppers at ops.ietf.org>; Wed, 20 Oct 2004 11:43:09 -0400 (EDT)
(envelope-from Ed.Lewis at neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis at 127.0.0.1
Message-Id: <a06110405bd9c34b2735b@[192.35.166.53]>
In-Reply-To: <20041020135111.GA32727 at vacation.karoshi.com.>
References: <20041020135111.GA32727 at vacation.karoshi.com.>
Date: Wed, 20 Oct 2004 11:43:14 -0400
To: namedroppers at ops.ietf.org
From: Edward Lewis <Ed.Lewis at neustar.biz>
Subject: Re: the uberTXT
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.44
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.64
Sender: owner-namedroppers at ops.ietf.org
Precedence: bulk
>> The bottom line is that TXT succeeds in delivering the data to every
>> interested client, whereas new record types are a miserable failure.
>
> this line of thinking should raise the question - why keep
> any of the other, now vestigal, RR types... anything we want
> can be done in the TXT RR. right?
Peace folks.
The argument here is not head to head. One set of words reflects the
way it is now. The other set of words is motivated by what may lie
ahead.
I really want to encourage the continual movement towards an
architectural correct DNS. Without that, the system will become
unmanageable and will be forced into stagnation from an engineering
viewpoint.
But reformation comes at a cost - we can't shutdown the DNS for a
week, have a flag day, instructing all uses of DNS software upgrade
on a dime. For this, we have to give a nod to doing some undesirable
things, undesirable from the point of view of an architectural purist.
What's missing from the discussion is how the DNS engineering
community helps lead the communities using DNS to reform their ways
when it comes to using DNS. (E.g., what can be done to get
application developers to not hold DNS data beyond the TTL
recommendation?) This is the answer to the "we gotta use TXT cause
it works today," not retorting with "relying on the TXT means we can
remove all other types."
I can't imagine any engineer worth their salt would want a system to
stagnate. I can imagine an engineer doing everything possible to
continue to offer support to users, even if this means stagnation
might look like the best approach.
That is why I think the draft ought to recognize that it is
preferable to extend via new types and ought to acknowledge that
reusing TXT, although discouraged, has a legitimate role in DNS work.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"Now under neu management"
--
to unsubscribe send a message to namedroppers-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
// eompost 41768AEF:1467B.1:pbzccebgbpbyfqaffgq
More information about the bind-users
mailing list