Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

From: Tim Wicinski <[email-masked]>
Date: Sun, 1 Nov 2015 17:36:42 +0900

Hi

The authors have updated their document to address all outstanding 
issues, and we feel the document is ready for Working Group Last Call.

This starts a Working Group Last Call for
	draft-ietf-dnsop-edns-chain-query

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

Currently the document is marked “Standards Track”, but due to lack of 
implementations at this time (though some are being worked), I am 
suggesting we apply the “Experimental” label to this.  The working group 
is welcome to chime inhere.

Because we are at IETF this week, we will set aside time at the 
microphones for any issues that members wish to raise.

This starts a two week Working Group Last Call process, and ends on 
Sunday 15 November 2015.

thanks
tim

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 02 Nov 2015 10:45:20 -0500

On 1 Nov 2015, at 3:36, Tim Wicinski wrote:

> feels the document is *not* ready for publication, please speak out 
> with your reasons.

I have read this document and believe it needs a bit more work. Sorry 
for not reviewing this document earlier (e.g. before the wg last call).

> Currently the document is marked “Standards Track”, but due to 
> lack of implementations at this time (though some are being worked), I 
> am suggesting we apply the “Experimental” label to this.  The 
> working group is welcome to chime inhere.

According to RFC 2026 section 4.1.1, "Proposed Standard":

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has 
received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard
    designation.

I don't think a lack of implementation reports should be a deal breaker 
for proposed standard. No doubt our illustrious AD could shed some light 
here, however, since I am far from familiar with this stuff.

Suggestions

General

The introduction and overview are littered with phrases like 
"stub-mode", "DNS client" and "host" that, because of the nineteen 
different varieties of name server we have to deal with come across as 
ambiguous. Worse, there are different world-views about DNSSEC 
validation on end hosts, e.g. those that trust an unsigned AD bit, 
expecting validation to occur upstream, and those who do validation 
themselves.

I think the context of the whole document would be much easier to grasp 
for a new reader if there was a clear diagram as close to the top of the 
text as possible that clearly outlined the precise deployment scenario 
we're talking about. I realise there is plenty of text that describes 
the use case here, but starting with a picture I think would be a great 
kindness to the reader.

Specification

The "Closest Trust Point (FQDN)" field in the EDNS(0) option as 
described in section 4 is a bit vague, I think. You're talking about an 
owner name, but you don't mention that phrase; you talk about "lowest" 
without context (is the root at the top or the bottom?) You don't 
specify the encoding of the owner name; I think it's natural to assume 
that it's a series of run-length encoded labels with a zero-length label 
indicating the end, but as written it could be taken as being in 
presentation format with a trailing dot (a nod to the use of "FQDN" 
which is generally in presentation format).

I have some reservations about the idea of inferring capabilities based 
on previous experience interacting with a server at a particular 
address. Authority servers are frequently built in clusters, and the 
origin server that responds to one query at one address might be 
different from the one that responds next time. Similarly, clients are 
frequently deployed behind NATs, and inferring capabilities based on 
source address there seems like a bad idea.

More fundamentally, I'm not sure I understand the benefit of 
capabilities discovery. A client surely should add the option to all 
queries; if it gets useful information back in the response it can use 
it, and if it doesn't, it has to re-query along the chain anyway. If the 
concern is related to dealing with servers that don't deal with unknown 
EDNS(0) options correctly, then I think the preferred approach would me 
to let them fail, forcing operator intervention on one or both sides.

Aside from capabilities disovery, I'm not sure what the purpose is of a 
server including the CHAIN option in a response. The sections in the 
response will either contain additional, useful information or they 
won't -- it's not clear to me what benefit the CHAIN signalling from 
server to client provides.

Section 5.4 indicates that extra RRSets included because of CHAIN 
processing should be included in the authority section. Wouldn't the 
additional section make more sense, except in the case of RRSIGs over an 
NS RRSet?

Section 6.4 contains the intriguing word "partian" that I had not 
encountered before, although I have to say I like it.

Section 8.1 uses the phrase "source IP address verification" which is 
vague. Do you mean that the implementation needs to have convincing 
indications that a query is not spoofed, e.g. by using DNS cookies? Or 
do you mean that the server should not be an open resolver? Or that if 
it's an open resolver, it should be operated mindful of the fact that 
there is amplification potential?

