Re: [dns-operations] [DNSOP] 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 ___ 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] question for DNS being attacked
Yes, but also this. (expanded from feel) It may also make Kaminsky style attacks easier if an attacker can blind an auth server from handing out responses. If the counter values are real from the RFC style paper, every other response becomes a truncated reply in a flood situation. This will extend the attack window by the time it takes to establish a TCP connection and query, or to the time it takes to retransmit the query plus TCP handshake if the blinding is successful. This assumes the second query works. But in reality it has the same chance as the first. Assuming about 100ms for TCP handshake and two seconds for timeout and retry followed by the TCP handshake, This means the window for potential false responses moves to about 1100ms on average. If a UDP reply would normally make it to the server in 100 ms, this opens a window 11 times as wide. This simple math only accounts for one server, however. Someone with better probabilistic skills than I have, at 1:30am, should do the math with more than one server, and include the attack probably as well. --Michael On Jun 28, 2012, at 1:15, pangj pa...@riseup.net wrote: Even with the slip values, I still feel this can open a wider window for other forms of attacks against a DNS zone. For example, the attacker spools with a legetimate IP and make a number of queries, thus RRL blocks that legetimate IP by mistake? -- Email/Jabber/Gtalk: pa...@riseup.net Free DNS Hosting with www.DNSbed.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
Re: [dns-operations] question for DNS being attacked
On Jun 28, 2012, at 9:06 AM, Vernon Schryver wrote: That conclusion does not hold, because it does not define the narrow window alternative. 11 times as wide as what? With a slip factor of 2, every other packet will be dropped, and the other packets returned will have the truncated bit set. If this is incorrect, please explain what it does do. This translates to a normal truncated response 50% of the time, and a timeout the other 50%. Ignoring the penalty BIND 9 and other servers are likely to assign to this misbehaving server, the timeout keeps the Waiting for a response window open much, much longer. This timeout is largely server-dependent, and some may wait multiple seconds. This leaves the window open for a spoofing flood attack to sneak in. While I commend you and Paul on the RLL work you've made, I think it is improper to not mention this in the documents you write. It may be not a big deal to the administrator of the zone, but it is up to them to decide that. Some may prefer to be a flooding source rather than make their zone more prone to spoofing, even if the actual odds are low. The biggest problem here is that the zone publisher's goals of not being spoofable are entirely dependent on the resolver asking the questions, without DNSSEC in the mix. --Michael ___ 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] question for DNS being attacked
On Jun 28, 2012, at 1:37 PM, Vernon Schryver wrote: A separate aspect of this supposedly much, much longer window is that it seems to assume that after the client has received a truncated or TC=1 response and is going through the DNS/TCP dance, it will still accept forged, evil DNS/UDP responses from the attacker. Is that true of common resolving servers and resolver libraries? It's not how I'd write a resolver. Instead I'd discard all of the state needed to accept apparently stale UDP responses before the TCP SYN is sent. Please correct me if I misunderstand the following statement. A slip rate of 2 drops 50% of the outgoing answers for a specific tuple, and returns a truncated response for the other 50%. If I do not understand that behavior, ignore the rest of the message and I'll re-evaluate my concerns. Also, is the default slip rate 2? If that is the case, then if a legitimate query comes into an auth server which is currently being rate limited, the reply will be dropped 50% of the time. So, half the time it gets no response (== timeout) and the other half it gets a truncated response, thereby translating into TCP (which is another whole can of worms I'm leaving for later.) If it gets a truncated response, all is well enough. If it gets no response, the additional time it waits will leave the window open for spoofing, using whatever lengths it has configured or defaults to. I'm not worried about the TC=1 response case here, although I would point out that an attacker being able to change the behavior of a system just by attacking it seems scary as well, and causing a server to have to fall back to TCP more often and an auth server to have to respond to more TCP than it otherwise would seems like a major behavioral change, and I can think of several interesting attacks based on that alone. --Michael ___ 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] question for DNS being attacked
On Jun 28, 2012, at 1:55 PM, Paul Vixie wrote: we are now in the post-apocalyptic road-warrior phase of non-DNSSEC's history. it's difficult for me to imagine anyone choosing to remain an attack amplifier when they could instead sign their zones. but you're entirely right about the tradeoff transparency; vernon and i do not intend to slip this decision into an operator's life without their knowledge and consent. BCP 38 Enough said. --Michael ___ 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] question for DNS being attacked
On Jun 28, 2012, at 2:35 PM, Paul Vixie wrote: On 6/28/2012 7:10 PM, Michael Graff wrote: BCP 38 Enough said. what does that mean? It means that time and time again, either sufficient mass must implement a feature like this, or it is effectively pointless. It also means that the pain of installing such a security feature is on the side that does not feel the pain. But, unlike BCP38 which would make a difference if enough ISPs implemented it, this is another form of an arms race against a well armed opponent. That said, the slip factor is clever, but I still worry about translating what would be a UDP timeout into a TCP query in addition to a filter that takes only 5 sequential packets to activate. --Michael ___ 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] question for DNS being attacked
On Jun 28, 2012, at 12:10 AM, Paul Vixie wrote: DNS RRL looks for unnatural similarities in a ip-src, dns-response flow, and limits the rate accordingly. it will not stop a random-sourced attack nor a widely-reflected attack, but it has been shown to stop targetted attacks using a small number of reflectors. there is a technical note at http://www.redbarn.org/dns/ratelimits which describes the approach in detail. The RLL tech may not be supported by ISC, but the URL http://ss.vix.com/~vixie/isc-tn-2012-1.txt says it is copyright by ISC. I still fear this sort of rate limiting (or possibly any major rate limiting that isn't fair-share outgoing bandwidth limiting) can cause other issues, including some security issues. It may solve the distributed flood using DNS as an amplification, but until I see a write up on exactly how it performs with more than just a description, and a few people outside of the two developers analyze that methodology, I would not use this system in production. Even with the slip values, I still feel this can open a wider window for other forms of attacks against a DNS zone. --Michael ___ 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] Why would an MTA issue an ANY query instead of an MX query?
So if enough people stopped answering users of qmail might change the field, even if the author won't change the code. --Michael (from an iPhone) On Jun 10, 2012, at 5:29, sth...@nethelp.no wrote: Clue appreciated, thanks! One word: qmail. Google qmail dns any query. It would actually be *good* to stop answering the ANY queries if that would force qmail installations do something about this behavior. But I don't have high hopes... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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
