Re: Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd)

This feature could be hugely beneficial - see below for some numbers.

I think it is worth being more clear about what is possible without this
draft both in principle and separately in practice.

The first paragraph of section 3 is saying that in practice, validating
resolvers (BIND, Unbound) are not currently optimized to minimize latency.
This ought to be fixed, but it does not imply that you have to suffer many
RTTs without edns-tcp-chain-query.

Editorial suggestions: I think section 1 and section 3 are doing basically
the same job and should be merged into one section. The term "Resolving
Nameserver" is peculiar and isn't defined in the terminology section.

In principle you can send all the queries and get all the responses needed
for validation in one RTT, or two if the answer contains a CNAME chain,
because you need the validation chain for the CNAME targets and you don't
know the targets until you get the response. So I think the key benefit of
edns-tcp-chain-query is not so much latency, but reducing the amount of
data sent and received to get a validation chain. (It turns out to be
difficult to completely eliminate the second RTT in the CNAME case; more
on that below.)

Perhaps it is worth calculating how much data could be saved. Let's use
webmail.hermes.cam.ac.uk as an example since it should make
edns-tcp-chain-query look really good :-) Given an empty cache, to look it
up and get the validation chain, a stub would query for:

webmail.hermes.cam.ac.uk. IN A
webmail.hermes.cam.ac.uk. IN AAAA
webmail.hermes.cam.ac.uk. IN DNSKEY
webmail.hermes.cam.ac.uk. IN DS
        hermes.cam.ac.uk. IN DNSKEY
        hermes.cam.ac.uk. IN DS
               cam.ac.uk. IN DNSKEY
               cam.ac.uk. IN DS
                   ac.uk. IN DNSKEY
                   ac.uk. IN DS
                      uk. IN DNSKEY
                      uk. IN DS
                        . IN DNSKEY

Which is 536 bytes sent in 13 queries. Our campus resolvers return 7826
bytes of UDP response to these queries. My resolver configured for minimal
responses only reduces this to 6568 bytes by omitting the additional
gubbins in the first response. That's about half a second of data at GPRS
speeds.

Those numbers come from the following script. I have patched dig to print
the query size: https://github.com/fanf2/bind-9/commit/b1d6fc85

h=webmail.hermes.cam.ac.uk.
s=127.0.0.1
(	dig +dnssec +noall +qr +stats @$s $h IN A $h IN AAAA;
	while [ "$h" != "" ];
	do	dig +dnssec +noall +qr +stats @$s $h IN DNSKEY $h IN DS;
		h=${h#*.};
	done;
	dig +dnssec +noall +qr +stats @$s . IN DNSKEY
) | grep SIZE

A lot of these are NODATA responses, the 2nd to 6th queries inclusive.
These responses are entirely redundant, since the RRSIG in the A response
indicates there is no AAAA and the nearest enclosing zone cut is cam.ac.uk
below which there are no DNSKEY nor DS records. Leaving those out would
save 2349 bytes, for a total of 4219 bytes of reply.

The remaining redundancy that edns-chain-query would eliminate is the
repetetive headers and OPT RRs. I think (without having checked in detail)
that this saves from the response the same amount of data as all but two
of the queries. (The first two queries still need to be separate; the
client would send one with the chain option and one without.) This saves
another 430 bytes, reducing the total to 3789 bytes.

That is less than half the original.

On the query side, we now only need to send queries for A and AAAA, and
include the edns-chain option in one of them, making 111 bytes which is
about 20% of the original.

Some more suggestions and questions ...

Section 5.2 generating a query:

I think the Last Known Query Name needs to be the First Unknown Query
Name. In the empty cache case, the client only has a root trust anchor so
it needs the root DNSKEY RRset. So when it sends . in the edns-chain-query
option it wants to get everything up to and including the root.

Section 5.3 generating a response:

Why include the NS RRsets? The client is making forwarding queries to an
upstream recursive server, so it doesn't need to know the names or
addreses of the authoritative servers. Those are only useful for direct
iterative resolving.

I think more needs to be said about additional section processing. It
seems sensible to me to do additional section processing only for direct
answers to the client's query, not for the validation chain (i.e. omit the
NS RRsets and their targets). For instance if the client asks for the MX,
include the MX target RRs in the additional section.

What about the MX target validation chain(s)? If I query for example.ac.uk
and they have outsourced mail to example.net, I can put ac.uk in
edns-chain option, but I don't know in advance that the response will have
anything to say about example.net, and I can't tell the server that I
already have example.net in my cache. (There's a similar problem for CNAME
responses.)

So the server has a dilemma: include everything to ensure that the client
doesn't have to make any more queries, which is a waste of bandwidth if
the client's cache is populated, or make the client suffer another round
trip to deal with the targets if the cache isn't populated?

Perhaps it would make sense to send the validation chain for CNAME targets
and additional records only if the client's edns-chain domain is a parent
of the target. The server can then be sure it only sends records the
client does not have. If the targets are not under the client's edns-chain
domain, then the client might have to send a follow-up query.

Section 6.5 anycast considerations:

Again I think this is too pessimistic about the anycast and TCP.

Section 4 option format:

Why use the term FQDN? This is a domain name in wire format, right? (which
will compress nicely since it is a parent of the QNAME)

Tony.
-- 
f.anthony.n.finch  <[email protected]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext