Subject: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive

From: Tim Wicinski <[email-masked]>
Date: Tue, 07 Oct 2014 13:27:40 -0400

All

We have two drafts expiring shortly and I wanted to get the sense of the 
working group.

These are the two EDNS extensions worked on by Mr. Paul Wouters.  They 
initially had no home, and we gave them a home, and there was a lot of 
discussion around them, and paul turned these documents several times to 
address issues.

DNSOP went and got their charter changed, to address work like this. 
Since then we've had no discussion on them. However, I am confident that 
the previous rounds gave these documents a strong vetting. They have 
been adopted as working group documents some time ago.

The documents are:

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

https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/

I have thought about tbis and the opinion of this chair is that they are 
actually ready for a WGLC round and we pick up some shepherds and 
editoring and move them down the road.  Before I did this, I wanted to 
take the temperature of the group, and see if there are any issues with
moving forward.

thanks
tim

---

From: Evan Hunt <[email-masked]>
Date: Tue, 7 Oct 2014 19:31:37 +0000

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/

I support both, and will review if needed.

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

---

From: Ray Bellis <[email-masked]>
Date: Wed, 8 Oct 2014 08:21:41 +0000

On 7 Oct 2014, at 18:27, Tim Wicinski <[email-masked]> wrote:

> All
> 
> We have two drafts expiring shortly and I wanted to get the sense of the working group.
> 
> These are the two EDNS extensions worked on by Mr. Paul Wouters.  They initially had no home, and we gave them a home, and there was a lot of discussion around them, and paul turned these documents several times to address issues.
> 
> DNSOP went and got their charter changed, to address work like this. Since then we've had no discussion on them. However, I am confident that the previous rounds gave these documents a strong vetting. They have been adopted as working group documents some time ago.
> 
> The documents are:
> 

I do NOT support adoption of edns-tcp-keepalive.

It appears to be a solution for a problem that does not exist, based on a misunderstanding of how TCP clients and servers are already supposed to interact and a misrepresentation of the recommended shortening of the standard timeout for TCP sessions that happened in RFC 5966.

The latter is mentioned in the abstract where the draft asserts this makes "making use of TCP only suitable for individual queries generated as a fallback protocol for truncated UDP answers”.  This assertion is not supported (or even mentioned) anywhere else in the text.

Like HTTP/1.1, DNS over TCP sessions should _already_ be considered persistent, albeit with shorter timeouts since RFC 5966  (I see that Apache 2.2 uses a 5 second timeout).  There’s no need to use an option to ask for it, nor IMHO any need for the value of the timeout to be communicated between client and server (or vice versa).

There’s a small group of us that are looking at an update to 5966 to reflect lessons learnt since that was published in August ’10 and to propose further clarifications.  On discussion with one of that group a few days ago the primary missing feature I could see relating to socket handling in TCP over DNS was an analogue of the HTTP/1.1 “Connection: close” flag from server to client - in effect the server asking the client nicely to close the connection from its end.  This puts the TCP TIME_WAIT burden on the client instead of the server and could be trivially accomplished with a single bit flag in the EDNS flags.

kind regards,

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 8 Oct 2014 08:38:46 +0000

> I do NOT support adoption of edns-tcp-keepalive.

Ah, I see that particular horse has already bolted.  

My comments still stand, though.  I do not believe this option is useful, or required.

Ray

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Oct 2014 10:35:31 +0100

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

I do not think this protocol extension is necessary.

I have previously described how you can get the same round-trip
performance by sending queries for all the chain records at once:
http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html

The performance problem that EDNS chain queries are trying to fix is an
problem with existing server implementations, NOT a protocol limitation.
Both BIND and Unbound fail to handle queries concurrently when they arrive
over one TCP connection.

It would be much better to spend time working on fixing these bugs instead
of adding complexity to the protocol.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 8 Oct 2014 10:07:51 +0000

> Both BIND and Unbound fail to handle queries concurrently when they arrive

This is one of the issues to be addressed in 5966-bis - specifying that TCP queries should not be processed serially causing "head of queue" blocking.

kind regards,

Ray

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Oct 2014 09:34:43 -0400 (EDT)

> http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html

That doesn't help a stub resolver much. Do you really want the resolver
logic of gathering all this data in asynchronous queries to be in libc?

> Both BIND and Unbound fail to handle queries concurrently when they arrive

this extension allows a significant resource saving when used on mobile
phones.

> of adding complexity to the protocol.

What is the complexity? It's not introducing any new formats, no new
record types, and just an edns option you can ignore if you don't want
it? The complexity is in the upstream resolver picking up all the right
entries. The client is clean and simple. Send one packet, get a nicely
validatable answer back.

Paul

---

From: Simon Perreault <[email-masked]>
Date: Wed, 8 Oct 2014 09:42:05 -0400

> logic of gathering all this data in asynchronous queries to be in libc?

Why not? Check out OpenBSD's libc. It contains a fully asynchronous
resolver. The standard APIs are simply wrappers around their non-standard
async counterparts. Overall I find it much cleaner and simpler than glibc's.

The point is: asynchronism does not necessarily imply complexity.

Simon

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Oct 2014 09:51:09 -0400 (EDT)

> It appears to be a solution for a problem that does not exist, based on a misunderstanding of how TCP clients and servers are already supposed to interact and a misrepresentation of the recommended…

I agree. We investigated and we found that it was not needed to detect
bad broken TCP. But then some other people wanted this extension for
better determining of load on DNS servers, and they said they would like
this document to continue.

So the original reason is indeed not needed. We could expand on the
second reason in the draft, or drop the draft if there is no one
left who wants it.

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Oct 2014 15:19:40 +0100