Joe

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 Nov 2015 21:06:16 +0900

On Sun, Nov 1, 2015 at 5:36 PM, Tim Wicinski <[email-masked]> wrote:

> Hi
>
> The authors have updated their document to address all outstanding issues,
> and we feel the document is ready for Working Group Last Call.
>

I've read this document and think it proposes a useful capability.

I also have a practical use for an option like this - the TLS dnssec
chain extension that I'm involved in. Server implementations of that
extension could use the EDNS chain query capability to more efficiently
build the authentication chain returned to the TLS client.

Some other quick comments:

> This document specifies an EDNS0 extension that allows a validating
> Resolver running as a Forwarder to open a TCP connection to another
> Resolver and request a DNS chain answer using one DNS query/answer
> pair.

The definition of "Forwarder" being used here conflicts with the
definition in existing DNS protocol documents (e.g. RFC2308) and
also in the new draft-ietf-dnsop-dns-terminology document.

For what it's worth, I prefer the reversed definition this draft is
using which is much more logical, but I think it's important that we
use an agreed upon term or reconcile this in some other manner.

> Closest Trust Point, a variable length FDQN of the requested start
> point of the chain.

FDQN --> FQDN. But it is probably worth being more explicit. I assume
you mean a fully qualified domain name in DNS wire format.

> 5.4.  Generate a Response
>
> When a query containing a non-zero CHAIN option is received from a
> Forwarder, the upstream Recursive Resolver supporting CHAIN MAY
> respond by confirming that it is returning a CHAIN.  To do so, it MUST
> set the CHAIN option to the lowest Trust Point sent as part of the
> chain, with its corresponding OPTION-LENGTH.  It extends the Authority
> Section in the DNS answer packet with the DNS RRsets required for
> validating the answer.  The DNS RRsets added start with the first
> chain element below the received Closest Trust Point up to and
> including the NS and DS RRsets that represent the zone cut
> (authoritative servers) of the QNAME.

To follow-up on in-person discussion that happened at the last dnsop
meeting, this last sentence seems to imply an ordered sequence of RRsets
in the authority section comprising the chain. Since consensus is
against introducing ordering of RRsets in DNS message sections, this
should probably be reworded.

> A DNS query that contains the CHAIN option MUST also have the DNSSEC
> OK bit set.  If this bit is not set, the CHAIN option received MUST
> be ignored.

What is the expected behavior if the requestor sets the CD bit?

> 6.2.  NS record Considerations
>
> CHAIN responses MUST include the NS RRset from the child zone
> including the RRSIG records required for validation.
>
> When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer
> required to use the NS RRset, as it can construct the validation path
> via the DNSKEY and DS RRsets without using the NS RRset.  However, the
> Forwarder might be forced to switch from Forwarder mode to Recursive
> Resolver mode due to a network topology change.  In Recursive Resolver
> mode, the NS RRsets are needed to find and query Authoritative Servers
> directly.  It is RECOMMENDED that the DNS Forwarder populate its cache
> with this information to avoid requiring future queries to obtain any
> missing NS records.  Therefore, CHAIN responses MUST include the NS
> RRset from the child zone, including the RRSIG records required for
> validation.

What is meant by "the NS RRset from the child zone"? Should this be the
NS RRset of the zone containing the queried name?

I understand the stated rationale for including NS RRsets. On the other
hand this makes it less likely that the TLS chain extension would use
this message format (because of size considerations) rather than its
current format of a sequence of RRsets (a discussion that is happening
around that draft).

--
Shumon Huque

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Nov 2015 13:02:48 +0000

> issues, and we feel the document is ready for Working Group Last Call.

The rationale for this document is still completely wrong. It does not
provide any reduction in latency compared to the existing DNS protocol.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay, Southeast Fitzroy: Southwesterly 5 or 6 in far north, otherwise
variable 3 or 4. Moderate or rough. Fair. Good.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 09 Nov 2015 08:22:46 -0800

> provide any reduction in latency compared to the existing DNS 

