Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-02.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 11:16:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Chain Query requests in DNS
        Author          : Paul Wouters
	Filename        : draft-ietf-dnsop-edns-chain-query-02.txt
	Pages           : 15
	Date            : 2015-03-09

Abstract:
   This document defines an EDNS0 extension that can be used by a
   security-aware validating Resolver configured as a Forwarder to send
   a single query, requesting a complete validation path along with the
   regular query answer.  The reduction in queries lowers the latency.
   This extension requries the use of source IP verified transport such
   as TCP or UDP with DNS-COOKIES so it cannot be abused in
   amplification attacks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-chain-query-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Mar 2015 18:52:03 +0000

The justification in the introduction is misleading:

   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.  This reduces the number of round-trip times ("RTT") to two.
   If combined with long livd TCP or [TCP-KEEPALIVE] there is only 1
   RTT.

Without this extension the typical number of RTTs required is 1, so this
isn't a reduction.

                                           There is also no guarantee
   that the initial set of UDP questions will result in all the records
   required for DNSSEC validation.  More round trips could be required
   depending on the resulting DNS answers.

With this extension you still require 2 RTT if the target is SRV or MX,
and maybe if it is CNAME or DNAME depending on how much the server decides
to return. Maybe it requires 3 RTT if the server decides it doesn't like
doing chain queries any more.

It occurs to me that you could get a lot of edns-chain-query's bandwidth
saving with a simple "minimal responses please" query flag.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: Southwest 5 to 7, occasionally gale 8 at first, becoming variable
4. Moderate or rough, becoming slight or moderate. Fair. Good.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 15:01:13 -0400 (EDT)

> Without this extension the typical number of RTTs required is 1, so this

When you have nothing of nohats.ca in your cache, and you ask for the
A record of www.nohats.ca, you will normally get back the A record
and the RRSIG. Then you need to query for the DS, DNSKEY, etc etc. And
then for the DS, DNSKEY et all of the parent, the parents parent, etc.
All of those require round trips. Yes you can blindly send a bunch of
parallel udp queries on every dot and hope the last one you need didn't
take too long or drop. Clearly this extension provides a more robust
way of doing this. The interface is clean, and you get all you need
in a single DNS packet.

> doing chain queries any more.

I'm happy to add a section of recommendations for adding common "related
records" such as IPSECKEY, TLSA, SSHFP or what not. It does mention
CNAME/DNAME and I'm happy to add an entry about SRV and MX. Would that
address your concerns?

> saving with a simple "minimal responses please" query flag.

This is not about bandwidth saving.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Mar 2015 10:32:45 +0000

Paul Wouters <[email-masked]> wrote:
> All of those require round trips.

No they do not. Please stop repeating this falsehood.

> Yes you can blindly send a bunch of parallel udp queries on every dot
> and hope the last one you need didn't take too long or drop.

Or you can use TCP and send the whole lot in a single packet.

In most cases the number of queries required is about the same number of
packets as a TCP initial window, so if your network can't cope with that
you are not going to have a happy time.

> CNAME/DNAME and I'm happy to add an entry about SRV and MX. Would that

Well, it would fix an omission.

There is also the question of how the server should decide whether to
include the target validation chain or not, and if that depends on whether
the target is under the last known name or not. Is it entirely at the
server's discretion?

> This is not about bandwidth saving.

But that is all it does.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Northwesterly backing southerly 6 to gale 8, occasionally
severe gale 9 later. Rough or very rough, becoming high or very high. Wintry
showers, rain later. Good, occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Mar 2015 10:58:06 -0400 (EDT)

On Tue, 10 Mar 2015, Tony Finch wrote:

Tony,

> No they do not. Please stop repeating this falsehood.

paul@bofh:~$ sudo unbound-control flush_zone nohats.ca
paul@bofh:~$ dig a +dnssec www.nohats.ca @127.0.0.1
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-16.P2.fc19 <<>> a +dnssec
www.nohats.ca @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60716
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.nohats.ca.			IN	A