> logic of gathering all this data in asynchronous queries to be in libc?

You don't need any asynchronous code to send concurrent queries. If you
are using a TCP socket you don't even need to select(). Just write out the
queries then read the replies.

(You only need to go async if you want to be concurrent with other
activity in the program, in which case it isn't relevant to compare with
the non-async libc resolver.)

> this extension allows a significant resource saving when used on mobile

Yes, I pointed that out in the article linked above. But EDNS chain
queries only reduce the data sent and received, not the number of round
trips. The maximum number of round trips required is two, with or without
EDNS chain queries.

Note that the numbers I was working with did not include NS RRsets. If you
add those in as required for EDNS chain queries, then I guess you will not
actually be winning.

Perhaps a more useful option would be to request minimal responses.

> entries. The client is clean and simple. Send one packet, get a nicely

The client needs to negotiate support and keep track of which servers
provide it or not.

The EDNS chain query option doesn't include enough information for the
server to optimize its response correctly if the answer is a CNAME or MX
etc. to a different zone (e.g. under a different TLD).

It isn't clear to me if including NS records in the response makes sense
as the default behaviour. Maybe it does for roaming clients (like Unbound
/ DNSSEC-trigger) that switch back and forth between forwarding and
iterative resolution, but if you have a forwarding-only resolver it is
just waste. You could make it optional - or you could just remove the
feature and if the client wants NS records it can ask for them using a
separate query.

But all of these questions disappear, and you get negligible loss of
performance, if the client sends concurrent queries for just the records
it needs.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Oct 2014 11:11:57 -0400 (EDT)

> trips. The maximum number of round trips required is two, with or without

If you keep the TCP connection open, for chain query it would be a
maximum of one round trip. I am not sure how you are saying you can do
all the work in parallel, when you do not know beforehand how many CNAME
or DNAME contstruct will appear in your queries and when you have no
cache other then the root key. Unless you are going to break up on every
dot and send all those packets in parallel.

> add those in as required for EDNS chain queries, then I guess you will not

I do not understand this at all? Can you clarify? As chain queries give
you all the required validation data in one round trip, how will you do
the same without sending an excessive amount of queries and then still
needing so send another wave of those if there is a CNAME/DNAME? How
would you break even accomplishing 1 RTT (assuming that when you say
"win" you don't mean less than 1 RTT :)

> The client needs to negotiate support and keep track of which servers

On the stub, the client would use the assigned forwarders only. So it
just needs to remember if its current one or two resolvers support this
or not.

> etc. to a different zone (e.g. under a different TLD).

I think it does. It can add the required records in the additional
section so that the dns answer packet contains all the components
required for validation.

> just waste.

That is something we could discuss. It might be that the gains for NS
records are not worth it. I am not sure yet either way.

> You could make it optional - or you could just remove the

In the case of the caching itterative resolver, that might make sense.

> performance, if the client sends concurrent queries for just the records

See above. I disagree that rapid-fire is desirable over sending a single
query. And I did not yet see how you can achieve this in roughly 1 RTT.

Additionally, those that prefer rapid-fire can already do so and not use
query-chain.

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Oct 2014 16:47:51 +0100

> dot and send all those packets in parallel.

Yes exactly, as I explained in my article from last October.

Note that when you get a response involving a CNAME from a recursive
server, you get the whole CNAME chain, so you can get all the validation
chains in a second round trip.

EDNS chain queries also require this second round trip, unless they waste
space by eagerly sending all the CNAME validation chains in the first
response. But if you send them eagerly you are wasting radio time and
battery charge if the client has them in its cache.

> I do not understand this at all? Can you clarify?

See the numbers in my previous article. The savings from EDNS chain query
were quite large in my example because I chose a deeply nested domain with
some non-zone-cut labels. If you have a domain of a more common length and
you pad the response with NS RRsets then I doubt EDNS chain queries will
save much compared to concurrent standard queries.

> section so that the dns answer packet contains all the components

When I say "not enough information" I mean the "last known" name isn't
enough for the server to both eliminate wasted validation chains and
eliminate second round trips.

Say I visit www.ietf.org, and I send an EDNS chain query with a "last
known" name of org. The server can either send back just the DS+DNSKEY
for ietf.org, or it can also include the whole validation chain for
cdn.cloudflare.net.

If it sends the short response, I might need to send another query to get
Cloudflare's validation chain. If it sends the long response it might be
wasted effort if I already have it cached.

There is no way I can anticipate what the target of the CNAME is, so
there's nothing useful I can add to the EDNS chain query to avoid the
wasted effort. There is no way the server can anticipate what is in my
cache so it can't avoid sending too little or too much data.

> Additionally, those that prefer rapid-fire can already do so and not use

Exactly.

Tony.

---

From: David C Lawrence <[email-masked]>
Date: Wed, 8 Oct 2014 16:07:21 -0400

Ray Bellis <[email-masked]>:
> It appears to be a solution for a problem that does not exist, based on a
> misunderstanding of how TCP clients and servers are already supposed to
> interact and a misrepresentation of the recommended shortening of the
> standard timeout for TCP sessions that happened in RFC 5966.

I support the draft, and I'm not coming from the position of
"misunderstanding of how TCP clients and servers are already supposed
to interact".  I am very clear on the current spec.  It is just
preferable to me that the TCP session behaviour be negotiated.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 9 Oct 2014 12:39:37 +0000

On 8 Oct 2014, at 21:07, David C Lawrence <[email-masked]> wrote:

> It is just preferable to me that the TCP session behaviour be negotiated.

Can you please elaborate?

What particular benefits do you anticipate arising from such a negotiation?

kind regards,

Ray