Re: [dns-operations] dotless domains
Logically, shouldn't a right-side dot fix all of this? If I browse to: http://myname./ I would expect to get a gTLD, as the right-side dot represents the root. If I were to browse to: http://myname/ I would expect to hit my local definitions, then search domain, then fail or hit the browser search. Is this a broken view or does it make sense? On Sun, Sep 23, 2012 at 11:51 PM, Mark Andrews ma...@isc.org wrote: In message 505fe0c6.50...@dougbarton.us, Doug Barton writes: On 09/23/2012 21:07, Mark Andrews wrote: It does if http://myname; goes to a local machine one day and the next day it goes to a tld the next day because myname was added to the root zone and that zone has A, or SRV records which will be the case if resolvers/browsers are fixed to make simple names match against tld first, which you suggest is a logical consequence of allowing this idiocy to continue. I didn't say that was the only solution, maybe the better idea is test local resolution first, then add a fully-qualifying dot second. My point was not, Here is how to solve the problem, so stop attacking my poor, harmless straw man. :) My point was that we are not limited to the status quo. You then have administators having to check the list of TLDs whenever they add a new machine and rejecting any name that matches a tld to prevent simple - tld becoming simple - local. Simple - TLD + Simple - local cannot be made to work safely. The best solution would be to acknowledge that this is a security problem and fix gethostbyname, getaddrinfo etc. and browsers never treat a simple name as a tld. Simple names are locally resolved not globally resolved. ... and are you saying that if I have foo.example.com, AND I have users that do http://foo, AND someone creates dot-foo, AND my users then try to go to my local site and get the TLD instead; that they will be confused into entering their foo.example password into a form on dot-foo? Or do I misunderstand? They might. Not all interfaces are good at showing what you have connected to or even show anything at all. Think mail user@myname. Which user gets the email? The local user or the TLD user? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- 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
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
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 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
Re: [dns-operations] DDoS botnet behaviour
It seems to me that it might be pertinent to split this discussion into clear threads. There are several different attack patterns being discussed here, and it is my opinion that they have distinct and different solutions, and may merit separated discussion, or at least identification. The https://www.dns-oarc.net/wiki/mitigating-dns-denial-of-service-attacks page doesn't describe the categories of attacks for which the mitigations provide remedy; hopefully someone clueful enough is envolved in the remediation, but for the sake of completeness, it might be expected that this information, or links to it, be included in the wiki. I'm not suggesting detailing every edge case, but I think a brief summary might be in order. Something brief describing the nature of several example cases for which each mitigation is optimal, and maybe a pros/cons list for each might be very useful to someone attempting to mitigate. On Sun, Jun 10, 2012 at 4:36 PM, Vernon Schryver v...@rhyolite.com wrote: From: Jim Reid j...@rfc1035.com My logs tended to have a few hundred entries at a time for the same (spoofed?) IP address. So as soon as I blackholed the last IP address in the log file, entries for another would be appended. At 4am and there's a caffeine deficit, this looks like a new client has immediately popped up to replace the one that's just been nuked. In fact, the new IP address was already there and its queries were lost amongst the noise of the other 100+ addresses that were firing crap at the name server. That raises two issues. A problem with the response rate limiting code I've been working is logging. One needs to be able to find out response have been rate limited and why. To answer that question, my current logging code simply logs to a new BIND9 category whenever it drops a response (or would have dropped when in test mode). The problem is that even on my small DNS servers that generates too much noise. My plan is to change from instantaneous to retrospective logging that says something equivalent to 10.2.3.4 recently asked 27 times for A records for example.com and the last 13 responses were dropped. The second issue concerns log noise and the popular enthusiasm for using Bloom filters for DNS response rate limiting. I've heard more than one suggestion for using Bloom filters for DNS response rate limiting. Bloom filters are a great idea for some things but I think they a problem instead of a solution here. The problem is suggested by the word probabilistic in Part of a series on Probabilistic data structures on https://en.wikipedia.org/wiki/Bloom_filter It's like the difference between accounting and statistics. You don't (and for privacy reasons must not) care exactly how many nearby households have incomes above or below twice the median for your neighborhood. A statistical statement like 99.9% of your neighbors earned $31,000 +/-$10,000 is fine. On the other, accounting hand, you'd be unhappy if your bank told you that 0.1% of your bank statements would be fiction, and you'd have to guess which. Bloom filters have false positives. If you know enough about your data, you can make the false positive probability as low as you like, but you cannot make that probability zero without giving up the reasons why you chose a Bloom filter. Never mind the difficulities in knowing enough about your DNS query stream, and not that it is always a probability distribution as opposed to a rate. Computing that distribution depends on hard to answer questions such as how independent your hash functions really are on your real data. The connection with logging is that you need to be able to answer the question Why did your DNS server drop my requests? With any sort of probabilistic filter including Bloom filters, you won't be able to say You sent more than X requests without turning on query-logging and slogging through GBytes of log lines. I think doing the retrospective logging I plan would make any Bloom filter scheme equivalent to a straight forward hash table. Log messages saying IP addresses that the filter says are the same recently asked 27 times for A records for example.com and the last 13 responses were dropped would not satisfy people wanting to know why their customer's browsers are stalling when trying to get to their web sites. 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
