Re: [DNSOP] More work for DNSOP :-)

Paul Vixie <> Sat, 07 March 2015 01:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D81B81A8794 for <>; Fri, 6 Mar 2015 17:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YBK7rP0kepw3 for <>; Fri, 6 Mar 2015 17:25:27 -0800 (PST)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCF741A8790 for <>; Fri, 6 Mar 2015 17:25:27 -0800 (PST)
Received: from [IPv6:2001:559:8000:cb:b015:3cb0:25ba:df77] (unknown [IPv6:2001:559:8000:cb:b015:3cb0:25ba:df77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 7DFE6184D7; Sat, 7 Mar 2015 01:25:27 +0000 (UTC)
Message-ID: <>
Date: Fri, 06 Mar 2015 17:25:23 -0800
From: Paul Vixie <>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Paul Wouters <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------000308000309070704070901"
Archived-At: <>
Cc: Evan Hunt <>, "" <>
Subject: Re: [DNSOP] More work for DNSOP :-)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Mar 2015 01:25:30 -0000

Paul Wouters wrote:
> On Fri, 6 Mar 2015, Paul Vixie wrote:
>> ...
>> i'd like to see this done. it would not require an internet-draft, ...
> At the time, I was more thinking of an EDNS option with a nsec3-style
> bitmap to specify which RRTYPE's you are interested in. Those would
> have to include the proof that something does not exist. It gets
> trickier if you want to support asking for "IPSECKEY and TLSA record for
>" and map that to the proper for
> TLSA and its NSEC3 records.

we don't need new signaling. additional data rules already permit what
i'm proposing here.

> People were pretty fast to say "just send multiple queries at once". And
> that is kind of true, and exactly what is now done with A / AAAA. But it
> would be better to get one query reply so you can make an informed
> decision instead of either waiting for the 2nd query or doing v4 when
> you could have done v6 if you had waited on the second query reply.

certainly, sending multiple queries in parallel means more processing
for everybody including the intervening routers, and unless you have a
tcp session open, means you have a smaller chance of success (meaning,
that nothing you want back will face loss or congestion.) if you need to
know whether AAAA exists before you will fall back to IPv4, then you
have to wait for both responses before you can make your next move.
also, if AAAA would satisfy you, then you'll end up hearing an "A"
response that you don't care about, probably after you've made your next
move (initiated a IPv6 TCP session). i don't see how we can build the
star-trek like future that many of us would like to live in, starting
from awful design-by-organic-side-effect like this.

> The problem with specifying this without a new EDNS option is that you
> don't know the differenec between old software or a missing A/AAAA
> record - you just know it was not in the reply. So software will still
> use two queries. It's fixable, but the migration path will take years
> while we don't have a good dns library to do this work in that everyone
> will then use.

my proposal is just send the additional data. granted, many RDNS clients
("stub resolvers") wouldn't cache the additional data, but newer ones
like that we hope the world will switch to, can.
and, if ADNS servers did this, then it would prepopulate the RDNS cache,
thus speeding up the non-parallel queries that folks are making today.
(this is the big win from MX, SRV, and NS additional data processing.)

so, no new signaling is needed. this can be done, opportunistically,
now, by anybody and everybody.

Paul Vixie