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

On Wed, 23 Oct 2013, Marc Lampo wrote:

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

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

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

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.

> I would propose that more examples are provided,
> 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
> considered as well.

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

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

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

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

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

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

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.

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

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
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext