Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
* Vernon Schryver: Emergency patches against ANY to last for a day or two for lack of other available tools can make good sense--for a day or so. But spending any long term effort on ANY queries in this context is the same thinking that brought us SPF as the final ultimate solution to the spam problem (FUSSP), because as we all knew, spam requires forged senders. But unlike spam, these attacks require spoofed source addresses. Perhaps it's time to admit defeat, call our legislators, and suggest that they mandate source address validation by service providers. ___ 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?
From: Florian Weimer f...@deneb.enyo.de Emergency patches against ANY to last for a day or two for lack of other available tools can make good sense--for a day or so. But spending any long term effort on ANY queries in this context is the same thinking that brought us SPF as the final ultimate solution to the spam problem (FUSSP), because as we all knew, spam requires forged senders. But unlike spam, these attacks require spoofed source addresses. Was I really that unclear? Of course forged IP source addresses are a critical part of DNS reflection DoS attacks, just as bulk is a critical part of spam. My point is that it is necessary to pay attention to the necessary aspects of the problem and deal with those instead of trivial efforts against the current wrapping paper. From the history of obvious bogus spam FUSSPs such as the many variations of email authentication and the prove mail sender is a human unsolicited bulk email (spam) sent to uninvolved third parties, I predict that the next solution to DNS reflection attacks after the current disable AUTHORITY and ADDITIONAL sections and disable ANY will be disable DNSSEC. Solutions analogous to know your customer before allowing outgoing bulk connections to TCP port 25 such as disable or restrict open recursive DNS servers to known users or even install response rate limiting DNS software (not to mention BCP 38) are resisted as too hard. The saving grace is that the monetary rewards for allowing DNS reflection attacks aren't as large as those for allowing unsolicited bulk email. Perhaps it's time to admit defeat, call our legislators, and suggest that they mandate source address validation by service providers. Speaking of easier non-solutions that would not only not solve the problem but create worse problems ... On the other hand, if service providers were liable for damages caused by forged IP source addresses (or forged SMTP envelopes) ... Vernon Schryverv...@rhyolite.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] Why would an MTA issue an ANY query instead of an MX query?
On 2012-06-23 9:54 PM, Florian Weimer wrote: ... Perhaps it's time to admit defeat, call our legislators, and suggest that they mandate source address validation by service providers. it's been time and past time for that since the internet was first commercialized and privatized. not only mandating it in the enterprise, but in the isp, and in peers of the isp. economics favour NOT doing this. it will NOT be done, at scale, voluntarily. ___ 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?
On Sun, Jun 10, 2012 at 01:25:06PM +0200, DTNX Postmaster postmas...@dtnx.net wrote a message of 37 lines which said: Google is known to be obsessed with latency, for example, so I wouldn't be suprised if they deliberately request ANY and then parse and cache the results for a multitude of uses. But that's speculation. I checked the ANY requests coming into .FR name servers and Google (which should be an important user) does not appear. ___ 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?
I don't really think that is the ISPs business to 'correct' 'unwise' behaviour on the part of equipment. The devil is in the details. What does an ISP mean by 'correct' or what is 'unwise' ? Whatever filtering you can currently seem a 'good idea' quickly becomes abused, misunderstood and applied like a wrecking ball all over the place. For a taste of this one only needs to look at what ISPs and network operators do nowadays regarding ICMP filtering. It's a very slippery slope, one I wouldn't like the industry to take. Warm regards Carlos On 6/12/12 11:46 AM, Vernon Schryver wrote: From: Nicholas Suan ns...@nonexiste.net However since 53/udp is stateless, and 25/tcp is not, you cast a much wider net blocking port 53 inbound than you do with port 25. At least with port 25 you can look at the tcp flags and recognize this is a new connection without keeping connection state. Either I don't understand or that's a restatement of the claim that DNS clients commonly send from port 53. As far 25/TCP blocking is concerned in this context, the TCP flags only let you figure out whether a TCP segment is to or from a server, exactly as port 53 vs. not-53 often does for DNS/UDP. People have been repeating the DNS clients send from port 53 claim for almost as long as others talking about blocking port 25. Is it valid for consumer ISP customers? I bet not, but I don't know. ... ] From: Peter Koch p...@denic.de ] Joe and Joan should be using their ISP's validating, load balancing, ] well (or at least somewhat) maintained DNS servers, just as they should ] be using their ISP's SMTP systems. ] ]I'm sure my government loves you already. Why not cripple the Internet further ] since what else do Joe and Joan need but TCP port 80, where the rest ] (or even anything at all) can go through the ISP's web proxy? Haven't you heard?--Everything is moving to The Cloud. Are you claiming that Joe and Joan Sixpack would ever knowingly run their own DNS servers? In the real world, Joan and Joe Sixpack have no real control over the software on their computers. They don't even want it or they'd not tolerate the new silent updates from ISPs, Apple, Microsoft, Google, Adobe, Mozilla, etc. Besides, local DNSSEC validating, regardless of ISP port 53 blocks, is the fix for those concerns. Please think how easy it is for anyone in the path of your port 53 packets to run a covert proxy. Do you doubt that there are many illicit translucent DNS proxies? What is a DNS resolver besides a licit, somewhat transparent proxy? Consider how easy it is for an ISP to adjust its routers to redirect user port 53 packets to a resolver with an RPZ zone. Recall DNSChanger and the soon to end DNSChanger remediation effort. ... } From: Dobbins, Roland rdobb...@arbor.net } The *real* problem is, to beat the dead horse yet again, lack of } anti-spoofing deployment at the access edge. The rest of this discussion } is tactical. Yes, how is BCP 38 deployment going? That's not rhetorical. Somewhere recently I saw that question yet again but no real answers. Are consumer ISPs finally deploying BCP 38 and/or blocking port 25? (other than by out-sourcing the port 25 blocking by expecting spam targets to use Spamhaus' PBL) ... From: Stephane Bortzmeyer bortzme...@nic.fr Also, many ISP have lying resolvers and customers should NOT use them. From a security perspective, it would be catastrophic since the last mile is not secured, so the only safe way to run DNSSEC is to validate locally (which requires access to port 53 if the ISP resolver is lying). Either that is wrong or DNSSEC is useless, because sending to a packet toward a distant DNS servers does imply that it will answer. Instead I think local DNS validation consists of requesting signature and key RRs and checking the chain of public key signatures starting from the root key that you somehow previously got out of band. Do hotels capture and 'improve' your DNS requests to distant servers like HTTP? If you care, hotels you use manual IP addresses, laptop DNSSEC valdation, HTTPS, ssh (perhaps over port 443), and/or VPNs. Vernon Schryverv...@rhyolite.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 ___ 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?
Vernon Schryver v...@rhyolite.com wrote: Yes, how is BCP 38 deployment going? Someone on NANOG recently mentioned http://spoofer.csail.mit.edu/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: West or northwest 4 or 5, occasionally 3 later. Moderate. Thundery showers. Good. ___ 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?
From: Tony Finch d...@dotat.at Yes, how is BCP 38 deployment going? Someone on NANOG recently mentioned http://spoofer.csail.mit.edu/ http://rbeverly.net/research/papers/spoofer-imc09.html and the last slides in http://rbeverly.net/research/papers/spoofer-imc09-presentation.pdf suggest that relying on BCP 38 deployment is unsound. Vernon Schryverv...@rhyolite.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] Why would an MTA issue an ANY query instead of an MX query?
On Jun 12, 2012, at 14:46, Stephane Bortzmeyer wrote: On Sun, Jun 10, 2012 at 01:25:06PM +0200, DTNX Postmaster postmas...@dtnx.net wrote a message of 37 lines which said: Google is known to be obsessed with latency, for example, so I wouldn't be suprised if they deliberately request ANY and then parse and cache the results for a multitude of uses. But that's speculation. I checked the ANY requests coming into .FR name servers and Google (which should be an important user) does not appear. We are seeing them from 74.125.0.0/16, which is a range owned by Google, and they resolve to '*.1e100.net', a domain owned by Google. I do not know why they originate there; from the queries it seems that they may be the resolvers in use by the crawler bots, Gmail, or their open resolvers. I am speculating about the purpose of those requests, of course, but I am not making them up ;-) Also, they seem perfectly well behaved. Cya, Jona ___ 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?
On Jun 10, 2012, at 23:59, Kyle Creyts wrote: On Sun, Jun 10, 2012 at 2:33 PM, Paul Vixie p...@redbarn.org wrote: I'm afraid we may need more control. If my clients are generating a DDoS attack at 20 responses per second, and I limit this to 5 per second - the CC can get the same effect by mobilizing four times as many clients to do the job. no. the client ip is spoofed. the number of spoofers doesn't matter, when the reflector is looking at both the apparent client ip and the intended response. when most well-provisioned authority servers are running with some kind of rate limiting, then the only way to do a reflective amplifying ddos will be (a) do it through recursive not authority servers, or (b) send a small number of queries to a large number of authority servers, or (c) switch to some other wide area udp such as ntp or snmp or syslog or whatever. Someone mentioned that as soon as the spoofed client is blocked, that a new spoofed client is used... This behavior seems... strange. How quick is this shift? How would one know when to shift the target? The modes I _can_ come up with largely involve having some sort of information about what is reaching the target. (bandwidth or traffic sources) This just leads to more interesting questions about those perpetrating the attacks, and their intent. Is there an obvious way of discerning the time to switch targets that I am missing? Is this a non-interesting topic? From what I've seen, in our specific case, the apparent source address seems to swap every thousands requests or so, with a few exceptions. This is from running dnstop on our auth nameservers for a few hours. HTH, Jona ___ 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?
What about rate limiting clients which are not keeping the TTL value? We are talking about rate limiting on authoritative name servers, right? Not *only* on authoritative name servers. It is also relevant for recursive name servers. In general, yes of course. But I had ANY querys and the current amplification attack in mind. ___ 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?
Vernon Schryver v...@rhyolite.com wrote: My hope and almost ambition for the code I've been working on is find a default set of parameters response rate limiting parameters to reduce the nuisance of open resolvers. Do you expect the parameters to differ for reflected amplification attacks on authoritative servers? (which is the case that I care about.) Have you considered minimal truncated replies as an alternative response to over-limit clients? The idea being to move legit queries from the victims onto TCP. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Portland: Variable 3 or 4, becoming northerly or northwesterly 4 or 5, occasionally 6 in east. Slight or moderate. Occasional rain. Moderate or good, occasionally poor. ___ 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?
From: Tony Finch d...@dotat.at I think it's wrong to focus on ANY queries: restricting them just encourages the attackers to move on to another query type. For a domain with DNSSEC you get almost as much data in return to an MX query - 2KB vs 1.5KB for cam.ac.uk. Today I see 2232 byte responses for another type from the authoritative servers for another domain often discussed in this context. That obvious type is not TXT, SPF, MX, or anything else that might be deleted, deprecated, shrunk, compressed, moved to an apex, or whatever. ANY queries might be of little use to computers, but I find them useful while chasing DNS problems. Emergency patches against ANY to last for a day or two for lack of other available tools can make good sense--for a day or so. But spending any long term effort on ANY queries in this context is the same thinking that brought us SPF as the final ultimate solution to the spam problem (FUSSP), because as we all knew, spam requires forged senders. That analogy goes farther than one might realize, because some of the ANY solutions I've heard include analogs of the amazingly uninformed and wrong headed SPF re-invention of SMTP source routes. Vernon Schryverv...@rhyolite.com P.S. I know the current line is that SPF is not and never was a FUSSP; that doesn't change what was said at the time. I also know that DKIM has some real operational value, despite the fact that plenty of unsolicited, objectionable bulk email advertising is delivered with valid DKIM signatures. ___ 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?
On Jun 11, 2012, at 6:34 PM, Tony Finch wrote: For a domain with DNSSEC you get almost as much data in return to an MX query - 2KB vs 1.5KB for cam.ac.uk. They've been doing that for a while. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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?
On Jun 11, 2012, at 10:07 PM, Vernon Schryver wrote: But spending any long term effort on ANY queries in this context All I'm saying is that tactically filtering out ANY queries whilst one is under attack may be a valid tactical response, and that encouraging software developers not to make use of ANY queries when other query-types are more appropriate may be a good idea. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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?
* Kyle Creyts: Wouldn't an ANY query to a recursive ONLY return the cached records? This is implementation-dependent, and you can make sure that the cache contains sufficient amounts of data anyway. ___ 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?
bigger question: why allow the UDP 53 to CPE to be answered as if it were from internal? the external connectivity to port 53 should be able to be forwarded at the consumer's discretion, but should certainly not be answered by the DNS proxy! On Mon, Jun 11, 2012 at 9:46 PM, Vernon Schryver v...@rhyolite.com wrote: From: Chris Adams cmad...@hiwaay.net Once upon a time, Mark Andrews ma...@isc.org said: If we have Attacker - CPE - Auth - CPE - Target why isn't the CPE returning answers from its cache? Most of the CPE just run a DNS proxy (e.g. dnsmasq on Linux-based boxes), not a full cache. Even if they ran a cache, the attack would still be CPE-Target (just not going to another server in-between). It Why aren't ISPs blocking UDP source port 53 to the core under their old no-servers-for-consumers term of service? What is the common consumer ISP current practice for TCP port 25 at the ISP/core boundary? If it is one of the many old flavors of blocking (e.g. always, prior arrangement, business service), why can't it be applied to UDP port 53? How many consumers would object if their modems can't answer or perhaps even hear UDP port 53 from the outer Internet? In other words, as with port 25, why must the rest of the Internet subsidize some often very big outfits by dealing with abuse that the outfits could deal with or at least contain within their own networks? Why not a blacklist/ACL/whatever similar to Spamhaus' PBL for TCP port 25? For that matter, why not apply the PBL to UDP port 53 on the grounds that IP addresses that should never be seen sending email also never need outside DNS service? Of course, blocking consumer port 53 would not be a panacea, but it might reduce the proxies available for abuse. Vernon Schryver v...@rhyolite.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 -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer ___ 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] Why would an MTA issue an ANY query instead of an MX query?
Clue appreciated, thanks! --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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?
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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
ANY queries, in my *limited* experience, have had higher latencies by an order or two of magnitude. but that was mostly when I was doing open resolver research a year or two ago. On Jun 10, 2012 7:25 AM, DTNX Postmaster postmas...@dtnx.net wrote: On Jun 10, 2012, at 12:33, Dobbins, Roland wrote: On Jun 10, 2012, at 5:29 PM, sth...@nethelp.no wrote: One word: qmail. Google qmail dns any query. If that's it, then would asking djb to change its behavior so as to issue TXT requests to look for SPF records make sense? I know that doesn't do anything for currently-deployed MTAs, but one has to start somewhere . . . Asking DJB to change qmail behavior? ;-) It's not just qmail, though. I bet there's some engineers who consider it more efficient to do a single query to get all the data they want. A lot of the 'ANY' queries we get originate at Google, HE etcetera. Google is known to be obsessed with latency, for example, so I wouldn't be suprised if they deliberately request ANY and then parse and cache the results for a multitude of uses. A single ANY query for a domain gives you the NS, MX, TXT and SPF records, plus any A/ record present. At scale, who knows, the reduction in number of queries probably adds up. And then there's the information harvesters, who query hosted domains in sequence. They actually seem to account for around 40% of our 'normal' ANY traffic with just a few IP addresses. Cya, Jona ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobshttps://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-jobsmailing 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] Why would an MTA issue an ANY query instead of an MX query?
On Sun, Jun 10, 2012 at 04:24:51AM -0700, Kyle Creyts kyle.cre...@gmail.com wrote a message of 65 lines which said: are there legitimate reasons to continue supporting ANY queries? They are very useful for debugging. I would regret their disappearance. What about forcing TCP for ANY requests only? It would limit ANY requests to people who don't spoof their source IP address. I do not know how to force TC for replies to ANY queries. Patches for BIND and nsd are welcome. In the mean time, limiting the outbound size to something that will probably affect only ANY queries is a possible workaround: BIND: max-udp-size 1460 nsd: ipv4-edns-size: 1460 ipv6-edns-size: 1460 ___ 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?
On Sun, 2012-06-10 at 12:59 +0200, Jan-Piet Mens wrote: If that's it, then would asking djb to change its behavior ROFL. Ask DJB to change its behavior? Good luck with that. ;-) Indeed, since he publicly declared qmail open source and abandoned back in, ohh, 2008 IIRC (even though he really left it for dead back in 2000/2001) signature.asc Description: This is a digitally signed message part ___ 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?
On 2012-06-10 12:59 PM, Patrick W. Gilmore wrote: A single ANY query for a domain gives you the NS, MX, TXT and SPF records, plus any A/ record present. At scale, who knows, the reduction in number of queries probably adds up. It strikes me as laziness and cost-shifting. If you need to do multiple queries (e.g. TXT MX), is it better for either side to do two queries instead of one? yes, since the queries can be transmitted simultaneously, and there's way less risk of TC=1 and followup TCP. 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] 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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
One word: qmail. Google qmail dns any query.
thinking about or acting against ANY is bad infosec economics. any
investment along those lines is wasted, since ANY is merely the low
hanging fruit, and an attacker need only switch over to TXT or RRSIG or
NSEC to get a similar amplification effect from an authoritative name
server, if ANY were widely nonresponsive.
Agreed. And along the same lines, limiting EDNS responses to 1460 bytes,
as suggested, will block quite a few legitimate replies (not just ANY
replies).
to that end, vernon schryver and i have been exploring rate limiting in
BIND 9. there's a patch available, which i've so far offered only to
anyone whose server is currently getting abused. what i'm worried about
is that our profile for goodput-vs-badput is wrong headed or too course
grained. so far so good.
config {
// ...
rate-limit {
responses-per-second 5;
window 5;
};
};
I'm afraid we may need more control. If my clients are generating a DDoS
attack at 20 responses per second, and I limit this to 5 per second -
the CC can get the same effect by mobilizing four times as many clients
to do the job. On my wishlist, in addition to rate limiting, is also:
- Some way of dynamically blackholing clients, based on one or more of
-- Rate limit exceeded
-- Asking the *same* question (with a large response) repeatedly
-- Asking a *specific* question (e.g. ANY isc.org|ripe.net)
-- Input from an external system, e.g. via rndc
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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
SMTP predates the MX rrtype. In RFC821, c...@stdlib.net means connect to the host stdlib.net and host records (e.g. A and now ) are what matters [*]. RFC1123 and later RFC2821 regularised the MX rrtype for mail routing, obviating the need for the host records at a mail domain. However, the correct SMTP behavior, at least considered by many, still is that if you don't find an MX record for a domain name, try to find a host record. From the point of view of an SMTP server, an ANY query is a rational way to find all of the records it will need, in one pass. [*] Well at various times, MD, MF, MAILA and MAILB were all relevant too, but those have fallen completely out of disuse. On Sun, Jun 10, 2012 at 3:17 AM, Dobbins, Roland rdobb...@arbor.net wrote: Clue appreciated, thanks! --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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 -- Colm ___ 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?
On Jun 10, 2012, at 16:23, Paul Vixie wrote: On 2012-06-10 12:59 PM, Patrick W. Gilmore wrote: A single ANY query for a domain gives you the NS, MX, TXT and SPF records, plus any A/ record present. At scale, who knows, the reduction in number of queries probably adds up. It strikes me as laziness and cost-shifting. If you need to do multiple queries (e.g. TXT MX), is it better for either side to do two queries instead of one? yes, since the queries can be transmitted simultaneously, and there's way less risk of TC=1 and followup TCP. Interesting, I did not know that. Does that mean that even from the perspective of a SMTP server, which may need between three and five queries, it may be more efficient to do seperate queries instead of a single, large ANY query? Cya, Jona ___ 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?
Not supporting ANY queries would also have side effects - simply dropping the query maks the authoritative server appear unresponsive to the recursive server initiating the query. Note that in many cases the server receiving the ANY query is a recursive server, not an authoritative server. For instance, the ISP I work for runs several recursive servers. Those recursive servers are only available to the ISP's customers. Even so, those recursive servers are contributing to DDoS attacks - because so many of the *clients* are either CPEs with a DNS proxy open from the WAN side, or customers' general open recursive servers which use the ISP recursive servers as forwarders. 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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
limiting EDNS responses to 1460 bytes, as suggested [by me], will block quite a few legitimate replies (not just ANY replies). Why? The response will be sent, just with a TC bit, and the client, if it is not lying about its IP address, will retry with TCP. No blocking. Agreed, this should work fine. Muddled thinking on my part. 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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
Hi Roland. At 03:33 10-06-2012, Dobbins, Roland wrote: If that's it, then would asking djb to change its behavior so as to issue TXT requests to look for SPF records make sense? There is a thread at https://lists.dns-oarc.net/pipermail/dns-operations/2009-October/004542.html about whether changes in behavior will happen. The issue may not be SPF (see one of the patches http://www.saout.de/misc/spf/qmail-spf-rc5.patch ). Regards, -sm ___ 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?
On Jun 10, 2012, at 1:24 PM, Kyle Creyts wrote: So, list, I am young and foolish. Aside from being in the RFC, are there legitimate reasons to continue supporting ANY queries? Yes, you don't have that power. If you issue an RFC that ANY queries are deprecated, nothing will happen. People will keep sending them and the big implementations will keep supporting them. Also, the RFC-issuing-bandwidth we have has enough of a queue to work through. Bert___ 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?
On Sun, Jun 10, 2012 at 2:33 PM, Paul Vixie p...@redbarn.org wrote: I'm afraid we may need more control. If my clients are generating a DDoS attack at 20 responses per second, and I limit this to 5 per second - the CC can get the same effect by mobilizing four times as many clients to do the job. no. the client ip is spoofed. the number of spoofers doesn't matter, when the reflector is looking at both the apparent client ip and the intended response. when most well-provisioned authority servers are running with some kind of rate limiting, then the only way to do a reflective amplifying ddos will be (a) do it through recursive not authority servers, or (b) send a small number of queries to a large number of authority servers, or (c) switch to some other wide area udp such as ntp or snmp or syslog or whatever. Someone mentioned that as soon as the spoofed client is blocked, that a new spoofed client is used... This behavior seems... strange. How quick is this shift? How would one know when to shift the target? The modes I _can_ come up with largely involve having some sort of information about what is reaching the target. (bandwidth or traffic sources) This just leads to more interesting questions about those perpetrating the attacks, and their intent. Is there an obvious way of discerning the time to switch targets that I am missing? Is this a non-interesting topic? none of those things is low hanging fruit; they will require enough work, even by script kiddies, that most attackers will switch back to ddos-for-hire which will work through direct bombing by botnets. this is because recursive servers can generally run closed (on-net or on-campus only) and the smallish number of open ones can rate limit (as opendns and googledns both do today); and because maintaining a catalogue of server+qtuple inputs for spoofed-source attacks will be a lot more work than just use ripe.net or isc.org as happens today; and because ntp and snmp generally reflect just fine but don't amplify as well as dns. On my wishlist, in addition to rate limiting, is also: - Some way of dynamically blackholing clients, based on one or more of -- Rate limit exceeded -- Asking the *same* question (with a large response) repeatedly -- Asking a *specific* question (e.g. ANY isc.org|ripe.net) -- Input from an external system, e.g. via rndc all but the last is already done. distributed blackholing of abusive source addresses is dangerous, since in udp, the source addresses will often be spoofed. this means blackholing is likely to cut off responses to legitimate queries from the victims. (vernon and i spent a lot of time working on that problem especially.) 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 -- Kyle Creyts ___ 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
