Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
The reasoning as I remember it: If I ask the server for vix.su a question, and it helpfully provides an answer in redbarn.org, ... That's not what Warren's proposing. Did you read the draft? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
On Tue, Jan 13, 2015 at 11:28 PM, Paul Vixie p...@redbarn.org wrote: Warren Kumari war...@kumari.net Tuesday, January 13, 2015 8:19 PM ... I'm surprised that no-one has yet commented on the 'Let's just co-opt the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or not, and are scared to ask :-) W i think you're not kidding, but that you'll ignore input you consider grumpy, so i wasn't going to mention any specific defect. instead i'll ask: what's your use case? do you, or your employer, or indeed anybody anywhere, need this feature? for what? *Need* the feature? Nope, it's just an optimization. It seemed to me that DNSSEC allows you to actually have some faith in the additional data, and so its worth revisiting if we can use it. I have no idea what my employer thinks of this - I wrote it because it seemed interesting to me. In general they like things that make the user experience faster, and (if this works), it should do that, so... probably they'd like it but who knows i've long believed that just as A and are optional additional-data in MX and SRV and NS responses, so it should be that A should be optional additional-data for responses, and 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... 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 for A, A for . 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. 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] This optimization might not be worth it - but I figured drafts are cheap, and worth discussing... If the consensus is that this is not worth doing, I'm fine to abandon the work. (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 W [0]: These examples are somewhat self-inflicted pain - you could have skipped the CNAME, and you could also have put all the resources on www.foo. -- Paul Vixie -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
On Tue, Jan 13, 2015 at 9:17 PM, John Levine jo...@taugh.com wrote: First, for a same transaction, the cost from using TCP may be more than the gain from the queries you save, which may ultimately let the performance become even worse. Do you have any consideration on this? And also, if already doing tcp the the auth server, why not just ask the 4 questions asynchronously over the TCP channel, instead of waiting to see if the server will give you a freebie, where you might have to send another query (After the RTT) for the data? In most cases, you won't know what other questions to ask until you get the initial response back. In some cases, e.g., domains used in web pages, you won't know the other questions until you've done a lot of other work, too. I'm not sure whether this is a good idea, but the motivation makes sense. I'm also not sure that it is a good idea - it may be a case of premature optimization (30 years on :-)), but I figured it was worth discussing. It seems that there are a number of places where it might make things harder^w, better, stronger, faster (https://www.youtube.com/watch?v=K2cYWfq--Nwt=0m50s), and doesn't really violate the spec (too much!) I'm surprised that no-one has yet commented on the 'Let's just co-opt the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or not, and are scared to ask :-) W R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
Warren Kumari mailto:war...@kumari.net Tuesday, January 13, 2015 8:19 PM ... I'm surprised that no-one has yet commented on the 'Let's just co-opt the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or not, and are scared to ask :-) W i think you're not kidding, but that you'll ignore input you consider grumpy, so i wasn't going to mention any specific defect. instead i'll ask: what's your use case? do you, or your employer, or indeed anybody anywhere, need this feature? for what? i've long believed that just as A and are optional additional-data in MX and SRV and NS responses, so it should be that A should be optional additional-data for responses, and 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. what have you got for multiple-responses in terms of motivation for the complexity of a protocol change? (if this is what you meant when you said you were expecting grumpy responses, feel free to ignore me.) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
Warren Kumari mailto:war...@kumari.net 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 are optional additional-data in MX and SRV and NS responses, so it should be that A should be optional additional-data for responses, and 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 with A, and A with , 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 for A, A for . 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 ;; ANSWER SECTION: ss.vix.su. 3600IN CNAME family.redbarn.org. family.redbarn.org. 1200IN 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 ;; ANSWER SECTION: www.microsoft.com. 2724IN 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 2600:1406:1a:485::2768 e10088.dscb.akamaiedge.net. 20 IN 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 ;; ANSWER SECTION: somewhere.vix.su. 3600IN 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
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
On Tue, Jan 13, 2015 at 10:08:00PM -0800, Paul Vixie wrote: 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. Didn't we decide a while back that this was a bad idea, that resolvers needed to stop trusting CNAME chains sent by authorities, and that authorities really ought to stop sending them? The reasoning as I remember it: If I ask the server for vix.su a question, and it helpfully provides an answer in redbarn.org, I have only its own assurances that it *is* in fact authoritative for redbarn.org; the answer can't be trusted until I've chased delegations to redbarn.org too. Even if I'm DNSSEC-validating your responses, you *could* be replaying an outdated answer with a still-valid signature, so I'm safest if I resolve each name in the CNAME chain separately. (I vividly remember a thread about this three or four years ago, but I'm having poor luck with the grepping.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
It is said in this draft that The authoritative nameserver SHOULD include as many of the additional records as will fit in the response. It may be true that some of the Resource Records in the same DNS zone file are highly related. But authority servers do not know which resource records are in the cache of recursive servers and which not, because the expiration time (due to TTL mechanism) of the resource records from the same DNS zone file are different! So there may be many additional records (in the so-called multiple-response) thrown away by the recursive servers, because there are already answer records due to real DNS request in the cache! It is said many times in the mailing list that this draft is for optimization, and maybe it is time to prove that the ratio of additional records needed by the recursive servers will be really very high and the ratio of additional records thrown away by the recursive servers will be very low, by real data trace or mathematical model. Guangqing Deng CNNIC From: Warren Kumari Date: 2015-01-14 13:22 To: Paul Vixie CC: dnsop; Paul Wouters; John Levine Subject: Re: [DNSOP]答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt On Tue, Jan 13, 2015 at 11:28 PM, Paul Vixie p...@redbarn.org wrote: Warren Kumari Tuesday, January 13, 2015 8:19 PM ... I'm surprised that no-one has yet commented on the 'Let's just co-opt the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or not, and are scared to ask :-) W i think you're not kidding, but that you'll ignore input you consider grumpy, so i wasn't going to mention any specific defect. instead i'll ask: what's your use case? do you, or your employer, or indeed anybody anywhere, need this feature? for what? *Need* the feature? Nope, it's just an optimization. It seemed to me that DNSSEC allows you to actually have some faith in the additional data, and so its worth revisiting if we can use it. I have no idea what my employer thinks of this - I wrote it because it seemed interesting to me. In general they like things that make the user experience faster, and (if this works), it should do that, so... probably they'd like it but who knows i've long believed that just as A and are optional additional-data in MX and SRV and NS responses, so it should be that A should be optional additional-data for responses, and 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... 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 for A, A for . 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. 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] This optimization might not be worth it - but I figured drafts are cheap, and worth discussing... If the consensus is that this is not worth doing, I'm fine to abandon the work. (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 W [0]: These examples are somewhat self-inflicted pain - you could have skipped the CNAME, and you could also have put all the resources on www.foo. -- Paul Vixie -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
Evan Hunt mailto:e...@isc.org Tuesday, January 13, 2015 10:41 PM Didn't we decide a while back that this was a bad idea, that resolvers needed to stop trusting CNAME chains sent by authorities, and that authorities really ought to stop sending them? yes, we did, unless dnssec signatures are also sent. that's in warren's proposal also. Even if I'm DNSSEC-validating your responses, you *could* be replaying an outdated answer with a still-valid signature, ... no, because you could receive that signature in other ways, and so its validity-period is all that governs. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
In message cakr6gn3ohsbmm9wcize8cg03ze2-nxcbvl4gnvj+k0gmtpl...@mail.gmail.com
, George Michaelson writes:
Mark.. can you amplify a bit on:
FORMERR will just cause the nameserver to think that EDNS is not
supported. This is not a issue unless there are signed zones and
the resolver is validating.
Because somewhere north of 10% of the world now validates..
It is only a problem if the zone is signed and the server is broken
and you are validating. That combination is miniscule.
EDNS - FORMERR - Plain DNS
EDNS + OPTION - FORMERR - Plain DNS
Now nameservers could do
EDNS + OPTION - FORMERR - EDNS - FORMERR - Plain DNS
but that adds yet another round trip if EDNS is not supported.
BADVERS isn't as bad as you at least know that EDNS is supported
EDNS + OPTION - BADVERS - EDNS
That said we need to have a active program to notify operators of
broken servers so they can get them fixed before people run into
these issues.
It is easy enough to identify servers that misbehave with unknown
EDNS options. It only takes a couple of queries to differentiate
between EDNS not supported and broken EDNS support.
These were generated by looking at subsets of the Alexa top 1M and
processing the root zone.
http://users.isc.org/~marka/gov-report.html
http://users.isc.org/~marka/tld-report.html
http://users.isc.org/~marka/au-report.html
http://users.isc.org/~marka/alexa-report.html
http://users.isc.org/~marka/bottom-report.html
What would be useful would be for all TLD operators to generate
lists of broken servers and inform their operators.
Mark
On Wed, Jan 14, 2015 at 10:09 AM, Mark Andrews ma...@isc.org wrote:
In message alpine.lfd.2.10.1501130909220.4...@bofh.nohats.ca, Paul
Wouters wr
ites:
On Tue, 13 Jan 2015, Davey Song () wrote:
As to the draft itself, there are two questions:
First, for a same transaction, the cost from using TCP may be more than
the gain from the queries you save, which may ultimately let the
performance become even worse. Do you have any consideration on this?
And also, if already doing tcp the the auth server, why not just ask the
4 questions asynchronously over the TCP channel, instead of waiting to
see if the server will give you a freebie, where you might have to send
another query (After the RTT) for the data?
Second, the purpose of using TCP is to mitigate amplify attack as you
describe in the draft. I notice that there is a draft using DNS cookie
to counter that problem. But it lacks incentive to deploy. For my
concern,
you can consider to combine the two ideas to achieve better result.
Nameserver vendors will just turn this on by default, that is ISC's
intention with named once the option is finalized. Theoretically
it should be ignored if not understood and if not it can be disabled
of a per server basis.
From BIND 9.10 (configure --enable-sit).
server 2001:428::7 { request-sit no; };
http://users.isc.org/~marka/ts/gov.optfail.html
http://users.isc.org/~marka/ts/au.optfail.html
http://users.isc.org/~marka/ts/tld.optfail.html
http://users.isc.org/~marka/ts/bottom.optfail.html
http://users.isc.org/~marka/ts/alexa.optfail.html
FORMERR will just cause the nameserver to think that EDNS is not
supported. This is not a issue unless there are signed zones and
the resolver is validating.
BADVERS is identifiable in the response and you use it as a heuristic
to disable sending the option.
Echoing of the option is not a issue for cookies.
Timeout will be treated like EDNS is not supported.
NXDOMAIN can sometimes be returned by badly configured load balancers.
Adobe's load balance is a example of this. They just need CNAME's
added to the backend nameserver but Adobe doesn't seem to understand
this. They also don't respond correctly to CNAME queries despite
returning CNAME to A/ queries.
The cookies wouldn't help much because it per definition introduced
another round trip.
Cookies don't require another round trip. Authoritative servers
can still adjust the responses they send depending upon whether
there is as valid server cookie or not.
Additionally I don't see nameservers leaving idle TCP connections
around for hours / days.
Also, why hardcode the records on the auth server. I think it is much
better to leave the auth servers as is, and have resolvers figure out
dynamically what is often asked in bundles and see if it can stuff
in an additional record there.
While I see a great use of a long term TCP connection between stubs and
resolvers, I am not sure I'm much in favour or doing lots of TCP between
resolver and auth server.
Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117,
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
On Tue, 13 Jan 2015, Davey Song (宋林健) wrote: As to the draft itself, there are two questions: First, for a same transaction, the cost from using TCP may be more than the gain from the queries you save, which may ultimately let the performance become even worse. Do you have any consideration on this? And also, if already doing tcp the the auth server, why not just ask the 4 questions asynchronously over the TCP channel, instead of waiting to see if the server will give you a freebie, where you might have to send another query (After the RTT) for the data? Second, the purpose of using TCP is to mitigate amplify attack as you describe in the draft. I notice that there is a draft using DNS cookie to counter that problem. But it lacks incentive to deploy. For my concern, you can consider to combine the two ideas to achieve better result. The cookies wouldn't help much because it per definition introduced another round trip. Also, why hardcode the records on the auth server. I think it is much better to leave the auth servers as is, and have resolvers figure out dynamically what is often asked in bundles and see if it can stuff in an additional record there. While I see a great use of a long term TCP connection between stubs and resolvers, I am not sure I'm much in favour or doing lots of TCP between resolver and auth server. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
In message alpine.lfd.2.10.1501130909220.4...@bofh.nohats.ca, Paul Wouters wr
ites:
On Tue, 13 Jan 2015, Davey Song () wrote:
As to the draft itself, there are two questions:
First, for a same transaction, the cost from using TCP may be more than
the gain from the queries you save, which may ultimately let the
performance become even worse. Do you have any consideration on this?
And also, if already doing tcp the the auth server, why not just ask the
4 questions asynchronously over the TCP channel, instead of waiting to
see if the server will give you a freebie, where you might have to send
another query (After the RTT) for the data?
Second, the purpose of using TCP is to mitigate amplify attack as you
describe in the draft. I notice that there is a draft using DNS cookie
to counter that problem. But it lacks incentive to deploy. For my concern,
you can consider to combine the two ideas to achieve better result.
Nameserver vendors will just turn this on by default, that is ISC's
intention with named once the option is finalized. Theoretically
it should be ignored if not understood and if not it can be disabled
of a per server basis.
From BIND 9.10 (configure --enable-sit).
server 2001:428::7 { request-sit no; };
http://users.isc.org/~marka/ts/gov.optfail.html
http://users.isc.org/~marka/ts/au.optfail.html
http://users.isc.org/~marka/ts/tld.optfail.html
http://users.isc.org/~marka/ts/bottom.optfail.html
http://users.isc.org/~marka/ts/alexa.optfail.html
FORMERR will just cause the nameserver to think that EDNS is not
supported. This is not a issue unless there are signed zones and
the resolver is validating.
BADVERS is identifiable in the response and you use it as a heuristic
to disable sending the option.
Echoing of the option is not a issue for cookies.
Timeout will be treated like EDNS is not supported.
NXDOMAIN can sometimes be returned by badly configured load balancers.
Adobe's load balance is a example of this. They just need CNAME's
added to the backend nameserver but Adobe doesn't seem to understand
this. They also don't respond correctly to CNAME queries despite
returning CNAME to A/ queries.
The cookies wouldn't help much because it per definition introduced
another round trip.
Cookies don't require another round trip. Authoritative servers
can still adjust the responses they send depending upon whether
there is as valid server cookie or not.
Additionally I don't see nameservers leaving idle TCP connections
around for hours / days.
Also, why hardcode the records on the auth server. I think it is much
better to leave the auth servers as is, and have resolvers figure out
dynamically what is often asked in bundles and see if it can stuff
in an additional record there.
While I see a great use of a long term TCP connection between stubs and
resolvers, I am not sure I'm much in favour or doing lots of TCP between
resolver and auth server.
Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
Mark.. can you amplify a bit on:
FORMERR will just cause the nameserver to think that EDNS is not
supported. This is not a issue unless there are signed zones and
the resolver is validating.
Because somewhere north of 10% of the world now validates..
On Wed, Jan 14, 2015 at 10:09 AM, Mark Andrews ma...@isc.org wrote:
In message alpine.lfd.2.10.1501130909220.4...@bofh.nohats.ca, Paul
Wouters wr
ites:
On Tue, 13 Jan 2015, Davey Song () wrote:
As to the draft itself, there are two questions:
First, for a same transaction, the cost from using TCP may be more than
the gain from the queries you save, which may ultimately let the
performance become even worse. Do you have any consideration on this?
And also, if already doing tcp the the auth server, why not just ask the
4 questions asynchronously over the TCP channel, instead of waiting to
see if the server will give you a freebie, where you might have to send
another query (After the RTT) for the data?
Second, the purpose of using TCP is to mitigate amplify attack as you
describe in the draft. I notice that there is a draft using DNS cookie
to counter that problem. But it lacks incentive to deploy. For my
concern,
you can consider to combine the two ideas to achieve better result.
Nameserver vendors will just turn this on by default, that is ISC's
intention with named once the option is finalized. Theoretically
it should be ignored if not understood and if not it can be disabled
of a per server basis.
From BIND 9.10 (configure --enable-sit).
server 2001:428::7 { request-sit no; };
http://users.isc.org/~marka/ts/gov.optfail.html
http://users.isc.org/~marka/ts/au.optfail.html
http://users.isc.org/~marka/ts/tld.optfail.html
http://users.isc.org/~marka/ts/bottom.optfail.html
http://users.isc.org/~marka/ts/alexa.optfail.html
FORMERR will just cause the nameserver to think that EDNS is not
supported. This is not a issue unless there are signed zones and
the resolver is validating.
BADVERS is identifiable in the response and you use it as a heuristic
to disable sending the option.
Echoing of the option is not a issue for cookies.
Timeout will be treated like EDNS is not supported.
NXDOMAIN can sometimes be returned by badly configured load balancers.
Adobe's load balance is a example of this. They just need CNAME's
added to the backend nameserver but Adobe doesn't seem to understand
this. They also don't respond correctly to CNAME queries despite
returning CNAME to A/ queries.
The cookies wouldn't help much because it per definition introduced
another round trip.
Cookies don't require another round trip. Authoritative servers
can still adjust the responses they send depending upon whether
there is as valid server cookie or not.
Additionally I don't see nameservers leaving idle TCP connections
around for hours / days.
Also, why hardcode the records on the auth server. I think it is much
better to leave the auth servers as is, and have resolvers figure out
dynamically what is often asked in bundles and see if it can stuff
in an additional record there.
While I see a great use of a long term TCP connection between stubs and
resolvers, I am not sure I'm much in favour or doing lots of TCP between
resolver and auth server.
Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt
Hi Warren It's good idea that the authority DNS be smart enough to predict or configured to package all the information for a URL as a whole object (like a webpage). It will reduce the latency for user. As to the draft itself, there are two questions: First, for a same transaction, the cost from using TCP may be more than the gain from the queries you save, which may ultimately let the performance become even worse. Do you have any consideration on this? Second, the purpose of using TCP is to mitigate amplify attack as you describe in the draft. I notice that there is a draft using DNS cookie to counter that problem. But it lacks incentive to deploy. For my concern, you can consider to combine the two ideas to achieve better result. Glad to see more discussion on application and innovation of large packet which will lead us to break through the limitation of 512B :-) Davey -邮件原件- 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Warren Kumari 发送时间: 2015年1月12日 4:52 收件人: dnsop 主题: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt Hi all, This document may contain much that makes folk grumpy. It proposes allowing an authoritative nameserver to return additional information (surprisingly, in the Additional section), and have recursives trust it (because it is DNSSEC signed). This makes responses larger, and so we propose an, um, interesting mitigation to the DDoS concern... you'll have to read it to find out what :-P W -- Forwarded message -- From: internet-dra...@ietf.org Date: Sun, Jan 11, 2015 at 3:47 PM Subject: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt To: Wesley Hardaker i...@hardakers.net, Warren Kumari war...@kumari.net, Zhiwei Yan yanzhi...@cnnic.cn A new version of I-D, draft-wkumari-dnsop-multiple-responses-00.txt has been successfully submitted by Warren Kumari and posted to the IETF repository. Name: draft-wkumari-dnsop-multiple-responses Revision: 00 Title: Returning multiple answers in a DNS response. Document date: 2015-01-11 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-multiple-responses-0 0.txt Status: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ Htmlized: http://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-00 Abstract: This document (re)introduces the ability to provide multiple answers in a DNS response. 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
