Subject: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd)

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Oct 2013 16:24:26 -0400 (EDT)

This is the 01 version for edns-tcp-chain-query-01

- Moved TCP Keep-alive into a separate document
- Allow edns-tcp-chain-query discovery over UDP
- Clarify CNAME / DNAME 
- Cleanup of text.

Paul

-------- Original Message --------
From: [email-masked]
To: Paul Wouters <[email-masked]>
Subject: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt
Date: Tue, 15 Oct 2013 10:21:52 -0700

A new version of I-D, draft-wouters-edns-tcp-chain-query-01.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Filename:	 draft-wouters-edns-tcp-chain-query
Revision:	 01
Title:		 TCP chain query requests in DNS
Creation date:	 2013-10-15
Group:		 Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-chain-query-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query
Htmlized:        http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-wouters-edns-tcp-chain-query-01

Abstract:
    This document defines an EDNS0 extension that can be used by a DNSSEC
    enabled Recursive Nameserver configured as a forwarder to send a
    single query over TCP requesting to receive a complete validation
    path along with the regular query answer.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Finch <[email-masked]>
Date: Sat, 19 Oct 2013 18:00:36 +0100

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-masked]>  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.

---

From: Tony Finch <[email-masked]>
Date: Sat, 19 Oct 2013 20:47:36 +0100

Tony Finch <[email-masked]> wrote:

Sorry, there was an error in my calculations.

> save 2349 bytes, for a total of 4219 bytes of reply.

The RRSIG only proves the nonexistence of the DNSKEY and DS records. We
need the NSEC to prove the nonexistence of the AAAA record. And the A and
AAAA queries have to be separate, so the AAAA response should be a full
NODATA response. So we only save 1872 bytes and the total is 4694 bytes.

> another 430 bytes, reducing the total to 3789 bytes.

Actually 4264 which is 55% of the original.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Oct 2013 22:29:37 -0400 (EDT)

On Sat, 19 Oct 2013, Tony Finch wrote:

> This feature could be hugely beneficial

Great, I think so too :)

> RTTs without edns-tcp-chain-query.

There is not much they can do to fix it if I'm using a phone over 3g
with a validator on the phone.

> Nameserver" is peculiar and isn't defined in the terminology section.

Thanks will look into that.

> data sent and received to get a validation chain.

I figure when it comes to bytes send/received, if DNS is your issue you
have bigger problems with what's asking the DNS questions. It's nice to
reduce the size if we can, but I don't think there is much impact with
reduced size?

> That's about half a second of data at GPRS speeds.

Well, I guess it you meassure at GPRS speeds.... :)

> Name.

I was avoiding that because the client does not know what it doesn't
know. There might not be zone cuts on every dot. Which is why I opted
for it to convey that it did know.

> In the empty cache case, the client only has a root trust anchor so

Yes. Was this not clear in the draft?

> addreses of the authoritative servers. Those are only useful for direct

Because roaming devices run the risk of changing to a network where they
have to operate without forwarder. In which case it would be really nice
to already have those NS records validated and ready. It seemed like an
optimization that might cause more problems than it solves.

> include the MX target RRs in the additional section.

I guess that depends on how the resolver is configured. unbound seems to
be minimal responses, while my old named seems to add it A records to
the additional section. So I think that would be out of scope for this
draft, but perhaps a mention that it would be recommended not to
configure resolvers with minimum responses (unlike authoritative
servers?)

> already have example.net in my cache. (There's a similar problem for CNAME

I don't think there is a principle reason why not to add those to the
additional section. In fact, I had thought about a special query that
would signal to the upstream resolver "give me your 1% hot cache
entries with a TTL of more then 5 minutes".

> trip to deal with the targets if the cache isn't populated?

right. so we can either make an option, or not optimize here.

I'd say that MX is not that important because it is not very interactive
(but a background process) and that CNAME/DNAME could be avoided if
people cared about the extra 1 RTT for the followup (TCP keepalive) query.

> domain, then the client might have to send a follow-up query.

I think that's what Jelte was hinting at too. I think I'll try to write
this up for the next version. It covers a quite common case, and without
the risk of needing to include a whole new hierarchy of which we don't
know if the client knows it or not.

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

I can tone it down a bit and just state implementors should be careful.

> will compress nicely since it is a parent of the QNAME)

You are right, will fix in next draft.

thanks for the feedback!

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Oct 2013 10:32:43 +0100

> with a validator on the phone.

