Re: [dns-operations] CloudFlare policy on ANY records changing
Once upon a time, Paul Hoffman paul.hoff...@vpnc.org said: If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that. A problem with ever using ANY to get more information from a cache is the client's/applications's assumption that all requests will go to the same server. Even if a client sends requests to the same IP, anycast can mean they go to a different server. -- Chris Adams c...@cmadams.net ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Mon, Mar 9, 2015 at 10:58 PM, Mark Andrews ma...@isc.org wrote: In message cagmqtqjrpx_xg_ojtshsw5yqaefkzwdma16xw7iry9pr0_f...@mail.gmail.com , Yunhong Gu writes: Returning NOTIMP may confuse resolvers as it is not clear what is not implemented. Which is why you only change one thing at a time when trying to determine what is covered by NOTIMP. A NOTIMP response to an ANY query with EDNS0 option could cause a retry-without-EDNS0 query, or mislead the resolver to believe that the nameserver does not support EDNS0. And if you retry w/o a OPT record you will still get NOTIMP, move onto the next nameserver and enventually return SERVFAIL. Retry introduces latency, which matters a lot for resolvers. There are situations a resolver may not want to enumerate all possibilities (e.g. the client may already timeout before the resolver get the final response). Note there really is nothing special w.r.t. ANY here. We have nameservers that return NOTIMP to TXT, MX, NS, SOA, DNSKEY etc. About the only query type that doesn't get NOTIMP is A. ANY is indeed a little special compared to the examples you mentioned. If a nameserver returns response for A, then it should return NODATA instead of NOTIMP for TXT, MX, etc. Returning NODATA for ANY is a little confusing, though it can be argued to be legitimate if only cached records are returned. So the problem is, why NOTIMP? REFUSED sounds like a better choice. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Mar 10, 2015, at 8:46 AM, David C Lawrence t...@akamai.com wrote: Paul Hoffman writes: On Mar 10, 2015, at 6:25 AM, Yunhong Gu g...@google.com wrote: So the problem is, why NOTIMP? REFUSED sounds like a better choice. +1. REFUSED exactly describes what is going on. One down side there, however, is that REFUSED as understood by resolvers commonly has the semantic currently that the name is not hosted by the server at all. What used to be root referrals for lame delegations is now REFUSED to minimize response size. If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that. It is likely that any response we think of (even no response at all) will cause some deployed resolvers to get the wrong idea. Having said that, it is perfectly reasonable for an operator to not want to reply to an ANY, given the unclarity of what it is expected to send back and the opportunity for malicious intelligence gathering. So us saying if you want to do this, use that at least will cause future versions of things that relied on ANY to know what they are getting. Also: this should probably one of the three threads on dn...@ietf.org... --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Tue, 10 Mar 2015, Chris Adams wrote: A problem with ever using ANY to get more information from a cache is the client's/applications's assumption that all requests will go to the same server. Even if a client sends requests to the same IP, anycast can mean they go to a different server. So so true. You can use it in some vague way to fingerprint anycast DNS services. DAMHIK! -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Mar 10, 2015, at 6:25 AM, Yunhong Gu g...@google.com wrote: So the problem is, why NOTIMP? REFUSED sounds like a better choice. +1. REFUSED exactly describes what is going on. --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
Paul Hoffman writes: On Mar 10, 2015, at 8:46 AM, David C Lawrence t...@akamai.com wrote: One down side there, however, is that REFUSED as understood by resolvers commonly has the semantic currently that the name is not hosted by the server at all. If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that. Yeah, we've well established they shouldn't. Bad guys often don't care about what they shouldn't be doing, though, and (untested assertion follows) using REFUSED responses for ANY queries of random names could be a pretty useful vector for getting all of the servers for a domain declared lame. I'm not saying that ultimately the REFUSED approach is unworkable, just that I'd like to see some practical testing of it in addition to the support of the philosophical purity of it. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
Returning NOTIMP may confuse resolvers as it is not clear what is not implemented. A NOTIMP response to an ANY query with EDNS0 option could cause a retry-without-EDNS0 query, or mislead the resolver to believe that the nameserver does not support EDNS0. Yunhong On Fri, Mar 6, 2015 at 2:10 PM, Paul Vixie p...@redbarn.org wrote: Jared Mauch wrote: On Mar 6, 2015, at 11:02 AM, Olafur Gudmundsson o...@ogud.com o...@ogud.com wrote: By announcing this we are hoping that anyone running un-patched qmail will fix it. I’m guessing there will be no change. right. most of us blocked IDENT (without ICMP, to force the far end into its longest possible state-holding timeout period) in order to communicate the offensive futility of a protocol that asked an initiator to help in any way to verify the identity behind some other connection emanating from that same initiator, and the result was not widespread IDENT sucks, i'm turning it off, but rather, further ignorance and more bliss. QMAIL users are already accustomed to frequent mystery failures. no matter how many authority servers turn off ANY queries, there will be no patching of QMAIL and no migration of QMAIL operators to other platforms. the interesting part of this game will be when mozilla firefox's users start switching back to Chrome again because the DNS community's immune response to the recent QTYPE=ANY change hits that browser right between the eyes. perhaps they'll switch MPR (mozilla portable runtime) to the newer http://getdnsapi.net/; http://getdnsapi.net/ tech in order to stem their losses? anyway i'm going to stock up on popcorn so as to enjoy watching this show. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
In message cagmqtqjrpx_xg_ojtshsw5yqaefkzwdma16xw7iry9pr0_f...@mail.gmail.com , Yunhong Gu writes: Returning NOTIMP may confuse resolvers as it is not clear what is not implemented. Which is why you only change one thing at a time when trying to determine what is covered by NOTIMP. A NOTIMP response to an ANY query with EDNS0 option could cause a retry-without-EDNS0 query, or mislead the resolver to believe that the nameserver does not support EDNS0. And if you retry w/o a OPT record you will still get NOTIMP, move onto the next nameserver and enventually return SERVFAIL. Note there really is nothing special w.r.t. ANY here. We have nameservers that return NOTIMP to TXT, MX, NS, SOA, DNSKEY etc. About the only query type that doesn't get NOTIMP is A. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] CloudFlare policy on ANY records changing
We will be depreciating support for ANY queries and return NOTIMP in the near future https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ ID proposing this behavior will be forthcoming Olafur ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Mar 6, 2015, at 10:54 AM, Anthony Eden anthony.e...@dnsimple.com wrote: Olafur, Out of curiosity, have you considered forcing ANY queries over to TCP in all cases as a starting point to see what impact it has, if any? Sincerely, Anthony Eden Yes we have been doing that for the last few months. That does help a lot but still allows attackers to fill Recursive Resolvers with large answers to replay. For us the main advantage of doing NOTIMP is code simplicity we can generate the return packet without hitting the actual DNS server. Another thought we had was to “poison” resolvers with bogus long lived record like qname 1W HINFO “Stop sending” “ANY query” Olafur On Fri, Mar 6, 2015 at 4:48 PM, Casey Deccio ca...@deccio.net mailto:ca...@deccio.net wrote: On Fri, Mar 6, 2015 at 10:05 AM, Olafur Gudmundsson o...@ogud.com mailto:o...@ogud.com wrote: We will be depreciating support for ANY queries and return NOTIMP in the near future https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ ID proposing this behavior will be forthcoming Be prepared... Less than two years ago a prominent DNS service began denying ANY queries for a previous employer's domain, and some (important) emails were not delivered. Historical measurements will help quantify potential issues, but certainly those are not comprehensive, and like anything, there will be breakage. I'm not suggesting it's not the right direction, but the change seems somewhat abrupt, and might result in some undesirable near-term effects. Community support and publicity could help mitigate issues. Best regards, Casey ___ dns-operations mailing list dns-operations@lists.dns-oarc.net mailto:dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs https://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- DNSimple.com http://dnsimple.com/ http://dnsimple.com/ Twitter: @dnsimple ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Fri, 6 Mar 2015, Olafur Gudmundsson wrote: We will be depreciating support for ANY queries and return NOTIMP in the near future https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ ID proposing this behavior will be forthcoming Can't you wait for eastlake cookies and only allow it on source address verified queries (TCP or a send an eastlake cookie) ? That would cause less breakage. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On Mar 6, 2015, at 10:48 AM, Casey Deccio ca...@deccio.net wrote: On Fri, Mar 6, 2015 at 10:05 AM, Olafur Gudmundsson o...@ogud.com mailto:o...@ogud.com wrote: We will be depreciating support for ANY queries and return NOTIMP in the near future https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ ID proposing this behavior will be forthcoming Be prepared... Less than two years ago a prominent DNS service began denying ANY queries for a previous employer's domain, and some (important) emails were not delivered. Historical measurements will help quantify potential issues, but certainly those are not comprehensive, and like anything, there will be breakage. I'm not suggesting it's not the right direction, but the change seems somewhat abrupt, and might result in some undesirable near-term effects. Community support and publicity could help mitigate issues. Best regards, Casey By announcing this we are hoping that anyone running un-patched qmail will fix it. Olafur ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
On 3/6/15, 10:05, Olafur Gudmundsson o...@ogud.com wrote: We will be depreciating support for ANY queries and return NOTIMP in the near future https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ ID proposing this behavior will be forthcoming I simultaneoulsy requested on on DNSOP. ;) smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudFlare policy on ANY records changing
IIRC UltraDNS/Neustar did this some time ago as well, but it looks as if they have reinstated it. You may want to ask them how that played out. - mark Olafur Gudmundsson wrote: On Mar 6, 2015, at 10:48 AM, Casey Deccio ca...@deccio.net mailto:ca...@deccio.net wrote: On Fri, Mar 6, 2015 at 10:05 AM, Olafur Gudmundsson o...@ogud.com mailto:o...@ogud.com wrote: We will be depreciating support for ANY queries and return NOTIMP in the near future https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ ID proposing this behavior will be forthcoming Be prepared... Less than two years ago a prominent DNS service began denying ANY queries for a previous employer's domain, and some (important) emails were not delivered. Historical measurements will help quantify potential issues, but certainly those are not comprehensive, and like anything, there will be breakage. I'm not suggesting it's not the right direction, but the change seems somewhat abrupt, and might result in some undesirable near-term effects. Community support and publicity could help mitigate issues. Best regards, Casey By announcing this we are hoping that anyone running un-patched qmail will fix it. Olafur ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark E. Jeftovic mar...@easydns.com Founder CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
