Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

[Paul Vixie <[e-mail]>]

> Warren Kumari <mailto:[e-mail]>
> Tuesday, January 13, 2015 9:22 PM
>
> ... I wrote it because it seemed interesting to me.

i think you should do a deeper cost:benefit dive before proposing new
signalling on-the-wire.

>
>     i've long believed that just as A and AAAA are optional
>     additional-data in MX and SRV and NS responses, so it should be
>     that A should be optional additional-data for AAAA responses, and
>     AAAA should be optional additional-data for A responses. 
>
>
>     those are use cases i understand, and where the protocol impact is
>     negligible, as in, it could be an FYI.
>
>
> Yup. Those seem reasonable. This is (IMO) just an extension of that
> idea...

not just an extension of, because there is no new signalling on-the-wire
in the additional-data behaviours i mentioned above. we could do those
now, and not require any upgrades anywhere. many pre-DNSSEC servers will
cache any additional data that matches the QNAME. we could all literally
start sending AAAA with A, and A with AAAA, and it would not only not
break anything, it would start making eyeballs happier that same day.
>  
>
>
>     what have you got for "multiple-responses" in terms of motivation
>     for the complexity of a protocol change?
>
>
>
> I don't see this as a large protocol change - the 'only over tcp' was
> only put in to mitigate the "this will make packets huge" concern that
> I figured some people would have.. Other than that there is signaling
> support - which I put in because I figured it didn't hurt. The actual
> including multiple responses bit doesn't really seem to violate
> protocol - as you said re: A and AAA as optional additional-data in MX
> and SRV and NS, and AAAA for A, A for AAAA.

as others have pointed out, TCP is the wrong constraint to get what you
mean. like, "proof that the transaction's initiator address has not been
forged, or else, defense against DDoS amplification such as response
rate limiting, are a prerequisite of this new responder behaviour."
>
> The motivation for this is just efficiency / reducing latency -
> looking up foo.example, getting a CNAME to bar.example and then
> looking that up in another transaction seems inefficient and inelegant.

you've left the box i thought we were standing in. CNAME chains are
already returned by authorities, if in your above example, the alias and
the canonical name are served by the same authority server. take a look
at this:

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54849
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ss.vix.su.                     IN      AAAA
>
> ;; ANSWER SECTION:
> ss.vix.su.              3600    IN      CNAME   family.redbarn.org.
> family.redbarn.org.     1200    IN      AAAA    2001:559:8000:cd::5

whereas, in a non-authoritative response, even an out-of-zone CNAME
chain is followed and returned in its entirety:

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10123
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.microsoft.com.             IN      AAAA
>
> ;; ANSWER SECTION:
> www.microsoft.com.      2724    IN      CNAME   toggle.www.ms.akadns.net.
> toggle.www.ms.akadns.net. 300   IN      CNAME  
> www.microsoft.com.edgekey.net.
> www.microsoft.com.edgekey.net. 300 IN   CNAME  
> e10088.dscb.akamaiedge.net.
> e10088.dscb.akamaiedge.net. 20  IN      AAAA    2600:1406:1a:485::2768
> e10088.dscb.akamaiedge.net. 20  IN      AAAA    2600:1406:1a:484::2768

this is true even if the end of the CNAME chain is NXDOMAIN.

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15097
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;somewhere.vix.su.              IN      AAAA
>
> ;; ANSWER SECTION:
> somewhere.vix.su.       3600    IN      CNAME   nowhere.vix.su.


and if DNSSEC signatures are available, they are all returned. (example
not provided due to excessive size.)

i worry that if you didn't know that CNAME worked like this, how well
was the rest of your proposal researched? that's especially concerning
since your motivation wasn't a use case but rather "it seemed
interesting" and because you're calling it a "small" protocol change
without considering the size of the installed base or the long length of
the tail of deployment.

> Similarly, looking up www.example, getting the webpage and then doing
> a bunch of separate lookups for all the resources in it, like
>  images.example, js.example, css.example simply seems wasteful, and
> offends me :-) [0]

what you may want in this case is to help with the DNS-over-HTTP work,
since HTTP and HTTPS have connection persistency, and pipelining. (i
realize that john dickenson is also working on persistency and
pipelining for TCP/53 but i consider that a much larger change due to
the size of the existing TCP/53 installed base.)
>
> This optimization might not be worth it - but I figured drafts are
> cheap, and worth discussing...

drafts, and discussions, are not cheap. if you amortize the cost of the
time of all the people reading each message on this thread, plus their
air fare for the IETF meetings they go to, the activation energy of
every new draft is "fantastically cosmic" or higher.

> If the consensus is that this is not worth doing, I'm fine to abandon
> the work.

this is dnsop not dnsext. few ideas, no matter how questionable, will
fail to get consensus, since "no" votes aren't counted. if a nominal
number of folks are interested in working on this with you, it'll be
"game on".
>
>  
>
>
>     (if this is what you meant when you said you were expecting grumpy
>     responses, feel free to ignore me.)
>
>
> Nah, that wasn't a grumpy response. "Your draft is bad *and you should
> feel bad*" would be....

i do not want you to feel bad. however, i do hope you will re-consider
your approach, in several ways. every problem you're stating in this
draft has either an existing, or a lower cost, or a higher benefit,
solution than what you're proposing.

-- 
Paul Vixie