If they care about latency they should send all the necessary queries at
once, as in the example I posted. It seems to me that edns-chain-query is
just a more concise way to express this basic strategy. A client that is
adapted to use edns-chain-query can equally well be adapted to make
equivalent concurrent queries.

That is, whenever you would like to send an edns-chain-query, you can get
roughly the same latency if you send the basic query and at the same time
send queries for DS and DNSKEY for every domain name from your QNAME to
its topmost uncached parent domain.

So I think the draft should be more clear about the benefits of this
protocol change, relative to the backwards-compatible concurrent query
strategy. I say "roughly" above since the option might allow you to save
the second round trip for validating out-of-zone CNAME targets.

> for it to convey that it did know.

If the client is querying for www.example.com and it knows com, and it
knows it doesn't know example.com, it should put example.com in the
option. It doesn't matter if that is a zone cut or not.

> Yes. Was this not clear in the draft?

But as currently written, the client will not get the . DNSKEY RRset,
because the option says it knows the root. If it only has a trust anchor,
not the complete . DNSKEY RRset, it won't be able to validate the TLD DS
record. It will have to make a separate query for the . DNSKEY RRset.

If you change it to be the last unknown domain name, then this problem
goes away.

> optimization that might cause more problems than it solves.

Oh, that makes sense. It would be helpful to have that rationale in the
NS record considerations section of the draft.

And now to additional validation chains outside the client's last known
name...

> entries with a TTL of more then 5 minutes".

Sounds like a self-ddos option to me :-)

> people cared about the extra 1 RTT for the followup (TCP keepalive) query.

Note that (when comparing with clients that don't use this option and just
send all the necessary queries at once) this second RTT for CNAME
validation is the one that the option can eliminate.

> know if the client knows it or not.

Cool.

I still have a nagging question if there is a better way to eliminate
more of these follow-up queries.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Oct 2013 10:48:05 -0400 (EDT)

On Tue, 22 Oct 2013, Tony Finch wrote:

> once, as in the example I posted.

But you mostly cannot know. There is not much quering all possible zone
cuts of a.b.c.d.e.fg.h.i.j.k.l.com if the nameserver of l.com is
ns1.nohats.ca.

Now if l.com's NS records are ns1.nohats.ca, than sure we could add the
relatively small stuff for .ca and nohats.ca. to the additional section
as well. The question is where do you draw the line? I think latency is
a little more important than saving a few bytes, so I'd rather get some
redundant data. Can we leave that decision as a local policy, analogue
to a 'minimal responses' switch ?

> It seems to me that edns-chain-query is

But when you are hammering all imaginary zone cuts, and you really
needed .ca, that seems overly aggressive to me. The client does not have
a good idea what to ask. The server does have a good idea of what it
should return. Therefor I think the client should simply ask what it
wants to know, and the server should think about sending additional
data to satisfy the original question.

> strategy.

I'll try and write something up. But I hope the above explanation makes
sense to you?

> option. It doesn't matter if that is a zone cut or not.

What if it does know example.com, just not www.example.com. It puts in
www.example.com? And what is "knowing" with regard to RRtype? It might
not "know" something because it does not exist. I prefer chaining the
question to something we know exists.

> If you change it to be the last unknown domain name, then this problem

I see. That's true. Let me think on this a bit more. I'm not sure if
this one corner case is important enough to matter. Let's see what
others have to say about this?

> NS record considerations section of the draft.

Will do.

> more of these follow-up queries.

We should probably take a look at some common resolves (on phones) and
see what dns data we currently have. google for instance has straight A
records for gmail.com but CNAMEs for mail.google.com.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Oct 2013 16:24:00 +0100

Paul Wouters <[email-masked]> wrote:
> needed .ca, that seems overly aggressive to me.

Even though in the majority of cases you'll only make a couple of
redundant queries?

I thought we weren't trying to save bandwidth :-)

> www.example.com?

Right, since www.example.com might be a zone cut. And if it knows
www.example.com there is no need for the option.

> And what is "knowing" with regard to RRtype?

Not my choice of word! And we're concerned with the ability to validate
any RRset at a name, which is independent of the RRtype.

> It might not "know" something because it does not exist.

It will either know nothing since it has nothing in the cache or know it
has a negative cache entry or know it has a cached proof of insecurity.

Tony.

---

From: Marc Lampo <[email-masked]>
Date: Wed, 23 Oct 2013 15:31:59 +0200

Hello,

