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

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 protected]> wrote:

>
> 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 protected]
> To: Paul Wouters <[email protected]>
> 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<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:
>    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
>
>
> ______________________________**_________________
> dnsext mailing list
> [email protected]
> https://www.ietf.org/mailman/**listinfo/dnsext<https://www.ietf.org/mailman/listinfo/dnsext>
>

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext