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

[Paul Wouters <[e-mail]>]

On Tue, 10 Mar 2015, Tony Finch wrote:

Tony,

>>> Without this extension the typical number of RTTs required is 1, so this
>>> isn't a reduction.
>>
>> 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.
>
> 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


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

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 ?

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

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.

>> 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?
>
> 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?

> 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?

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?

>>> 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.
>>
>> This is not about bandwidth saving.
>
> But that is all it does.

I fail to be convinced by your statements.

Paul