Is that really true? That is, I assume that you mean the latency with 
this proposal is due to the recursive still having to go fetch all the 
pieces. However, if the recursive already has some or all of the answers 
in its cache, this proposal reduces the latency compared to the stub 
asking for each piece. Or, I might be misunderstanding why you think 
there is no latency reduction.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Nov 2015 16:55:24 +0000

Paul Hoffman <[email-masked]> wrote:
> Is that really true? That is, I assume that you mean the latency with this
> proposal is due to the recursive still having to go fetch all the pieces.

No, I mean stub/recursive latency.

> However, if the recursive already has some or all of the answers in its cache,
> this proposal reduces the latency compared to the stub asking for each piece.

No, as I have explained at least twice before.

With the current DNS protocol, a stub resolver can get all the records it
needs to validate a response in 1RTT, by sending multiple concurrent
queries for all the possible delegation points in the QNAME.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay, Southeast Fitzroy: Southwesterly 5 or 6 in far north, otherwise
variable 3. Moderate or rough. Fair. Good.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 09 Nov 2015 09:34:17 -0800

On 9 Nov 2015, at 8:55, Tony Finch wrote:

>> this

OK, but...

> queries for all the possible delegation points in the QNAME.

I'm confused. How does the stub know all of those ahead of time?

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Mon, 9 Nov 2015 20:52:32 +0000

> queries for all the possible delegation points in the QNAME.

But has to retain state for all those active queries, which adds a fair
bit of complexity.  I would expect it to be a lot more straightforward to
code a stub validator using CHAIN.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 9 Nov 2015 17:36:46 -0800

> code a stub validator using CHAIN.

In deep zones like the reverse zones the stub has no idea where the zone
cuts are thus
this idea is work reduction for the stub

Olafur

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Nov 2015 21:28:45 +0000

Ólafur Guðmundsson <[email-masked]> wrote:
> cuts are thus this idea is work reduction for the stub

Yes, this is true, and edns-chain-query also reduce bandwidth use.

However the only benefit of edns-chain-query claimed in the abstract is
reduced latency and this is completely wrong.

WRT complexity, from the validation code I have looked at, the main
problem (in multiple validators in multiple languages) is that the
validation process is too finely interleaved with the query process, and
you would have to disentangle them to make good use of edns-chain-query.
But once you have done that it is pretty easy, and a LOT more
interoperable, to send concurrent queries.

Note that finding zone cuts is not relevant to latency: if you send
concurrent queries for all possible cuts you will find out in 1RTT where
the cuts are and all the information you need for validation. What
edns-chain-query reduces is the bandwidth for the non-zone-cut queries and
responses, and the work of separating the relevant and irrelevant
responses.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Westerly or southwesterly 5 or 6, occasionally 7 later.
Moderate or rough. Rain or squally showers. Moderate or good, occasionally
poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Nov 2015 21:29:30 +0000

> I'm confused. How does the stub know all of those ahead of time?

The possible delegation points are where the dots are in the QNAME.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Easterly 5 to 7 in far southeast, otherwise variable 3 or 4.
Moderate, occasionally rough in far southeast. Mainly fair. Mainly good.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 10 Nov 2015 15:35:46 -0800

Do we know of any implementations that have tried this? 

From my high tech gadget

> On Nov 10, 2015, at 13:29, Tony Finch <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Nov 2015 05:18:56 +0000

> The possible delegation points are where the dots are in the QNAME.

Except in the presence of CNAME (possibly via DNAME) records, which
might mean that the client needs more records to validate multiple
nodes in the DNS tree.

So without nameserver assistance 1RTT via parallelism is not always
possible.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2015 10:15:53 +0000

> Do we know of any implementations that have tried this?

I mentioned in another message that I did a brief survey of validators. I
was trying to see if there was one I could easily adapt to concurrent
queries. Sadly I couldn't find one. A lot of validators are coupled to
iterative resolvers, which don't have the same opportunity for fast
concurrent validation that stub resolvers have.

I don't know of any existing validators thet make concurrent queries. I
think this is why validation has a reputation for being slow. The problem
is with the implementations, not with the protocol.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland, Plymouth: Southwest 5 to 7, decreasing mainly 4 later.
Moderate, occasionally rough in Portland and Plymouth. Drizzle at times.
Moderate or good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2015 11:35:22 +0000

