Re: [dns-operations] annoying DDoS attack on ns0.rfc1035.com
Nope - I tested this some time ago - mail delivery from certain large providers will fail as they don't do MX requests, even if the ANY fail's it seems. -Original Message- From: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of DTNX Postmaster Sent: 10 June 2012 11:07 To: DNS Operations List Subject: Re: [dns-operations] annoying DDoS attack on ns0.rfc1035.com On Jun 10, 2012, at 10:59, Dobbins, Roland wrote: On Jun 10, 2012, at 3:45 PM, Jim Reid wrote: And why pick on my name server which has never done anyone any harm? They're just looking for ANY records, there's no rhyme or reason to it. They're spoofing the IP address of the target they're attacking - they're using your server for reflection/amplification. Do you really need to respond to ANY queries - especially when your servers are being abused? Are there any downsides to not responding to 'ANY' queries? A client should retry with a more focused query AFAIK, but does that actually happen in practice? 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 ___ 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] annoying DDoS attack on ns0.rfc1035.com
On 2012-06-10 8:45 AM, Jim Reid wrote: On 10 Jun 2012, at 09:19, DTNX Postmaster wrote: The iptables rules mentioned in the first comment work well for us Well for starters, I [dw]on't use Linux. The server runs FreeBSD. what f-root has done for the last ten years (also on freebsd) is: add pipe 1 udp from any to any 53 in pipe 1 config mask src-ip 0x buckets 1024 bw 400Kbit/s queue 3 add pipe 2 tcp from any to any 53 in pipe 2 config mask src-ip 0x buckets 1024 bw 100Kbit/s queue 3 note, this approach, and the iptables approach, are inadequate since they look only at the query ip, whereas rate limiting has to take the desired response into account. i say desired response because one of the myriad attack formats of interest is randomstring.domain where domain is dnssec signed. here the desired response will be of the form NXDOMAIN, proof from 'domain'. these have to be rate limited also, and there's no way to do that upstream of the name server. which brings me to: Besides, the damage is done by the time these packets hit the server's ethernet card. At ~4000qps inbound, this is close to saturating the server's VLAN in the data centre. The traffic needs to be blocked before it reaches that. ... i don't agree. 4Kqps is no big deal in input, it's the output that would cost you money. and as described above, there's no accurate rate limiting possible upstream of the name server; one has to know the proposed response before one can decide whether a given response ought to be dropped. 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?
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] annoying DDoS attack on ns0.rfc1035.com
Den 10. juni 2012 kl. 16:11 skrev Paul Vixie: On 2012-06-10 8:45 AM, Jim Reid wrote: On 10 Jun 2012, at 09:19, DTNX Postmaster wrote: The iptables rules mentioned in the first comment work well for us Well for starters, I [dw]on't use Linux. The server runs FreeBSD. what f-root has done for the last ten years (also on freebsd) is: add pipe 1 udp from any to any 53 in pipe 1 config mask src-ip 0x buckets 1024 bw 400Kbit/s queue 3 add pipe 2 tcp from any to any 53 in pipe 2 config mask src-ip 0x buckets 1024 bw 100Kbit/s queue 3 note, this approach, and the iptables approach, are inadequate since they look only at the query ip, whereas rate limiting has to take the desired response into account. i say desired response because one of the myriad attack formats of interest is randomstring.domain where domain is dnssec signed. here the desired response will be of the form NXDOMAIN, proof from 'domain'. these have to be rate limited also, and there's no way to do that upstream of the name server. which brings me to: Besides, the damage is done by the time these packets hit the server's ethernet card. At ~4000qps inbound, this is close to saturating the server's VLAN in the data centre. The traffic needs to be blocked before it reaches that. ... i don't agree. 4Kqps is no big deal in input, it's the output that would cost you money. and as described above, there's no accurate rate limiting possible upstream of the name server; one has to know the proposed response before one can decide whether a given response ought to be dropped. I'm seeing the same attack as Jim Reid described on one of my nameservers too (just found the source/target address on Gmane and signed up for the mailinglist), at ~3Kqps/1.3Mbits at the moment (in Germany, AS24940). No UDP checksum, the source address is set to 37.221.160.125 and ANY queries for a zone that isn't and haven't been in use (no records apart from DNSSEC, SOA and NS). I haven't seen anything on the other authoritative servers. The attack have been going on at least since Thursday, when I noticed and stopped answering the queries. There were also several addresses targeted at that time. Here's a sample query: fd 35 01 00 00 01 00 00 00 00 00 01 08 62 61 63 0010 6f 6e 64 6e 73 03 62 69 7a 00 00 ff 00 01 00 00 0020 29 23 28 00 00 00 00 00 00 Jan Inge ___ 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
Re: [dns-operations] Rate limiting for DNS: list of practices
On Jun 10, 2012, at 1:17 PM, Stephane Bortzmeyer wrote: On Sun, Jun 10, 2012 at 12:47:22PM -0700, Paul Hoffman phoff...@proper.com wrote a message of 9 lines which said: It would be useful if there was a somewhat-up-to-date document that we can point DNS operators towards that covers this. A beginning is here https://www.dns-oarc.net/wiki/mitigating-dns-denial-of-service-attacks. Errr, no. There is nothing about rate-limiting there. Yes, I am volunteering to collect the information. Some actions are controversial so it is not only a matter of collecting info but also of evaluating it. Fully agree. --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] 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