excuse me if I am uneasy with this proposed way of working.

I think there are several more aspects that need a more precise description.
Some of the aspects listed hereafter, but I cannot claim completeness.

Hopefully mentioning these points will allow to correct/complete the draft.

First off :
I remember a presentation of Cricket Liu, author of DNS & Bind, Infoblox,
where the overhead of DNSSEC overall is not dramatic.
The very first time, when a cache is emtpy, several queries are needed
of course, but the answers are cached and may not need to be queried for
afterwards (for as long as they live in the cache).

So, probably the first DNS query with tcp-chain saves overhead/bytes/RTT,
but does the gain persist afterwards ?
Staying with the first example, 9.1, Simple query for example.com.

 Suppose this query, for www.example.com.,
 is followed by a second query for the MX record of example.com.

 After the first query, with or without tcp-chain-query, the forwarder
 will have the DNSKEY(s) of example.com. loaded in its cache.
 So :
 with tcp-chain-query, the query for the MX records, would specify
  "example.com." as last known query name.
 without tcp-chain-query, the query for the MX records would not be followed
  by any subsequent query (because the required DNSKEY info is already
there)

I would propose that more examples are provided,
not to focus exclusively on a "first query when the cache is empty".

When calculating the gain, the numbers for a second query should be
considered as well.

With respect to proposal in the draft :
1) In its present version, there are several references about
   a forwarder that sends queries with this tcp-chain-query option,
   a recursive resolver that responds with the tcp-chain-query option.

   But what with a tcp-chain-query to an authoritative name server ?
    (or : a name server authoritative for some, caching for all others)
   What with a tcp-chain-query to a forwarder itself ?

2) Without the tcp-chain-query option, it is hardly possible to
   create a DNS query packet larger than 512 bytes.
   (at least I would not know how :
    header + 1 name to query for (max 256 bytes) + EDNS0
    cannot be larger than 512 bytes, can it ?)

   But with the tcp-chain-query option, this changes.
   As the draft states, in 4 Option Format, that no compression is allowed
   in the Last Known Query Name,
   an attacker could create a query with two max length domain names,
   resulting in a "valid" query, > 512 bytes,
   to name servers that may not be tcp-chain-query aware
   and expecting no queries exceeding 512 bytes.

   I think this is worth mentioning in the security section of the draft.

3) I'm puzzled with the numerous records that can be returned
   and them being in the proper sections
   (no offense meant, Olafur, I just don't see it yet)

   Without tcp-chain-request, a query for www.example.com
   (assuming there is only an A RRset for it)
   will yield :
   Answer section : www.example.com. A RRset
                    www.example.com. RRSIG over A RRset
   A second query is needed for the DNSKEy of example.com.
   It will yield :
   Answer section : example.com. DNSKEY RRset
                    example.com. RRSIG over DNSKEY RRset
   A third query is needed for the DS record of example.com.
   Resulting in :
   Answer section : example.com. DS RRset
                    example.com. RRSIG over DS RRset
   ...

   The first paragraph of 5.3 Generating a Response states :
   "It extends the
   Authority Section for the DNS answer packet with the required DNS
   RRSets resulting in an Authority Section that contains a complete
   chain of DNS RRsets that start with the first chain element below the
   received Last Known Query Name upto and including the NS and DS
   RRsets that represent the zone cut (authoritative servers) of the
   QNAME."

   ? does this mean that all DNSKEY and DS information and there RRSIGs
     are expected in the authority section of the answer ?
     (which is a different section than if queried for separately)

   Perhaps it is only a matter of rephrasing ...

4) The one before last paragraph of 5.3 Generating a Response
   addresses CNAMEs

   Without tcp-chain-request, when a forwarder asks a resolver,
   recursive query, for a name that is turns out to be a CNAME,
   the resolver returns both the CNAME and the address it points at :
$ dig @<-resolver-ip-> www.hotmail.com. +recurse +short
dispatch.kahuna.glbdns2.microsoft.com.
157.55.0.137
157.55.0.139
   So, 1 query, 1 answer that has it all.

   But the one before last paragraph of 5.3 states :
   "It MUST NOT follow the CNAME ..."
   Thus this mean the forwarder will have to ask a second question,
   if using tcp-chain-request ?

   My feeling is this is an important change in the behaviour.
   (but I understand the author is hesitant as well, about this paragraph)

   (no comment of mine on DNAME, I am not qualified for that).

Kind regards,

Marc Lampo