> So without nameserver assistance 1RTT via parallelism is not always

Yes, with aliases you sometimes need 2RTT.

However edns-chain-query also has a problem with aliases since the server
doesn't know what the client might already have cached regarding the CNAME
or DNAME target. The server has to either send too little information, in
which case the client needs a second round trip, or too much information,
in which case it negates the bandwidth saving.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: Southwesterly 6 to gale 8, but 4 or 5 at first in north. Moderate
or rough. Rain or drizzle, squally showers later. Moderate or good,
occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Nov 2015 06:36:52 -0800

> The possible delegation points are where the dots are in the QNAME.

i've watched this go back and forth, while changing planes, trains, and automobiles. 
(greetings from amsterdam! and yes, istanbul was lovely!)

first, i don't think you mean dots. paul\.vixie.redbarn.org is three labels but only two 
possible delegation points. if you mean label boundaries you have to say label boundaries, 
because dots can appear inside labels.

second, you can't send a burst of queries, as a validator. even apart from the fact that any 
CNAME (RFC 2317 style) can add delegation points that weren't at label boundaries in 
your original QNAME, and there can be more than one of these, so you're not at RTT=1 or 
even RTT<=2, you're at RTT>0 without knowing the upper bound...

...you can't flood the channel. stubs might do so, at their peril, but will be rate limited if 
they exceed channel capacity to their RDNS (for cache hits) or above their RDNS (for 
cache misses). validators, on the other hand, must not generate background queries in 
bursts. unless bufferbloat is happening, most microbursts will be lossy, and if bufferbloat 
is happening, microbursts will make everything else worse.

each currently-in-progress query inside a validator (or indeed, any RDNS or proxy) must 
make at most one upstream query at a time, and use the network's RTT as its rate limit. 
otherwise you're hosing yourself and everyone else.

there are a lot of great reasons why chain queries are necessary. there is in fact no other 
way to do what they do.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2015 15:56:31 +0000

Paul Vixie <[email-masked]> wrote:
>
> if you mean label boundaries you have to say label boundaries,

Yes.

> second, you can't send a burst of queries, as a validator. even apart
> from the fact that any CNAME (RFC 2317 style) can add delegation points
> that weren't at label boundaries in your original QNAME, and there can
> be more than one of these, so you're not at RTT=1 or even RTT<=2, you're
> at RTT>0 without knowing the upper bound...

You get the entire CNAME chain in the first RTT so you can validate all
the links in the chain in the second RTT.

> ...you can't flood the channel.

In most cases this will be four or six concurrent queries which is hardly
flooding the channel. This is comparable to the TCP initial window or the
burst of SYNs you get when a browser starts fetching a page full of
images.

Browsers send a lot of concurrent queries. My experience with adns tells
me that concurrent queries work nicely at volumes orders of magnitude
bigger than we are considering here.

If you already have a TCP channel open you can send all the queries with
one write and they'll happily fit in a single segment.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, South Rockall: Southwesterly 7 to severe gale 9, increasing storm 10,
perhaps violent storm 11 later. Very rough or high, becoming high or very high
later. Rain or thundery showers. Moderate or poor, occasionally good.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Nov 2015 08:26:28 -0800

> the links in the chain in the second RTT.

here, you appear to be planning for a stub validator, which makes RD=1 queries. in a 
recursive caching validator, it would only receive CNAME chains of length>1 for in-zone 
CNAME's or CNAME's that cross zones where both the source and destination zones are 
served by the authority server you happen to be speaking to at the moment. for RFC 2317 
that's almost never the case.

> flooding the channel. ...

yes, that's flooding the channel. you're allowed one work-stream per query, in order that 
timeouts and other loss are only felt as backpressure by those apps who caused them.

> This is comparable to the TCP initial window or the

these aren't browsers, those aren't web servers, and i'm not talking about TCP.

> one write and they'll happily fit in a single segment.

i have no objection to multiple parallel outstanding upstream queries over a TCP stream.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2015 16:41:27 +0000

Paul Vixie <[email-masked]> wrote:

> here, you appear to be planning for a stub validator, which makes RD=1 queries.

