Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
* Olafur Gudmundsson: On Mar 18, 2015, at 11:55 AM, Paul Vixie p...@redbarn.org wrote: we need a document that says If you don't want to answer ANY, here's how to do it interoperably. we don't need to say you should not answer ANY, but we do need to say if you want to query for ANY, here's what might happen. that, sir, is a killing. we are killing ANY. there's no pretense. This is exactly what my goal is tell the upstream the type ANY will not be answered. Upstream? Is reducing the number of ANY queries an immediate goal of yours? (Discounting any indirect effect that useless ANY answers will have on future application changes.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On 03/18/15 01:11, Michael Sinatra wrote: I think there are a few issues at play. google and other public recursives will sometimes have multiple backend servers fetch a given RR when they receive a single query for that RR on one instance of, say, 8.8.8.8. I am basing this both on observed behavior and on Geoff Huston's research (recently presented at NANOG). And since nothing is cached, I get the same servers asking the same query over and over again. Writ large, the result is that I end up with 1-2k of simultaneous TCP sessions, per server, per domain. Just a quick qualification: This is during an active attack, not as a normal course of events. However, the attacks can and will last for several weeks. michael ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Paul Wouters mailto:p...@nohats.ca Wednesday, March 18, 2015 6:58 AM On Wed, 18 Mar 2015, Paul Vixie wrote: my proposal is, limit ANY to a selected set of source-ip addresses, as is commonly done with AXFR/IXFR. Which I answered before by saying that is basically killing the ANY query. The proposed solution merely pretends to not kill it by saying acl. i don't think there's any pretense here about not wanting to kill, or not killing, ANY. the history of DNS is replete with examples of information leaks which had to be stopped, either by ad-hoc action or by standards action. limiting who can do zone transfers was first (BIND4 King James Edition, 1989-ish). preventing DNSSEC zone walking was next (DNSEXT, NSEC3, 2001-2014). now it's ANY. many things which made sense on an academic research Internet do not make sense on a world-wide commercial internet. we need a document that says If you don't want to answer ANY, here's how to do it interoperably. we don't need to say you should not answer ANY, but we do need to say if you want to query for ANY, here's what might happen. that, sir, is a killing. we are killing ANY. there's no pretense. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Paul Wouters wrote: On Tue, 17 Mar 2015, Yunhong Gu wrote: The reason that this response can be used for an amplification attack is its size, not the ANY type. A responses with 200 A records can be used for the same purpose. The (even deeper) root cause is the use of UDP in DNS protocol. I just do not think banning ANY touches any of these fundamental issues. Right, so require tcp or eastlake cookies, that would protect third parties, but not the server itself. or allow padding the ANY request so the request/response ratio is close to 1 before allowing the answer. that would not prevent the unfortunate information leak that allows third parties to scan our caches. Make the dig command default to tcp. That should cover the vast majority of valid ANY queries. my proposal is, limit ANY to a selected set of source-ip addresses, as is commonly done with AXFR/IXFR. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
note: replying only to dnsop@. no thread is ever appropriate for dnsop@
plus some other mailing list. please stop cc'ing dns-operations@ on your
replies; this is not an operational thread, and the people in the dns
community who care about protocol development, are probably on both lists.
Mark Andrews mailto:ma...@isc.org
Tuesday, March 17, 2015 10:10 AM
Lets get DNS cookies finalised so that TC=1 isn't needed for repeat
legitimate clients. ...
TC=1 for amplification suppression should be triggered by response
size and whether you are a known repeat client or not rather than
{meta} query type.
to be clear, response rate limiting will still be necessary even with
dns cookies in place.
without dns cookies, the requests don't have to have correct source-ip
addresses, and thus, a dns server can be made to attack the apparent
source of those queries. rrl helps with this.
with dns cookies, the requests have to have correct source-ip addresses,
and thus, a dns server can be made to attack its own upstream
infrastructure. rrl helps with this, also.
there should of course be more strict rate limits in place for the
former, than for the latter.
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
removing dns-operations@ as a cc. one mailing list at a time, please? Michael Sinatra wrote: On 3/16/15 4:15 PM, P Vixie wrote: Michael, what attacks do you think we can stop by limiting ANY? Paul ... * These domains are DNSSEC-signed with NSEC3. Many tools set the TTL of NSEC3PARAM to 0 when signing zones with NSEC3. The NSEC3PARAM RR is part of the ANY response. well, that's part of your problem right there. but i can see how ANY is involved, now. * The public recursive servers use an implementation that clears all records from the cache when the TTL of one record expires, so the next time the recursive server gets an ANY query, it must re-query the authoritative server. this is an internet-affecting bug and i hope you report it as such. RRsets are to be purged when the lowest TTL therein expires, but the other RRsets sharing that name should not be affected. can i ask which public facing dns service has mandated that the rest of us juggle their chainsaws for them in this way? (this is even worse than the jerk who decided that EDNS could use IP fragmentation -- but i think that guy has apologized at least.) In this situation, if I set TC=1 for all ANY queries on my authoritative server, but the public recursives don't, then the victim still gets hit with a pretty big amplification attack, and my authoritative servers get hammered with TCP queries. hammered sounds like a volume greater than that which would be detected and strangled with DNS RRL. what am i missing here, that makes this your problem, rather than the public recursive dns operator's problem? ... So my point is that if we're going to specify TC=1 for ANY queries, it has to be mandatory, and all implementations have to handle it the same: Send an empty NOERROR and set TC=1. If I am the only one setting TC=1, it won't doing any good for the attack described above, even if my domains are the ones being used in the attack. The other option is to allow the authoritative servers to control what gets set out in response to QTYPE=ANY. But I see devils in the details, just as with NOTIMP and other proposals. i think there's no saving ANY at this point. we're deciding how it dies and where to bury it, that's all. however, you've provided an example of an ANY attack that can't be trivially switch to TXT, so, thank you. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Tue, 17 Mar 2015, Yunhong Gu wrote: The reason that this response can be used for an amplification attack is its size, not the ANY type. A responses with 200 A records can be used for the same purpose. The (even deeper) root cause is the use of UDP in DNS protocol. I just do not think banning ANY touches any of these fundamental issues. Right, so require tcp or eastlake cookies, or allow padding the ANY request so the request/response ratio is close to 1 before allowing the answer. Make the dig command default to tcp. That should cover the vast majority of valid ANY queries. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On 03/16/15 18:07, Yunhong Gu wrote: On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra mich...@brokendns.net mailto:mich...@brokendns.net wrote: On 3/16/15 4:15 PM, P Vixie wrote: On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra mich...@brokendns.net mailto:mich...@brokendns.net wrote: On 03/16/15 07:23, bert hubert wrote: Separately, I fail to see why we actually need to outlaw ANY queries when we can happily TC=1 them. If the public recursives also support TC=1 on all ANY queries, then this works. If not, the issue arises where just-below-the-radar attacks are using many public recursives, in which case you're not stopping much. Michael, what attacks do you think we can stop by limiting ANY? Paul The attack that I have had to grapple with is this: * Someone sets up a bot to query public recursives (google, opendns, level3, etc.) for a particular domain whose ANY response is large. (This _usually_ means DNSSEC-signed.) * The query from each client,domain,qtype tuple is just barely slow enough not to trigger rate limiting from the public recursive service. * The backend of the public recursive service queries my authoritatives for some of the involved domains. Suppose the response is just under the usual typical default EDNS0 buffer size of 4096. * These domains are DNSSEC-signed with NSEC3. Many tools set the TTL of NSEC3PARAM to 0 when signing zones with NSEC3. The NSEC3PARAM RR is part of the ANY response. Sounds to me this is the root cause of the problem and ANY is the just a scapegoat. Giving NSEC3PARAM a positive TTL would prevent my headache, but it wouldn't help the victim of the attack, and would probably make it worse for the victim. michael ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mon, Mar 16, 2015 at 11:53:17PM +0900, Paul Vixie wrote: that is not the use case for this. the updated document makes clear that the iteration complexity in split-authority systems having a lightweight front end, is the situation where ANY is painful. Sorry? We solve implementation hardship by standards action now? Some modern Authoritative servers, such as those used by CDN's, do not have DNS zones. For those servers answering ANY query truthfully is hard work. Thus ignoring ANY queries simplifies the implementation. Is this really all there is to the story? Seriously? I have lots of respect for Olafur, but this does seem to turn a local challenge into a global standards action.. Bert ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On 16 Mar 2015, at 15:05, bert hubert bert.hub...@netherlabs.nl wrote: Sorry? We solve implementation hardship by standards action now? Some modern Authoritative servers, such as those used by CDN's, do not have DNS zones. For those servers answering ANY query truthfully is hard work. Thus ignoring ANY queries simplifies the implementation. Is this really all there is to the story? Seriously? I have lots of respect for Olafur, but this does seem to turn a local challenge into a global standards action.. Hypothetically, if you're using one of those funky NoSQL-style backends where RRs are looked up in a key-value store directly from a (QNAME, QTYPE) tuple I can see how supporting QTYPE == ANY would be tricky. The fact that ANY exists can put some significant implementation constraints on your system :( Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mon, Mar 16, 2015 at 03:16:08PM +, Ray Bellis wrote: Hypothetically, if you're using one of those funky NoSQL-style backends where RRs are looked up in a key-value store directly from a (QNAME, QTYPE) tuple I can see how supporting QTYPE == ANY would be tricky. At DNS query rates, you could just query purely based on the name as the key. You'd have to do so anyhow to determine what kind of NXDOMAIN/NOERROR response to generate! Or are we going to flatten that distinction too to ease implementation? Bert ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
bert hubert mailto:bert.hub...@netherlabs.nl Monday, March 16, 2015 11:23 PM On Mon, Mar 09, 2015 at 04:18:12PM +0100, bert hubert wrote: On Mon, Mar 09, 2015 at 11:08:03AM -, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. (...) Do you think I read 4.3.2 wrong? Or is there another RFC that updates the algorithm? Thanks to some clarification from Dan, I now understand that one can indeed rely on ANY queries to resolvers to either deliver a CNAME or no CNAME, in which case there is no CNAME. i'd like to see those clarifications. if any non-CNAME RRset had existed and been cached, and then replaced by a CNAME, then ANY would not see the CNAME until the last non-CNAME RRset had expired from that cache. which is why, when i want to know if there is a CNAME, i ask if there's a CNAME. i realize that this only matters when the non-CNAME TTL's are one to two weeks long, and weren't trimmed before replacement with the CNAME. however, that situation is common enough that i dispute the phrase quoted above, guaranteed to work by mandatory DNS standards. Separately, I fail to see why we actually need to outlaw ANY queries when we can happily TC=1 them. TC=1'ing them would be a way to prevent them from being used as an amplifying reflector. that is not the use case for this. the updated document makes clear that the iteration complexity in split-authority systems having a lightweight front end, is the situation where ANY is painful. there never was an ANY-related problem for which TC=1 was the solution. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On 16 Mar 2015, at 15:22, bert hubert bert.hub...@netherlabs.nl wrote: At DNS query rates, you could just query purely based on the name as the key. You'd have to do so anyhow to determine what kind of NXDOMAIN/NOERROR response to generate! Yes, that's a good point :) Or are we going to flatten that distinction too to ease implementation? No, we had that argument already - NOERROR is definitely the right error for an empty non-terminal ;-) Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Nicholas Weaver mailto:nwea...@icsi.berkeley.edu Sunday, March 15, 2015 4:44 AM On Mar 13, 2015, at 7:59 PM, Paul Vixie p...@redbarn.org wrote: Nicholas Weaver Saturday, March 14, 2015 5:07 AM ... Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good. several of us jumped for joy in 2008 when kaminsky showed rdns poisoning to be a trivial exercise, because it finally provided justification for what was at that time 12 years of apparently-wasted effort on DNSSEC. But it didn't justify DNSSEC, even at the time. no, of course not. dnssec was well justified by the need for new dnssec-aware applications such as DANE. all we got from kaminsky was a whip to frighten the crowds with. Between actually adding in a bit more entropy in the request through 0x20 and port randomization, and more importantly cleaning up the glue policy for recursive resolvers (which Unbound did), you close the door on off-path attackers: both making races harder AND eliminating the race until win property. i wish this were so. but 0x20 didn't add enough bits on average-sized names, and furthermore, a lot of RDNS servers are behind NAT. (CGN is a reality, in japan.) NAT's source port derandomization is as dangerous as we thought. far too many RDNS servers were never patches, or were patched but NAT'ed. so we'll keep pushing the crap system we have, uphill all the way, noone loving it, and almost everyone in fact hating it. we've now spent more calendar- and person-years on DNSSEC than was spent on the entire IPv4 protocol suite (including DNS itself) as of 1996 when the DNSSEC effort began. ugly, ugly, ugly. At which point is it sunk cost fallacy? it always has been. we needed end-to-end authentication, because of bullshit like SOPA, and ad-insertion, and DNS Changer. the DNS resolution path looks like raw meat for the BBQ's of every ISP and many ASP's and governments and criminals and oh my. but DNSSEC was the wrong answer, architecturally, because it tried to secure the middle of the data path rather than the ends, and no dnssec-aware endpoint can get DNSSEC if they are behind a non-dnssec-aware RDNS or CPE. it's been an inarguable clusterfsck for the last ten years. we are so far into the sunk cost fallacy on DNSSEC that we can't even see or remember our starting conditions any more. DNS is insecure, live with it may be the best answer. Why keep throwing good effort after bad? it's not, though, the best answer. we have to secure the DNS resolution path. what's in doubt is whether DNSSEC can do this, or if it can, whether it's the best way to have done this. It certainly is a hell of a lot better than the DOS attack that is recursive resolver validation which provides almost no meaningful security gain. don't get bent about dnssec as an amplifier. TXT is also a fine amplifier. but in many DDoS victim data paths, the bottleneck is defined in terms of number of packets processed, not the number of bits processed, so a non-amplifying reflector is still quite valuable to attackers. even an attenuator at the bit level is quite valuable. (an attenuator at the packet level is not valuable to attackers, which is why RRL uses SLIP=2 as a default.) in other words we had to, and still have to, solve the reflector problem -- with or without DNSSEC. andrews/eastlake dns cookies will do that. and once we've done that, DNSSEC as a DoS vector will be just another dead meme. If I was Comcast, after the HBO DNSSEC mess-up, on top of previous mess-ups where Comcast inevitably gets the blame, I'd be really really tempted to turn OFF DNSSEC validation. It has failed. i know what you mean and i'd face the same temptation. i wonder if there has ever been a validation failure in the comcast resolver complex that wasn't due to a keying/signing cockup by the domain holder -- that is, if comcast has to have negative trust anchors to protect its validation investment, what's the upside? could they defend their users just as well by not running validation at all, so that keying/signing problems don't have to be managed by the comcast NOC? what matters for DNSSEC is the end-to-end case. as long as comcast is running DNSSEC-aware resolvers, they don't need to validate anything in order to make DNSSEC applications like DANE workable for their customers. and i'd rather see them turn off validation than see negative trust anchors added to the specification. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Hi, DNS is insecure, live with it may be the best answer. Why keep throwing good effort after bad? it's not, though, the best answer. we have to secure the DNS resolution path. Probably a terminology issue, but I think we need to secure the data, not the resolution path. I'm not a particular fan of DNSSEC for a number of reasons, however what the Kaminsky thing demonstrated to me was that as long as the data is not protected, there are going to be path-based attacks that are going to allow for compromise. I see DNSSEC as a way of being able to stop playing whack-a-mole with those path-based attacks. i'd rather see them turn off validation than see negative trust anchors added to the specification. Simply: I believe without NTAs, DNSSEC will not get deployed except by a few 'true believers'. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mar 15, 2015, at 6:14 AM, Mark Andrews ma...@isc.org wrote: Can we kill this myth that recursive servers do not need to validate because they do need to validate for DNSSEC to work reliably. DNSSEC only work without validation in the middle if no one is spoofing, dropping RRSIGs etc. The moment there is anything other than only good answers being cached things will go wrong. +1 Of course, what goes wrong is that the response can't be validated, so DNSSEC is still doing its job, but it can prevent cache poisoning if validation is done in the cache, and cannot if it is not. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mar 13, 2015, at 7:59 PM, Paul Vixie p...@redbarn.org wrote: Nicholas Weaver Saturday, March 14, 2015 5:07 AM ... Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good. several of us jumped for joy in 2008 when kaminsky showed rdns poisoning to be a trivial exercise, because it finally provided justification for what was at that time 12 years of apparently-wasted effort on DNSSEC. But it didn't justify DNSSEC, even at the time. Between actually adding in a bit more entropy in the request through 0x20 and port randomization, and more importantly cleaning up the glue policy for recursive resolvers (which Unbound did), you close the door on off-path attackers: both making races harder AND eliminating the race until win property. In fact, several have viewed the glue policy cleanup which gets to the root cause of the Kaminski problem as detrimental specifically because of the desire to force DNSSEC adoption. so we'll keep pushing the crap system we have, uphill all the way, noone loving it, and almost everyone in fact hating it. we've now spent more calendar- and person-years on DNSSEC than was spent on the entire IPv4 protocol suite (including DNS itself) as of 1996 when the DNSSEC effort began. ugly, ugly, ugly. At which point is it sunk cost fallacy? DNS is insecure, live with it may be the best answer. Why keep throwing good effort after bad? It certainly is a hell of a lot better than the DOS attack that is recursive resolver validation which provides almost no meaningful security gain. If I was Comcast, after the HBO DNSSEC mess-up, on top of previous mess-ups where Comcast inevitably gets the blame, I'd be really really tempted to turn OFF DNSSEC validation. It has failed. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mar 13, 2015, at 10:21 AM, Morizot Timothy S timothy.s.mori...@irs.gov wrote: It’s been steadily increasing for years now and gives me an idea what percentage of the US public is protected against certain types of attacks involving our zones. DNSSEC validation is not a panacea, but in a layered approach toward combating fraud and certain sorts of attacks, it does provide a particular sort of protection not available through any other means. Whether or not ISPs sign their authoritative zones matters much less to us than whether or not they implement DNSSEC validation on their recursive nameservers. And that’s not a failure at all. By the measure above (which isn’t perfect, but the best one available) roughly a fifth to a quarter of the US public, the primary consumers of our zones, exclusively use validating nameservers. That’s significant. Would I like to see it higher? Sure. But I’ll take it. The problem is validation by the recursive resolver is nearly useless for security, but one heck of an effective DOS attack (NASA, HBO, etc)... Lets look at what real world attacks on DNS are. a: Corrupt the registrar. DNSSEC do any good? Nope. b: Corrupt the traffic in-flight (on-path or in-path). DNSSEC do any good? Only if the attacker is not on the path for the final traffic, but just the DNS request. c: The recursive resolver lies. Why would you trust it to validate? d: The NAT or a device between the recursive resolver and the user lies. Again, validation from the recursive resolver works how? Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Nonsense. I'm not sure exactly what sort of attack profile you have in mind at the registrar with a, but given that the TTL for DS records is generally 24 hours, most attacks at that level will create pretty widespread DNSSEC validation errors for at least that initial day. DNSSEC validation helps a great deal. B d are issues securing the first hop if validation is not done on the endpoint itself. Those are valid, but do not mean that DNSSEC validation provides no protection. It certainly protects against an array of cache poisoning attacks even in that configuration. And that's protection the clients would not otherwise have. It definitely makes it a lot harder to use DNS as an attack vector with nobody noticing. One layer of a layered approach. C is certainly a problem if you don't validate on the end point and trust any random nameserver on any network to which you connect. However, most enterprise clients and ISP users do tend to have a reliable and reasonably secure path to their first hop recursive nameserver. It's not nearly as secure as validating on the client, but it's much more secure than having no validation whatsoever. Nor is DNSSEC validation a DOS vector. That's a non sequitur and frankly a pretty silly assertion. Yes, an organization can break their own authoritative DNS (which is related to signing not validation), but frankly DNSSEC is just one of many ways an organization can screw up DNS or anything else in their network. It's best to know what you're doing. Organizations will learn. If you haven't implemented DNSSEC validation yourself, you may not have noticed, but US government agency management of DNSSEC has improved greatly with experience. Outages due to error are less and less common and usually limited in scope when they occur. Since we've been validating all Internet responses for four years and counting now (and tend to interact quite a bit with other agencies), we have noticed the improvement. Refusing to return results when the authoritative DNS response fails validation is good thing, not a bad thing, even when it's the authoritative zone administrators who screwed up their own zone. DNSSEC validation is not a panacea, but if you refuse to implement it you are denying your users one layer of protection you could pretty easily provide. And given that in the US the large majority of federal agency DNS authoritative zones are signed, you also can't claim there's no benefit to the US public from validation. Implementing validation on recursive nameservers does not protect users from every attack. Nothing does. Nor is it as good as performing validation at the client. But it is a solid first step with real security benefits. And it's a step that can be followed and built upon with further enhancements later. Scott -Original Message- From: Nicholas Weaver [mailto:nwea...@icsi.berkeley.edu] Sent: Friday, March 13, 2015 3:08 PM To: Morizot Timothy S Cc: Nicholas Weaver; dnsop@ietf.org Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards On Mar 13, 2015, at 10:21 AM, Morizot Timothy S timothy.s.mori...@irs.gov wrote: It’s been steadily increasing for years now and gives me an idea what percentage of the US public is protected against certain types of attacks involving our zones. DNSSEC validation is not a panacea, but in a layered approach toward combating fraud and certain sorts of attacks, it does provide a particular sort of protection not available through any other means. Whether or not ISPs sign their authoritative zones matters much less to us than whether or not they implement DNSSEC validation on their recursive nameservers. And that’s not a failure at all. By the measure above (which isn’t perfect, but the best one available) roughly a fifth to a quarter of the US public, the primary consumers of our zones, exclusively use validating nameservers. That’s significant. Would I like to see it higher? Sure. But I’ll take it. The problem is validation by the recursive resolver is nearly useless for security, but one heck of an effective DOS attack (NASA, HBO, etc)... Lets look at what real world attacks on DNS are. a: Corrupt the registrar. DNSSEC do any good? Nope. b: Corrupt the traffic in-flight (on-path or in-path). DNSSEC do any good? Only if the attacker is not on the path for the final traffic, but just the DNS request. c: The recursive resolver lies. Why would you trust it to validate? d: The NAT or a device between the recursive resolver and the user lies. Again, validation from the recursive resolver works how? Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Thu, Mar 12, 2015 at 4:09 PM, Mark Andrews ma...@isc.org wrote: In message 3d558422-d5da-4434-bded-e752ba353...@flame.org, Michael Graff writes: What problem are we specifically trying to solve here again? A non-problem for most of us. Michael If one really wants to reduce the number of packets required with SMTP processibg just write a RFC that says A and records should be returned in the additional section if no MX records exist at the qname. This is currently permitted so vendors could do this today. For some data; Route 53 does do this for MX, NS, SRV and CNAME. It's never been a problem, and does seem to speed up processing a little. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Nicholas Weaver mailto:nwea...@icsi.berkeley.edu Saturday, March 14, 2015 5:07 AM ... Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good. several of us jumped for joy in 2008 when kaminsky showed rdns poisoning to be a trivial exercise, because it finally provided justification for what was at that time 12 years of apparently-wasted effort on DNSSEC. you're entirely right that the end-system case (for example, DANE) is the only actual justification for the added costs and risks of Secure DNS, and you'd be right if you said that the current system is both over- and under-engineered for this sole actual use case. because it takes so many years to get everybody's permission to make any change to the DNS protocol, and so many more years to get everybody's permission to make any change of this magnitude to the root zone, the cost of giving up and starting over necessarily includes not just the tear-down but the re-negotiation. not practical. so we'll keep pushing the crap system we have, uphill all the way, noone loving it, and almost everyone in fact hating it. we've now spent more calendar- and person-years on DNSSEC than was spent on the entire IPv4 protocol suite (including DNS itself) as of 1996 when the DNSSEC effort began. ugly, ugly, ugly. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
I remain puzzled at the entire technological motivation that CloudFlare claims for this deliberate creation of interoperability problems. In particular, what exactly is the programming difficulty that they claim they're encountering in implementing QTYPE=*? Are they also having trouble implementing NXDOMAIN, which from a programming perspective is a very similar unification of data across all types? The rest of this message identifies specific rules that CloudFlare's threatened plan will violate in IETF's mandatory DNS standards. David C Lawrence writes: RFC 1035 explicitly allows for a server to indicate that a kind of query is not implemented. Whether it is a good idea to respond to ANY this way is a separate argument that is worth having. You just won't win on the foundation that it is a violation of the standard. Let's look at what the standards actually say. RFC 1034 clearly defines QTYPE=* to match all RR types, along with, e.g., QTYPE=A to match just that type. It explicitly says that the name server looks for matching RRs. CloudFlare's stated plans will violate this rule. This matching for QTYPE=* is precisely what CloudFlare claims is too hard to implement! You claim that this violation of a rule in IETF's mandatory DNS standards doesn't constitute a violation of the standards. Evidently you believe that the standards contain some relevant exception to the rule. What exactly do you claim that this exception is? The foundation for your argument, apparently, is the fact that RFC 1035 defines a syntax for a NOTIMP response. But why do you think this is of any relevance to the matching RRs rule? The rule doesn't say the name server looks for matching RRs, except for types that the server doesn't want to bother implementing. Where exactly, and what exactly, is the CloudFlare exception? Do you believe that the availability of a NOTIMP syntax overrides all other rules and frees the server to use this syntax for anything that it doesn't want to implement? Here's a hypothetical example to consider: * A very large cache operator is opposed to the usage of DNSSEC. (The operator's reason for this isn't relevant to this example.) * To deter usage of DNSSEC, the cache operator decides to create large-scale DNSSEC interoperability problems, augmenting DNSSEC's existing fragility. * Specifically, the cache operator issues DNSSEC queries to servers; and then, if a server response shows DNSSEC support, the cache operator returns NOTIMP to clients for _all_ of the server's data. * To avoid any sudden changes, the cache operator slowly ramps up this behavior, turning on the DNSSEC queries with higher and higher probability as time passes, but jumping immediately to probability 1 for servers that don't show DNSSEC support. * To justify the use of NOTIMP, the cache operator claims that it _wanted_ to implement actually returning DNSSEC records to clients but found this too complicated given geoip blah blah blah, so it had to return NOTIMP. It quotes your claim that RFC 1035 explicitly allows returning NOTIMP. Would you call this cache behavior compliant with the mandatory DNS standards? No? Why not? Why isn't the cache free to use NOTIMP whenever it hasn't implemented something? Are you quite sure that you've thought through what you're claiming? Let's continue looking at the mandatory DNS standards. RFC 1034 explicitly allows not-implemented queries in _some_ cases, such as inverse queries: Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return a not-implemented error response. RFC 1035 is also quite clear about this: Inverse queries are an optional part of the DNS. Name servers are not required to support any form of inverse queries. If a name server receives an inverse query that it does not support, it returns an error response with the Not Implemented error set in the header. While inverse query support is optional, all name servers must be at least able to return the error response. If the RFCs had meant to say that _all_ DNS features are optional (leaving interoperability up to the whim of bullies, apparently what you're endorsing), then why didn't the RFCs simply say that? Why did they explicitly highlight particular features as being optional? Furthermore, RFC 1123 explicitly requires DNS software to support all well-known, class-independent formats. This is another mandatory rule that CloudFlare's plan clearly violates. What exactly do you think this support requirement means, if servers are free to use NOTIMP whenever they want, for example for QTYPE=*? RFC 1034 explicitly says that a server is free to refuse to perform recursive services for any or all clients (and also explicitly says that an AXFR may cause an error, such as refused) but explicitly says that All name servers must
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior -- Section 3.7.1 says only that a QTYPE of * matches all RR types, whereas Section 5.3.3 (Algorithm) says to return the answer or the data if it's in the cache, but this is ambiguous with respect to QTYPE=* (other than the highly-improbable case that we have RRsets for every possible RR type, how can we know we have the answer/the data in our cache, given that the QTYPE matches all RR types at the node and there might be other RRsets extant which don't happen to be cached at the time? Is an answer really the answer if we can't be sure that it satisfies the matching rule of the QTYPE definition?). People cite the examples of Section 6.2.2 as definitive evidence that QTYPE=* queries can always be satisfied by whatever happens to be laying around in a cache, but they don't seem to notice that those were *non-recursive* queries in the examples, and it's their *non-recursiveness* that gives rise to the lack of rigor in returning a response (as it is whenever a non-recursive query is sent to a DNS entity that doesn't happen to be authoritative for the relevant zone). The required fetching behavior of a caching resolver in response to a *recursive* QTYPE=* query, is basically undefined by RFC 1034. Common practice is to treat QTYPE=* queries as effectively non-recursive, despite RD being set to 1, if *any* relevant RRset exists in the cache. Possibly, this is because the Section 6.2.2 examples were misunderstood. Or, simply because it was easier to code that way. A more modern concern would be that this rigor could be abused for possible DoS attacks. But, at this point in DNS histor y, I doubt we can roll back the clock and force everyone to be rigorous in fetching answers for QTYPE=* queries. So the answers are inherently unreliable, and that situation is not likely to change, unless and until someone invents an ALL QTYPE/RR-type/meta-type. - Kevin -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Wouters Sent: Monday, March 09, 2015 10:48 AM To: D. J. Bernstein Cc: dnsop@ietf.org; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards On Mon, 9 Mar 2015, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. And you've been told for two decades that this was wrong? Specifically, query type ANY matches all RR types for that node on that server. Wrong, query type ANY matches all RR types CURRENTLY IN THE CACHE. So the result of qmail's ANY query is completely meaningless and qmail cannot derive any conclusion from the absence of any record from that query. So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. qmail with this feature is broken. Additionally, Tony Finch did a write up of qmail's ANY problems too: https://fanf.livejournal.com/10.html In new software today I would sacrifice these efficiency benefits for the sake of simplicity, but this doesn't mean that I'm going to frivolously inflict retroactive punishment upon administrators who have installed standards-compliant software and done nothing wrong. You have had 10 years to fix it. Luckilly, I believe most distributions shipping qmail add the patch to fix this already. I understand how a sufficiently large site might acquire the impression that it can safely take radical action at its own whim, violating the existing protocol standards Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not need to interop with BIND4 anymore. Apparently Firefox recently deployed ANY queries. I haven't looked at the details but I gather that they're related to the well-known annoyances of handling etc. Firefox was browbeaten into reverting this change on the basis of highly questionable claims regarding amplification: It can return enormous result sets, and some authoritative servers have taken to refusing ANY queries because of the frequency with which such queries show up in amplification attacks - I'm concerned about amplification and the perception thereof by security monitors. No, they were also told that ANY queries only return data from the cache, and using ANY queries means you might miss actual A or records. This has nothing to do with ANY queries and amplification. The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Paul Wouters writes: So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. The client is behaving correctly. The ANY query isn't guaranteed to find the MX, but you're wrong in claiming that the client is relying on this. I realize that you don't understand how this type of DNS client works, so let me go through the details, slowly, covering (1) why the queries reliably produce the desired information and (2) why QTYPE=ANY ends up reducing the number of queries that the authoritative server has to handle for producing this information. The client begins with an ANY query to the cache. There are several possibilities for the cache state at this moment: * maybe there's nothing; * maybe there's an MX record; * maybe there's an A record; * maybe there's some other regular record, such as NS; * maybe there's a mix of regular records; * maybe there's a CNAME record; * etc. In the nothing case, the cache forwards the query to the server. This could end up retrieving, e.g., an MX set, an A set, and an NS set; it could end up retrieving a CNAME; there are many possibilities. The cache then returns whatever it has to the client. The client notices failure cases (such as SERVFAIL) and, in those cases, defers mail delivery. Let's now focus on what happens in the success cases. If the cache returns a CNAME: The client sees the CNAME, replaces the original name with the CNAME, and starts over. If the cache returns, e.g., an NS record: The client sees this record and concludes that there _isn't_ a CNAME. This conclusion is justified by the rule that a name can't have CNAME together with regular records. An administrator who sets up a single name with both CNAME and NS (or CNAME and MX, etc.) is entirely at fault for the resulting confusion. The client then sends an MX query to the cache. Again failures are caught and defer mail delivery. The most common success case is that the cache has an MX set at this point; the client sees the MX set and acts accordingly. (The A that the MX points to is normally cached too.) If there's a successful response without an MX (case 5 described in http://cr.yp.to/djbdns/notes.html#response-parsing) then the client correctly concludes that there isn't an MX and falls back to an A query for the original name. To summarize, this type of ANY-MX-A client correctly sees whether there's a CNAME, correctly sees whether there's an MX, and (when there isn't an MX) correctly sees whether there's an A. If there's a server failure (e.g., NOTIMP) or cache failure, the client correctly defers mail delivery. A comprehensive efficiency analysis requires detailed measurements for many years at many sites, but spot checks have consistently shown that the following cases are most important: * Most common: MX in server and in cache. The ANY-MX-A client ends up generating 0 queries to the server: the cache answers ANY with MX, and answers MX with MX. For comparison, a CNAME-MX-A client would also end up sending 0 queries to the server _if_ the cache were smart enough to use the MX as a reason to deny CNAME. But typical caches aren't that smart, so this type of client would end up sending 1 query to the server. An MX-A client uninterested in CNAME would end up sending 0 queries to the server. * MX in server but not in cache. The ANY-MX-A client ends up generating 1 query to the server: the server answers ANY with MX (and typically A), and then the cache answers MX with MX. For comparison, a CNAME-MX-A client would end up generating 2 queries to the server: the server answers CNAME with no data, then answers MX with MX. An MX-A client uninterested in CNAME would end up sending 1 query to the server: the server answers MX with MX. * A in server and in cache, no MX in server: The ANY-MX-A client ends up sending 1 query to the server. The cache answers ANY with A; the server answers MX with no data; the cache answers A with A. For comparison, a CNAME-MX-A client would end up generating 2 queries to the server (or 1 if the cache is smarter): the server answers CNAME with no data; the server answers MX with no data; the cache answers A with A. An MX-A client uninterested in CNAME would end up sending 1 query to the server. The server answers MX with no data, and the cache answers A with A. * A in server, nothing in cache: The ANY-MX-A client ends up sending 2 queries to the server. The server answers ANY with A; the server answers MX with no data; the cache answers A with A. For comparison, a CNAME-MX-A client would end up generating 3 queries to the server: the server answers CNAME with no data; the server answers MX with no data; the server answers A with A. An MX-A client uninterested in
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Packet size is harder to analyze. ANY often pulls some records that aren't used, and if the site isn't configured carefully then ANY can even end up falling back to TCP, costing bytes _and_ packets. On the other hand, there are a huge number of Internet sites that don't have a noticeable volume of unusual records and don't need TCP, and there's a clear traffic win for every skipped query and skipped no-data response. My guess is that with DNSSEC, this will be common, as often times the domain apex is where the email would be sent. For my personal domain, that’s @flame.orghttp://flame.org, and weighs in at 1758 bytes to an ANY query right now. Once this is done, the MX target then needs to be followed of course (or targets in the case of a failure to connect.) In the following, I’m using ESND0. If this isn’t true, we all know anything 512 bytes as a response was a TCP hit. I’m not as scared of TCP hits as others may be, but I do think they should be avoided when practical. ANY comes in as 1769 with or without DNSSEC. Had it asked for the MX directly, it would have gotten 60 bytes without DNSSEC, and 229 with. If there was no MX record, I assume then another query would be issued for the and A records. That’s two more queries, but both of which would be smallish in comparison to the ANY query. The DNSSEC keys nearly always dominate ANY queries at the apex. I’m happy we are discussing issues with ANY queries, and the fairly small number of clients that use them. I would have to see hard numbers collected over a lot of data showing where the ANY query was actually better than following the MX, , A path. Until data is collected from how people set up zones today, I’m not sure I can say one is better than the other, other than as a feeling that it might help reduce queries but I’m not sure it reduces bandwidth. What problem are we specifically trying to solve here again? —Michael ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior It is sort-of specified in the algorithm in section 4.3.2 which says, 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. That applies to RD=0 queries. For RD=1, section 5.3.3 says, 1. See if the answer is in local information, and if so return it to the client. This is usually understood to mean what you would get from an RD=0 query. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Northwest Fitzroy, Sole: Southwesterly, backing southeasterly for a time, 4 or 5 increasing 6 to gale 8. Moderate or rough, becoming very rough later in west. Occasional rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mar 9, 2015, at 10:54 AM, Tony Finch d...@dotat.at wrote: D. J. Bernstein d...@cr.yp.to wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. There are three bugs in the way qmail uses ANY queries. (1) qmail uses ANY queries for domain canonicalization on outgoing messages, as specified by RFC 1123. But canonicalization is not required by the current SMTP specification. It is a waste of time. Fixing this bug would make bug (3) moot. (2) qmail's DNS response buffer is too small to accommodate a complete DNS message, so it fails if it gets a large response. It uses the low-level libc resolver API which can easily handle large responses, including fallback to TCP, so it is a pity that qmail breaks this part of the resolver's functionality. This bug means it is not guaranteed to work. (3) Using an ANY query suppresses alias processing, so qmail makes a series of queries to follow CNAME chains. This is inefficient and wasteful. If you make an A or MX query, the DNS server will chase the CNAME chain for you, so you only need to make one query to get the canonical name. Even ignoring if qmail is “broken”. (I would rather classify it as, could do better), depreciating the ANY qtype is going to have some significant side effects of users troubleshooting DNS problems. I’m very sensitive to the abuse of ANY queries, but this is something that I feel there are sufficient controls that exist to mitigate the issues, namely using TC=1 to direct well behaving clients to receive a valid response. dnsop-any-notimp violates the principle of least surprise in technology by returning NOTIMP where Paul Vixie suggested NOERROR/ANCOUNT=0 would be more appropriate with the existing definitions. Much of this is triggered by bad coding practices and bad networking examples that are littered around codebases, e.g.: gethostbyname() vs getnameinfo() and by broken behaviors by nscd and other OS/LIBC implementations that also violate the principle of least surprise. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mar 9, 2015, at 11:16 AM, Edward Lewis edward.le...@icann.org wrote: On 3/9/15, 7:08, D. J. Bernstein d...@cr.yp.to wrote: The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying is not that query type ANY is the ultimate answer (clearly it can be improved); what I'm saying is that these are protocol issues, and that protocol changes need to be handled by an appropriately chartered IETF working group. (I removed the dns-operations list from this because this needs to be discussed on DNSOP.) Dan, You're right. But. Operators are not bound to comply with what the IETF documents. As much as operators shouldn't bully the IETF nor the public for which the serve, the street goes two ways. The IETF is not able to and should not bully them. The IETF is supposed to provide us with an interoperable way to operate and is supposed to have documents that reflect running code.” I would be interested in hearing the results you had from disabling ANY queries, or anyone else results. This isn’t standing in opposition to change, but trying to understand the true scope and nature of this problem. Perhaps I’m missing parts of the problem, but the qmail issue has existed for 10 years. Firefox recently turned on and back off ANY queries in 36.0 and 36.0.1 to try to keep performance what it should be for websites that have low TTLs vs being ‘sticky’ to an old A/ record. * Second: The merits of the protocol modification have to be properly discussed in that working group, to evaluate the costs and benefits of the protocol modification---and to consider whether there are better ways to achieve the same benefits. If operators find that a protocol needs to be modified to be properly operated, the IETF ought to adjust the protocol definition. Having a migration path would be a plus too. (Said tongue in cheek.) But - finding that a protocol needs to be modified is not as easy as that - hence my quoting of your words above. I’m concerned a change of this sort will cause a number of people to see something as ‘broken’ where it really is not. If we are dealing with code that will break things for existing users, giving them broad warning is important, even if they are using/abusing this capability of the DNSs system today. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On Mon, Mar 09, 2015 at 11:08:03AM -, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. Hi Dan, The way I read RFC 1034 4.3.2, this is not true. In step 4 we match whatever we find in the cache, put it in the packet, and move on to step 6. This means the algorithm might terminate returning only an A record or only an record. Or a TXT record for that matter. This reading of 4.3.2 makes 'ANY' queries to resolvers fragile. It might not return what you need. Do you think I read 4.3.2 wrong? Or is there another RFC that updates the algorithm? Bert ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On 3/9/15, 7:08, D. J. Bernstein d...@cr.yp.to wrote: The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying is not that query type ANY is the ultimate answer (clearly it can be improved); what I'm saying is that these are protocol issues, and that protocol changes need to be handled by an appropriately chartered IETF working group. (I removed the dns-operations list from this because this needs to be discussed on DNSOP.) Dan, You're right. But. Operators are not bound to comply with what the IETF documents. As much as operators shouldn't bully the IETF nor the public for which the serve, the street goes two ways. The IETF is not able to and should not bully them. The IETF is supposed to provide us with an interoperable way to operate and is supposed to have documents that reflect running code. * Second: The merits of the protocol modification have to be properly discussed in that working group, to evaluate the costs and benefits of the protocol modification---and to consider whether there are better ways to achieve the same benefits. If operators find that a protocol needs to be modified to be properly operated, the IETF ought to adjust the protocol definition. Having a migration path would be a plus too. (Said tongue in cheek.) But - finding that a protocol needs to be modified is not as easy as that - hence my quoting of your words above. Ed Lewis smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Jared Mauch ja...@puck.nether.net wrote: Even ignoring if qmail is “broken”. (I would rather classify it as, could do better) Yes. dnsop-any-notimp violates the principle of least surprise in technology by returning NOTIMP where Paul Vixie suggested NOERROR/ANCOUNT=0 would be more appropriate with the existing definitions. This would have the amusing effect of disabling qmail's address canonicalization without patching qmail. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin: Cyclonic in north Rockall at first, otherwise westerly or southwesterly severe gale 9 to violent storm 11, decreasing 5 or 6. High or very high, becoming very rough. Squally showers. Good, occasionally poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
bert hubert bert.hub...@netherlabs.nl wrote: On Mon, Mar 09, 2015 at 11:08:03AM -, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. The way I read RFC 1034 4.3.2, this is not true. In step 4 we match whatever we find in the cache, put it in the packet, and move on to step 6. This means the algorithm might terminate returning only an A record or only an record. Or a TXT record for that matter. This reading of 4.3.2 makes 'ANY' queries to resolvers fragile. It might not return what you need. Dan is aware of that, but this particular oddity isn't a problem for qmail. Later in his message he wrote: Of course, there's no guarantee of which RR types for a node are available at a cache, but a client is guaranteed to be able to detect CNAME records from responses to query type ANY (as qmail does), since a CNAME type prohibits all regular RR types. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle: Southeast veering west, severe gale 9 to violent storm 11. Very rough or high, becoming very high for a time. Rain then showers. Moderate or poor, becoming good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Edward Lewis writes: Operators are not bound to comply with what the IETF documents. As I said before, this is making a mockery of the IETF standardization process. Instead of * obeying the existing mandatory standards, * giving due respect to the installed base relying on the standards, * trying to build consensus for a transition that demands action from the installed base, and * taking the slow steps necessary to maintain interoperability during a transition if any transition happens, a large operator is using its market position to violate the standards and _create_ interoperability failures as a tool to enforce a protocol change that it wants. Furthermore, a few weeks before this standards violation is going to be deployed, the stated rationale for the change is undergoing massive revisions, making serious discussion difficult and leading observers to wonder how carefully the change was thought through in the first place. If you want IETF standards to be taken seriously---if you think that the basic rules of Internet communication should be established by consensus in IETF, and not simply overridden by future developers and operators who think they know better, including cases where you _don't_ agree with them---then you have to stop endorsing standards violations. Tony Finch writes: qmail uses ANY queries for domain canonicalization on outgoing messages, as specified by RFC 1123. But canonicalization is not required by the current SMTP specification. It is a waste of time. I fully agree that this was made optional in SMTP---that qmail is no longer required to do this. But how do you leap to the wild conclusion (stated twice in your message) that this is a bug in qmail? More importantly, why do you think this is relevant to anything that I said? I didn't say that qmail's behavior is currently required for SMTP. I said that qmail is very widely deployed and relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. The dnsop-any-notimp proposal ignores those standards and will create real interoperability problems with mail delivery. Using an ANY query suppresses alias processing, so qmail makes a series of queries to follow CNAME chains. This is inefficient and wasteful. No, you have the efficiency picture backwards. CNAME chains have always been an extremely small fraction of the DNS queries inside mail, while the QTYPE=ANY side effect of preloading MX/A records has always produced a significantly larger reduction in DNS queries. This item is something else that you explicitly label as a bug. You keep using that word; I do not think that word means what you think it means. qmail's DNS response buffer is too small to accommodate a complete DNS message, so it fails if it gets a large response. Precisely how many bytes do you believe are in a complete DNS message? 65535, the TCP limit? Do you seriously believe that 65535-byte responses work reliably today, and that any failure to handle such responses is a bug? How about 512, given the fact that the mandatory DNS standards do _not_ require TCP support? Or maybe 1280, the recommended safe size for EDNS0 UDP (depending on the network etc.)? Even in an imaginary world where 65535-byte responses work, what do you think happens if a server administrator puts _more_ than 65535 bytes of records at a single node? Do you blame the server administrator? If DNS implementors handle this use case by introducing a DNS transport capable of handling 4-gigabyte responses, will you then claim that there's a bug in every DNS client that has less RAM available or that simply insists on a smaller limit to control its resource use? In fact, all DNS client and server deployments have size limits on DNS responses, and these limits have always varied, making the system as a whole increasingly fragile for the unfortunate administrators pushing the limits (notably DNSSEC administrators). The only sane way out is for the protocol to declare a single reasonable size limit to be respected by all clients and servers---but this implies reengineering large DNS record types to split data across nodes (the same way that TCP splits streams across packets), and nobody seems willing to do this work. It's much easier to stuff all data into one node, pretend that the system works, and blame the administrators for all of the resulting failures. I'd be happy to discuss this issue further if anyone is interested in fixing these aspects of the DNS protocol. I would, however, suggest starting a separate thread for that, since this really isn't relevant to how dnsop-any-notimp violates the DNS standards. ---Dan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
My 2 cents... It is commonplace, these days, to clearly enumerate MANDATORY TO IMPLEMENT elements of a protocol specification. But, this was not the typical practice at the time RFCs 1034/1035 was written, and I don't think we can apply modern standards-parlance retroactively. RFC 1034/1035 certainly marked some protocol elements as optional or experimental, e.g. - inverse query opcode (optional) - the MG, MINFO, MR and NULL RR types (experimental) - negative-caching via the inclusion of an SOA RR in the Additional Section of the response (optional) yet, none of the QTYPEs defined in the RFCs are so labelled. In the face of such circumstantial evidence, I would say that conformance to RFCs 1034/1035 requires implementation, to some degree, of all QTYPEs defined in those RFCs, That, to me, is a reasonable reading of the document. RCODE=NOTIMP exists, ergo any/all QTYPEs which aren't also RR types[1], are optional to implement is not, IMO, a reasonable reading, but admittedly, the MANDATORY TO IMPLEMENT construct probably came into vogue in the first place, to forestall any such shaky interpretations. Now, having said that, I think it would be standards-conforming for an implementation to always answer with RCODE=REFUSED, always answer with NODATA, or to pick only certain RR types, more-or-less arbitrarily, (e.g. A and ) and only answer with RRs matching those RR types (as a way to minimize the amplification effect), in response to QTYPE=* queries. None of those would be violations of the standard, which in no way usurps local administrative control over what queries get substantive responses, versus those which do not, nor commits an implementation to rigorously tracking down *every* RRset owned by the QNAME of a given QTYPE=* query. But, I have to agree with Dan: NOTIMP in response to QTYPE=* is not standards-conforming. As for his meta-argument that DNSOP cannot make changes to the protocol, I'm still mulling that one over, in light of the charter language. - Kevin [1] The reason for the which aren't also RR types qualification is that RFC 1123, Section 6.1.3.5 states that DNS software MUST support all well-known, class-independent formats [sic]. While 1123 is silent on QTYPEs, _per_se_, at least the set of [QTYPEs that are also well-known, class-independent RR types], as of the date of 1123's publication, fall within mandatory-to-implement, and there is no need to debate over those. -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of David C Lawrence Sent: Monday, March 09, 2015 12:24 PM To: dnsop@ietf.org; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards RFC 1035 explicitly allows for a server to indicate that a kind of query is not implemented. Whether it is a good idea to respond to ANY this way is a separate argument that is worth having. You just won't win on the foundation that it is a violation of the standard. ___ 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