On Tue, Oct 15, 2013 at 10:24 PM, Paul Wouters <[email-masked]> wrote:

> - Clarify CNAME / DNAME - Cleanup of text.
>
> Paul
>
>
> Subject: New Version Notification for draft-wouters-edns-tcp-chain-**
> query-01.txt
> A new version of I-D, draft-wouters-edns-tcp-chain-**query-01.txt
> Filename:        draft-wouters-edns-tcp-chain-**query
> Revision:        01
> URL:             http://www.ietf.org/internet-**
> drafts/draft-wouters-edns-tcp-**chain-query-01.txt<http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-chain-query-01.txt>
> Status:          http://datatracker.ietf.org/**doc/draft-wouters-edns-tcp-
> **chain-query<http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query>
> Htmlized:        http://tools.ietf.org/html/**
> draft-wouters-edns-tcp-chain-**query-01<http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-01>
> Diff:            http://www.ietf.org/rfcdiff?**
> url2=draft-wouters-edns-tcp-**chain-query-01<http://www.ietf.org/rfcdiff?url2=draft-wouters-edns-tcp-chain-query-01>
>
> Abstract:
> ______________________________**_________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dnsext<https://www.ietf.org/mailman/listinfo/dnsext>
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Oct 2013 10:32:18 -0400 (EDT)

> afterwards (for as long as they live in the cache).

That is true for a dnssec resolver on the internet core, but not for a
dnssec resolver on a handheld device where latency is very high.

Organisation such as google don't like DNSSEC because of two reasons:
1) they dont trust port 53 is clean enough
    (they rolled out Google DNS)
2) Every RTT matters, and DNSSEC adds too many
    (google experiments with dnssec chains in X.509 attributes that come
     into the browser via TLS without extra RTTs)

This draft is attempting to solve 2) by keeping DNS in DNS

>   by any subsequent query (because the required DNSKEY info is already there)

It's not the gain so much for querying multiple records of the same
QNAME. It's a web page with 20 different QNAMEs all using their own set
of NS records, DNSKEY/DS records and A/AAAA records, where often the
A/AAAA records are different from the NS/DS records, requiring a broad
spectrum of queries to resolve.

> not to focus exclusively on a "first query when the cache is empty".

Sure. I will look at making the examples section more clear.

> When calculating the gain, the numbers for a second query should be

I hope I explained above that it is not so much about queries for
different RRtypes of the same QNAME.

>    What with a tcp-chain-query to a forwarder itself ?

Authoritative servers do not contain the information to form query
chains. They are expected to return REFUSED. I will clarify that
in the text.

>    I think this is worth mentioning in the security section of the draft.

That's certainly worth mentioning. Perhaps we should state that a chain
query should never exceed a certain length.

>      (which is a different section than if queried for separately)

Correct. Like traditional DNS queries, the answer to the QNAME/QTYPE
appears in the Answer Section. Supporting records for that answer go
into the Authority Section. (And possibly CNAME/DNAME following should
go in the Additional Section)

>    Perhaps it is only a matter of rephrasing ...

I will see about clarifying it further.

> dispatch.kahuna.glbdns2.microsoft.com.

See the other thread regarding CNAMEs. We are still discussing what the
best behaviour would be. The issue with returning anything about where
the CNAME points to, is that it could be an entirely different branch in
the DNS hierarchy - the answering server has no "Last Known Query Name"
to know what part of that second chain to return. One suggestion has
been to return it only when it falls within the requested chain.

Regards,

Paul

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Oct 2013 13:17:35 -0700

At Tue, 15 Oct 2013 16:24:26 -0400 (EDT),

> This is the 01 version for edns-tcp-chain-query-01

I have a couple of minor comments:

- In section 9.1, item #10:
        [...]  If it is a DNSSEC validating
        resolver, it ensures that no unvalidated data or out of baliwick
        data is accepted into the cache without having proper DNSSEC
        validation.
  I'm afraid "out of ba(i)liwick" is a bit unclear in this context
  regarding bailiwick against what.

- very minor nit: I suggest using "DNS message(s)" instead of DNS
  packet(s) throughout the draft, because "message" seems to be the
  more appropriate technical term per RFC 1035, and because "packet"
  can be ambiguous and in the general sense would normally be
  interpreted as individual IP packets.  I don't think such possible
  confusion is critical for the discussion of this draft, but if we
  can avoid it by simply replacing a word with another one, it should
  be worthwhile.

--
JINMEI, Tatuya