;; ANSWER SECTION:
www.nohats.ca.		86400	IN	A	193.110.157.102
www.nohats.ca.		86400	IN	RRSIG	A 8 3 86400
20150318104211 20150304194202 29800 nohats.ca.
HrYIKv7AJE8XL7TihxgWEMtZGTJ7LEqxtXOJf3NCbG5vNdvtrusoQF+6
2ife0nc08FkDSypt8Xe9TbpyTrBg2HNwUx7XvVJs88IfWiK8tg8L6Kl6
aPMxvE8gvS2a4tjlrir041fMXZU4Ib3SCtqXftSCGkC9ZZASu6um2a4h
FIsri06hlzD7umgZadZbaPnia69GGYznfSkEQEhGCm16tIejfZYn14Nz
3Pc8oyZauhm4BpsyfnYnXRzVvBwUr2Etc89bJV5UYd5ErHJ0o2tfvO61
p+k+B3RnsunrbGM+jU05Nu8AjBMfJSv52WIbUp9JH9olwo1OVgyUf2UX 7tFgPg==

;; Query time: 148 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 10 10:47:45 EDT 2015
;; MSG SIZE  rcvd: 355

> Or you can use TCP and send the whole lot in a single packet.

Yes, that is what this draft recommends. Are you agreeing with me?

Without the EDNS option, how does the server decide whether or not to
say add the DS record for nohats.ca and the DS record for ca. ? Do
you suggest the server decides this without signaling from the client?
Should they above query have contained those DS records for every
request for www.nohats.ca ?

> you are not going to have a happy time.

Sending a number of queries, and then when finding out you are still
lacking some information, sending out another number of queries, is
not the same as sending 1 query and getting a dns answer packet back
that in itself completely validates. This can be used by any application
that does not want to rely on a DNSSEC validating server running on
localhost that only knows about the DNSSEC rootkey, to obtain a fully
validatable (and discardable) set of records for a particular query.
This is very much a desired feature on cloud and container deployments
where a container does not want to relay on the AD bit received outside
the container/VM and where running 10000 containers shouldn't require
running 10000 validating caching servers on a single piece of hardware.

> Well, it would fix an omission.

Should the draft list those RRTYPEs it should consider including?
If so, should the draft list these in weighted order?
Does this include _prefix locations? (eg like for TLSA)
Which records do you think should be considered?

> the target is under the last known name or not. Is it entirely at the

The server should always have a say to reject a certain (malicious)
chain. The server should also take into account the transport. It might
not want to make an eastlake protected UDP packet too large, but can
include a lot more when using TCP. If the chain has too many entries
outside the path of last known name to qname, then it has no idea how
much data to send, and performing a lot of work to build the query might
not be worth it, especially if the client already has most of this
information but couldn't know its question would trigger those in its
answers.

Should the draft include text on avoiding some of the potentially less
useful type of chains?

>> This is not about bandwidth saving.

I fail to be convinced by your statements.

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Mar 2015 01:01:50 +0000

> paul@bofh:~$ dig a +dnssec www.nohats.ca @127.0.0.1

Oh come on, surely you understand the difference between a protocol
requirement and an implementation artifact.

I agree that current validators use too many round trips, but that is not
because of problems in the protocol.

> Yes, that is what this draft recommends. Are you agreeing with me?

Sorry, by "send the whole lot" I mean the client can bundle up half a
dozen queries (each a separate DNS message) into one TCP packet.

Most existing recursive servers will process these queries serially, but
as Mark Andrews pointed out, if you send the original query before the
queries for the DS+DNSKEY chain, the first query will prime the cache so
the later queries can be answered immediately, for a 1RTT response.

> that in itself completely validates.

But with the existing DNS protocol you can send out queries for everything
you need up front. If you use edns-chain-query there are still situations
where you have to ask follow-up queries, in pretty much the same cases as
without the extension.

You can implement the API you want without edns-chain-query.

I have looked at several validators, and they all have network logic
intertwined with the validation logic. None of the ones I looked at
currently have a function which can take a chain of RRsets and validate
them, the kind of function edns-chain-query would need. Once you have such
a function it's fairly easy to do 1 RTT query and validation without
edns-chain-query, and you want to do that anyway for compatibility with
old servers.

> Which records do you think should be considered?

You misunderstand what I mean. I am not suggesting adding answers for
questions that were not asked. I mean dealing with situations where the
DNS protocol (ignoring DNSSEC) requires follow-up queries that the client
cannot predict in advance, and which therefore require a second round
trip.

For example, if I ask for:
  dotat.at in mx ?
I may have to make follow-up queries regarding the target of the MX
record(s), and they have to be a second round trip.

This also applies to CNAME, DNAME, SRV, NS, maybe others.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire, Southeast Forties: Southwesterly 4 or 5, becoming variable 3 or
4, then southeasterly 6 to gale 8 later. Moderate or rough. Fair. Good.