Yes, that's what edns-chain-query is for.

> yes, that's flooding the channel. you're allowed one work-stream per
> query, in order that timeouts and other loss are only felt as
> backpressure by those apps who caused them.

Where is that specified?

> i have no objection to multiple parallel outstanding upstream queries

Why is TCP special?

Tony.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Nov 2015 08:57:48 -0800

> > backpressure by those apps who caused them.

it's written in tire tracks down my backside.

> > i have no objection to multiple parallel outstanding upstream queries

because it has per-flow congestion control.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2015 22:01:51 +0000

> it's written in tire tracks down my backside.

Sounds painful :-)

> because it has per-flow congestion control.

Which is perfectly fair, but there is a big difference between saying that
high-volume DNS clients need congestion control, and saying that they must
have at most one query outstanding at any time. If you say TCP is OK, you
are implicitly saying that it's OK to have a window size greater than one
packet. And that implies there are engineering questions about how that
window size should be managed.

And this implies it is unreasonable to forbid concurrent queries over UDP.
(And it would be futile to break running code in every browser.)

The upshot of all this is that how you use concurrent queries to improve
performance without breaking things is a matter of engineering and
implementation quality.

And since (as far as I know) no-one has done that engineering, I think it
is premature to try to deploy a protocol fix for a hypothetical problem.
(adns's concurrency control is quite simplistic, for example.)

What edns-chain-query says to DNSSEC users is, DNSSEC still isn't finished
or ready for deployment on edge devices, and you have to wait another 5 or
10 years for another protocol change to be deployed before you can get
decent performance.

This is wrong!

In order to make edns-chain-query work, validators will need to be
refactored to decouple the validation logic from the network chatter. At
the moment there aren't APIs that let you present a chain of DNSKEY and DS
RRsets to a validator and get an assessment. The current model is
"validate this RRset please" and then wait for a dozen RTTs.

But once you have a validator API that works with edns-chain-query you
also have a validator API that works with concurrent queries on the
existing DNS.

So really we should be trying to make that work first, since it has a much
more compelling deployment story.

And if well-informed engineering makes it clear that the existing DNS
can't reliably handle 6 ish concurrent queries, then maybe it's time to
think about upgrading everything with a new protocol feature.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8. Rough or very
rough, becoming very rough or high. Occasional rain. Good, occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Nov 2015 15:15:24 -0800

On Wednesday, November 11, 2015 10:01:51 PM Tony Finch wrote:
> have at most one query outstanding at any time.

there has to be a limit. i think we agree on that much. you must know that from the earliest 
days after i took over BIND from UCB/CSRG, it has limited the number of transactions it 
would initiate to any given server, and also the number of transactions it would initiate at 
one time, overall. the first limit is because the other end has buffers. the second limit is 
because my cpu is faster than my LAN which is faster than my WAN.

to meet the "has to be a limit" constraint, we use receive clocking. when the other end 
sends us a packet, that's our signal that we can send one or more packets. if the other end 
can send us a window size (as TCP can) then we might send more than one packet. if not, 
then we have to guess how many packets we can send in that "clock cycle". a stub should, 
unless it has better information, choose the lowest non-zero number available, that being 
one.

"better information" might be the result of new research for estimating available BDP 
between DNS initiators and responders. you're welcome to start that research. i'd love to 
consult with you and help you evaluate alternatives and results.

"better information" might be to aggregate all of the outbound stub flows through some 
local proxy, in which case the answer could be that not all stub flows can run at full (one 
or more transactions per clock cycle) rate, because some finite limit is shared by more than 
one flow, which then take turns in some way.

i hope that clears up what i meant by "at most one transaction outstanding per flow".

> If you say TCP is OK, you

your reasoning is nonsequitur. DNS initiators do indeed have more than one concurrent 
transaction at a time, and always have had. however, there is and always has necessarily 
been a limit to the number of transactions per flow. in DNS terms, a flow is a work unit. for 
example, a transaction in progress on the downstream side.

so, i didn't forbid the thing you were afraid i was forbidding. rather, i'm saying that if a 
gethostbyaddr() call for an IPv6 call needs up to 16 DNSKEY and DS RRsets, it is not 
acceptable to send 16 concurrent DS queries and 16 concurrent DNSKEY requests. i'm 
saying that there is no other way to compress the arbitrary amount of work needed to do 
DNSSEC stub validation into a single RTT except to either rely on TCP (which serializes the 
requests and allows the responses to come in any order) or change the protocol to allow 
"chain" queries.

if you'd like this draft changed to reference the tcp negotiation draft now in progress, and 
to say, if the stub can successfully negotiate with the RDNS to keep a tcp session open, 
then serializing the requests over TCP is a reasonable alternative to chain queries, then i 
would have no objections.

> (adns's concurrency control is quite simplistic, for example.)

BIND's concurrency also works. but all the ADNS-speaking agents on a single "host" do 
not currently share uplink capacity/response metrics. so, you are rationalizing extensively 
here -- making your data fit your conclusions.

the onus of proof is on she who asserts the possible. so, since you agree that there must be 
some limit, it's up to you to show that there is a respected limit in the many-labels case, 
for common configurations, including ADNS. i see no reason to expect such a limit to be 
respected currently, and so i'm saying, the just-send-everything-at-once approach is 
unworkable for UDP/53.

---

From: "Wiley, Glen" <[email-masked]>
Date: Thu, 12 Nov 2015 16:25:32 +0000

On 11/11/15, 5:01 PM, "Tony Finch" <[email-masked]> wrote:

>> > > i have no objection to multiple parallel outstanding upstream
>>queries
>> > > over a TCP stream.
>> >
>> > Why is TCP special?
>>

Another way to read the message of edns-chain-query is: DNSSEC has many use
cases and operation implications.  If you would like an alternate path
that may reduce latency under some conditions but not compromise the
security of the query/response here is one way to tackle it.

>"validate this RRset please" and then wait for a dozen RTTs.

At this stage there aren¹t widely deployed validating stub resolvers.
This is
true of new technology in general - I don¹t think the bar for improvements
should be ³has this already been implemented?²

There are some budding ideas and implementations out there, but any
support 
for DNSSEC on the client/host currently requires changes to the host APIs.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Nov 2015 01:40:38 -0500 (EST)

> I've read this document and think it proposes a useful capability.

Thanks for your feedback Shumon! (I think you read -03 and not -04)

> also in the new draft-ietf-dnsop-dns-terminology document.

I've changed the text to:

             This document defines an EDNS0 extension that can be used
             by a security-aware validating Resolver configured to use
             a Forwarder to send a single query, requesting a complete
             validation path along with the regular query answer.

(the text was already somewhat changed from before)

> you mean a fully qualified domain name in DNS wire format.

Done.

> should probably be reworded.

Added:

 	The added RRsets MAY be added in matching hierarchical
 	order but a DNS client MUST NOT depend on the order of the
 	added RRsets for validation.

> What is the expected behavior if the requestor sets the CD bit?

Text changed to:

             A DNS query that contains the CHAIN option MUST also have
              the DNSSEC OK ("OK") bit set. If this bit is not set,
              or if the Checking Disabled ("CD") bit is set, the CHAIN
              option received MUST be ignored.

> NS RRset of the zone containing the queried name?

The NS RRset lives at the child (authoritative and signed) and at the
parent (unsigned glue). We want the signed set, not the unsigned set. I've
changed the text.

> current format of a sequence of RRsets (a discussion that is happening

Okay, I've reworded it and loosened the MUST to a SHOULD unless space considerations
are important:

            CHAIN responses SHOULD include the NS RRset from the zone itself
            including the RRSIG records required for validation. It MUST
            NOT include the NS RRset from parent zone, as this RRset is
            not signed. If the size of the answer is an important factor,
            the NS RRset MAY be omited.

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 18 Nov 2015 01:59:15 -0500

The time for the WGLC has ended, and while there is some contention, 
there is also rough consensus to move this document forward. I will 
point the IESG to the mail thread about the issue Tony raised in the 
shepherd writeup.

IANA and given chain-query the EDNS Option Code of 13.

Paul has updated the draft with this and addressed the issues Mark and 
Shumon.  I'm finishing the writeup and this will go forward shortly.

thanks everyone for comments and reviews.
tim