Re: forward all but ANY requests
On 30-Nov-18 08:14, Erich Eckner wrote: > On 30.11.18 12:26, Timothe Litt wrote: >> On 30-Nov-18 06:04, Erich Eckner wrote: >>> Hi, >>> >>> I'm running a bind9 name server (9.13.4 on debian) which forwards some >>> zone (onion.) to tor's name server. Unfortunately, tor's name server >>> only answers A and requests, but not e.g. ANY requests. >>> >>> 192.168.1.3 is running the tor dns, >>> 192.168.1.13 is running bind9 forwarding to 192.168.1.3:9053 >>> >>> $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion ANY >>> ;; Connection to 192.168.1.3#9053(192.168.1.3) for >>> 3g2upl4pq6kufc4m.onion failed: connection refused. >>> $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion A >>> 10.255.55.223 >>> $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion >>> febe:5163:d2b9:98aa:345b:ee04:2c32:d10e >>> $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion ANY >>> $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion A >>> 10.255.55.223 >>> $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion >>> febe:5163:d2b9:98aa:345b:ee04:2c32:d10e >>> >>> Is there any option: >>> - to make bind fall back to A or when the ANY request fails (even >>> the connection fails!) or >>> - to only forward requests of certain type(s) or >>> - to answer ANY requests _always_ with A or records (not trying if >>> the ANY request can be forwarded successfully), possibly for certain >>> zones only? >>> >>> Sry, if that has been asked before, but I seem unable to find anything >>> useful on the internet, since "ANY" is not a good search term ;-) and >>> without "ANY" I only turn up how to set bind to ipv4/ipv6-only. >>> >>> regards, >>> Erich >> This reflects a common misunderstanding. >> >> A query for ANY does not return 'everything'. It returns what the >> server happens to have cached. It's a diagnostic. >> >> You have to ask explicitly for the record types that you want. >> >> Many people have fallen into the trap of thinking that an ANY query will >> return all records in the DNS, and assume that therefore it can be used >> to make fewer queries. You're not the first. >> >> Any software (or wetware) that relies on ANY for any purpose other than >> determining what's in a server's cache for diagnostic purposes is broken. >> >> >> Timothe Litt >> ACM Distinguished Engineer >> -- >> This communication may not represent the ACM or my employer's views, >> if any, on the matters discussed. > Thank you for the clarification. Indeed, I can (after querying A and > ) retrieve those records via ANY requests. :-) > > Regards, > Erich Note that this result is not guaranteed. The server is not required to cache records. The records may have a TTL less than the time between your queries. (E.g. 0) The records may be evicted from a busy cache before the TTL expires. Or the server may reboot between queries. Or... Unless you have some specific reason for finding out what is in a server's cache, you don't want to use queries for ANY. The results will seem confusing/unpredictable - and while they may "seem to work" for a while, will end up wasting a lot of your time. ANY queries are a classic "sharp tool". If used properly, they can cut the time required to diagnose a problem. If used improperly, they will cut you instead. For most people, in most circumstances, the best strategy is to never issue a ANY query. (dig is also a sharp tool; else issuing an ANY query would produce an "are you sure?" prompt :-) Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forward all but ANY requests
On 30-Nov-18 06:04, Erich Eckner wrote: > Hi, > > I'm running a bind9 name server (9.13.4 on debian) which forwards some > zone (onion.) to tor's name server. Unfortunately, tor's name server > only answers A and requests, but not e.g. ANY requests. > > 192.168.1.3 is running the tor dns, > 192.168.1.13 is running bind9 forwarding to 192.168.1.3:9053 > > $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion ANY > ;; Connection to 192.168.1.3#9053(192.168.1.3) for > 3g2upl4pq6kufc4m.onion failed: connection refused. > $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion A > 10.255.55.223 > $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion > febe:5163:d2b9:98aa:345b:ee04:2c32:d10e > $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion ANY > $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion A > 10.255.55.223 > $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion > febe:5163:d2b9:98aa:345b:ee04:2c32:d10e > > Is there any option: > - to make bind fall back to A or when the ANY request fails (even > the connection fails!) or > - to only forward requests of certain type(s) or > - to answer ANY requests _always_ with A or records (not trying if > the ANY request can be forwarded successfully), possibly for certain > zones only? > > Sry, if that has been asked before, but I seem unable to find anything > useful on the internet, since "ANY" is not a good search term ;-) and > without "ANY" I only turn up how to set bind to ipv4/ipv6-only. > > regards, > Erich This reflects a common misunderstanding. A query for ANY does not return 'everything'. It returns what the server happens to have cached. It's a diagnostic. You have to ask explicitly for the record types that you want. Many people have fallen into the trap of thinking that an ANY query will return all records in the DNS, and assume that therefore it can be used to make fewer queries. You're not the first. Any software (or wetware) that relies on ANY for any purpose other than determining what's in a server's cache for diagnostic purposes is broken. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
forward all but ANY requests
Hi, I'm running a bind9 name server (9.13.4 on debian) which forwards some zone (onion.) to tor's name server. Unfortunately, tor's name server only answers A and requests, but not e.g. ANY requests. 192.168.1.3 is running the tor dns, 192.168.1.13 is running bind9 forwarding to 192.168.1.3:9053 $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion ANY ;; Connection to 192.168.1.3#9053(192.168.1.3) for 3g2upl4pq6kufc4m.onion failed: connection refused. $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion A 10.255.55.223 $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion febe:5163:d2b9:98aa:345b:ee04:2c32:d10e $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion ANY $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion A 10.255.55.223 $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion febe:5163:d2b9:98aa:345b:ee04:2c32:d10e Is there any option: - to make bind fall back to A or when the ANY request fails (even the connection fails!) or - to only forward requests of certain type(s) or - to answer ANY requests _always_ with A or records (not trying if the ANY request can be forwarded successfully), possibly for certain zones only? Sry, if that has been asked before, but I seem unable to find anything useful on the internet, since "ANY" is not a good search term ;-) and without "ANY" I only turn up how to set bind to ipv4/ipv6-only. regards, Erich signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Doug Barton do...@dougbarton.us wrote: On 06/05/2013 11:33 AM, Tony Finch wrote: I believe the ANY hack on mail servers was a Sendmailism 20ish years ago. s/Send/q/ No, I meant Sendmail - see http://fanf.livejournal.com/10.html Sendmail at one time tried to use ANY for combined MX+A lookups, which doesn't work. qmail uses ANY for CNAME lookups, which sort-of works, apart from a number of bugs described on the page above. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Vernon Schryver v...@rhyolite.com wrote: [ANY query for combined MX/A lookup was] a bad hack then and it has remained a bad hack :-) I would not agree if you could rely on the open resolvers continuing to do what they're doing, if you didn't care about parsing 3 or 4 KBytes of irrelevant bits to get the RRsets you want, and if you don't care about spending 9 or 10 IP packets on a truncated UDP responce and then a full TCP response instead of 6 on 3 separate queries. With BIND as your DNS server, it could be a win for bursts of mail to a single SMTP server if your SMTP client is too dumb to do the obvious, safe caching. At worst you would need to ask for ANY, MX, A, and , but some of the time the ANY would have all of the RRsets. There are other caveats: The ANY query does not trigger additional section processing, so if you find MX records in the result you have to make follow-up queries to get the A and records of the targets; if you made an MX query in the first place you often don't need to make more queries. The ANY query does not trigger alias processing, so if there is a CNAME chain you have to follow it yourself. This is a waste because if you made an MX query in the first place the server would have given you the whole chain without further queries. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
In article mailman.488.1370508226.20661.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: The ANY query does not trigger alias processing, so if there is a CNAME chain you have to follow it yourself. This is a waste because if you made an MX query in the first place the server would have given you the whole chain without further queries. Unless the links in the CNAME chain are in the same bailiwick, isn't the client going to ignore them and follow them itself, to avoid cache poisoning? -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Barry Margolin bar...@alum.mit.edu wrote: In article mailman.488.1370508226.20661.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: The ANY query does not trigger alias processing, so if there is a CNAME chain you have to follow it yourself. This is a waste because if you made an MX query in the first place the server would have given you the whole chain without further queries. Unless the links in the CNAME chain are in the same bailiwick, isn't the client going to ignore them and follow them itself, to avoid cache poisoning? The client is a stub resolver, the server is a recursive resolver. The recursive server will either serve the CNAME chain from cache or chase it safely if necessary, Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
From: Tony Finch d...@dotat.at Sendmail at one time tried to use ANY for combined MX+A lookups, which doesn't work. That would be true and relevant if sendmail did that. Requesting ANY, not getting all of the MX, A, and/or records needed, and failing to continue making other DNS requests simply does not work. If sendmail did that, then given what BIND has done for eons, that bug would have been noticed immediately eons ago. Tony Finch pointed out privately that it wasn't until sendmail 8.12 that stopped asking for ANY records. I found 8.11.6 on http://rpm.pbone.net/index.php3/stat/26/dist/4/size/1399432/name/sendmail-8.11.6-1.62.3.src.rpm sendmail/domain.c in 8.11.6 started by requesting ANY. However it continued requesting , A, and/or MX and parsing ANSWER sections until it got the records needed. It did not stop with the ANY response unless the ANY response was dispositive (e.g contained all types or NXDOMAIN). My superficial code reading says it ignored ADDITIONAL sections and so ignored potentially interesting A or RRs in ADDITIONAL sections. My quick side-by-side comparison of the old 8.11.6 and current 8.14.7 domain.c says that the relevant difference is that 8.14.7 starts with A or and never tries ANY. However, that is about dns_getcanonname(). getmxrr() in both 8.11.6 and 8.14 starts and ends with MX and never messes with ANY. There is broken in that ANY scheme. It might or might not reduce average DNS traffic for sending mail. I'd vote against it today for various reasons, but that doesn't make it wrong. There is an interesting comment in the 8.11.6 version of domain.c: ** The ANY query is really meant to prime ** the cache so this isn't dangerous. If your SMTP client is very close to your recursive resolvers (typical 10 or 20 years ago), then making an ANY request that you ignore could reduce your external DNS traffic by priming (not refreshing) the resolver's cache. I don't know that getmxrr() in sendmail is not called before dns_getcanonname(), which would prevent cache the priming by an ANY request. About chasing CNAMEs safely or otherwise, please recall the somewhat controversial DontExpandCnames. The current cf/README says: confDONT_EXPAND_CNAMES DontExpandCnames [False] If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if FTP.Foo.ORG is a CNAME for Cruft.Foo.ORG, then with this option set a lookup of FTP will return FTP.Foo.ORG; if clear it returns Cruft.FOO.ORG. N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Vernon Schryver v...@rhyolite.com wrote: About chasing CNAMEs safely or otherwise, please recall the somewhat controversial DontExpandCnames. The current cf/README says: confDONT_EXPAND_CNAMES DontExpandCnames [False] If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if FTP.Foo.ORG is a CNAME for Cruft.Foo.ORG, then with this option set a lookup of FTP will return FTP.Foo.ORG; if clear it returns Cruft.FOO.ORG. N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well. That sounds like it was written about 15 years ago when the DRUMS working group was active. This currently violates the published standards refers to RFC 1123, and the mail-related parts of that were obsoleted by RFC 2821 and then RFC 5321 which allow non-canonical domains (and in fact did right from the first draft of November 1995). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Leonard Mills l...@yahoo.com wrote: If your some of your clients are SMTP relays, then ANY is the default lookup for an MX and is perfectly normal. Much better from the point of view of the mail servers to do one lookup instead of several. You are not quite correct. See http://fanf.livejournal.com/10.html for details. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Vernon Schryver v...@rhyolite.com wrote: If you have a domain to which you can can add records for a subdomain with differing 5-30 second TTLs and can spend not just 5 seconds but a few minutes playing around, you might come to my conclusion. I think they treat ANY as if it were psuedo-rdataset containing some of the RRs for the domain with a TTL equal to the minimum of all of the TTLs of the contained rdatasets. (I thought I sometimes get only some of the record types for my Christmas tree test domain from 8.8.8.8, but now I seem to always get all of them.) I thought Google Public DNS re-fetched RRsets as they were expiring in order to keep the cache populated, which would explain what you see, but they don't mention it on https://developers.google.com/speed/public-dns/docs/performance 5 years ago that might have been a good hack, I believe the ANY hack on mail servers was a Sendmailism 20ish years ago. It was a bad hack then and it has remained a bad hack :-) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
On 06/05/2013 11:33 AM, Tony Finch wrote: I believe the ANY hack on mail servers was a Sendmailism 20ish years ago. s/Send/q/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
On Jun 5, 2013, at 11:59 AM, Doug Barton do...@dougbarton.us wrote: On 06/05/2013 11:33 AM, Tony Finch wrote: I believe the ANY hack on mail servers was a Sendmailism 20ish years ago. s/Send/q/ That makes even more sense. DJB always thinks he knows best. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
From: Tony Finch d...@dotat.at a few minutes playing around, you might come to my conclusion. I think they treat ANY as if it were psuedo-rdataset containing some of the RRs for the domain with a TTL equal to the minimum of all of the TTLs of the contained rdatasets. (I thought I sometimes get only some of I thought Google Public DNS re-fetched RRsets as they were expiring in order to keep the cache populated, which would explain what you see, I don't understand how they could pre-fetch the gazillions of RRsets that are rarely requested. It certainly doesn't explain what I see in DNS queries and responses and in my server logs with a test domain with a dozen fat RRsets with TTLs ranging from 5 to 65 seconds. (They started SERVFAILing when I added the last RRset; I don't know whether they don't like bogus DNSKEYs, I tested too much, or I hit a size limit.) I'd be happy to disclose my test domain name in private mail, but that wouldn't get my server logs. Only one of us could play with it at a time. You could add to a zone of your own and start testing faster than I could answer private mail. It was a bad hack then and it has remained a bad hack :-) I would not agree if you could rely on the open resolvers continuing to do what they're doing, if you didn't care about parsing 3 or 4 KBytes of irrelevant bits to get the RRsets you want, and if you don't care about spending 9 or 10 IP packets on a truncated UDP responce and then a full TCP response instead of 6 on 3 separate queries. With BIND as your DNS server, it could be a win for bursts of mail to a single SMTP server if your SMTP client is too dumb to do the obvious, safe caching. At worst you would need to ask for ANY, MX, A, and , but some of the time the ANY would have all of the RRsets. However, in both cases, the proverb applies. If wishes were horses, beggars would ride Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
On 2013-06-05 12:28, Vernon Schryver wrote: I thought Google Public DNS re-fetched RRsets as they were expiring in order to keep the cache populated, which would explain what you see, I don't understand how they could pre-fetch the gazillions of RRsets that are rarely requested. As far as I recall from some documents they published when they first came out, they do so for some percentage of the top domains by number of queries, not necessarily every domain that exists. If you figure that keeping 10% of the data that passes through their caches each day current probably covers 80%-90% of DNS queries, and they only pre-fetch when the current TTL is getting close to expiry, it probably does get their average latency between query and response time down. I'm not convinced they really bother with any of that though, I wonder if they don't just have giant shared caches on powerful, well connected boxes. Either way, when you're playing with a single test domain, experimentally, they'll absolutely expire just the way anybody else does. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
From: Dave Warren da...@hireahit.com I thought Google Public DNS re-fetched RRsets as they were expiring in order to keep the cache populated, which would explain what you see, I don't understand how they could pre-fetch the gazillions of RRsets that are rarely requested. ... I'm not convinced they really bother with any of that though, I wonder if they don't just have giant shared caches on powerful, well connected boxes. I don't know about shared, but there's no doubt about the rest of that. Either way, when you're playing with a single test domain, experimentally, they'll absolutely expire just the way anybody else does. If I were doing what I might understand them to be doing, and if I were obsessed with initial page loading speed, then I might play an easy game with TTLs and extra recursing. When the remaining TTL of an RRset is positive but small, answer the DNS request from the cache as usual but also start fetching. When the remaining TTL is large or =0, do the usual things. That would keep popular RRsets in the cache without having needing to decide explicitly which domains are popular today or for a particular instance of the recursive server. If positive but small were a small multiple of the RTT to the authority (including the authority's queue and processing time), such as a constant 0.75 or 1.0 seconds for all RRsets everywhere, then its ratio to the original TTL would prevent more than 1% on average of the pre-emptive fetches from being wasted. It sounds hard to see whether they are playing that sort of game from outside. On the other hand, I think too many of the records in their responses to my ANY requests for my test domain have TTLs of 0. I think it would not be too hard to hack that early recursion into BIND, and so perhaps other DNS implementations. Making an ANY psuedo-RRset sounds messy, because of maintaining its TTL as the minimum of the TTLs of the RRsets at the node even as non-ANY requests refresh individividual RRsets. The point of all of this that is not mere gossip is: - Don't just assume that ANY requests are useless. - Don't just assume that no applications have used, use them now, or will use them in the future. - Don't just assume all DNS servers treat ANY requests the same. - Don't just assume that no significant DNS servers respond to them in any way that is not explicitly outlawed by a standards track RFC. And you might need to deal with some outlawed responses. ANY requests are like the SMTP sender, missued and abused by attackers and filtered by operators based on dubious assumptions. Filtering ANY is not as bad is blocking all ICMP or blocking TCP/53, but it comes from the same school of security expertise. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Quite correct (sorry for the top post). I'm surprised, but glad to have learned something. The only difference in the cases I do are that they're MS DNS and the zones I normally use that trick for are forwarded. - Original Message - From: Barry Margolin [mailto:bar...@alum.mit.edu] Sent: Tuesday, June 04, 2013 01:37 AM To: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@isc.org Subject: Re: any requests In article mailman.424.1370323734.20661.bind-us...@lists.isc.org, Novosielski, Ryan novos...@umdnj.edu wrote: If it were not already in the cache, I would not need to refresh the cache. Are you absolutely certain? If so, it is possible that this is a difference between BIND and AD DNS (I'm generally trying to refresh AD DNS caches), but I'm nearly certain I've used this to update a cached entry on a BIND-hosted domain. Try the following test: Pick a name that has both A and MX records, but isn't currently in cache. dig name a @server dig name any @server I have no idea what MS DNS does, but I'm pretty certain that if you direct this to the BIND server the second query will only return the A record, not the MX record. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Leonard Mills l...@yahoo.com wrote: If your some of your clients are SMTP relays, then ANY is the default lookup for an MX and is perfectly normal. Not correct. This is only done by some brokenware. The vast majority of mtas do correct MX and a/ lookups. And as has been pointed out elsewhere in the thread any does not tunnel through caches properly. -- Sent from my phone with, please excuse brevity and typos ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: any requests
Hello, Thanks for your answer. I see ANY queries from my clients (we do not use open resolvers) I do not see why these kind of queries are present. Moreover, the cache servers only anbswer with its cache content. Is this normal or must the cache query the authoritztive server to fetch all the records? Hugo, Date: Sun, 2 Jun 2013 22:13:33 + From: v...@rhyolite.com To: bind-users@lists.isc.org Subject: Re: any requests From: Matus UHLAR - fantomas uh...@fantomas.sk On 02.06.13 20:28, hugo hugoo wrote: I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. hard to say, but as I stated before: don't do that. Instead, use RRL to mitigate many kinds of amplification attacks instead of only those using ANY. See http://www.redbarn.org/dns/ratelimits Blocking DNS ANY requests is to DNS amplification DoS mitigation as blocking SMTP envelope Mail_From values of is to spam filtering. In early spam days, people who either knew far less than they pretended or had special agendas prescribed blocking the sender as almost the FUSSP, and never mind RFCs that require accepting mail from , the value of mail from , and the vast floods of spam that don't and never did involve the sender. Blocking DNS ANY or SMTP fit the old saying by H. L. Mencken: For every complex problem there is an answer that is clear, simple, and wrong. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
In article mailman.412.1370287583.20661.bind-us...@lists.isc.org, hugo hugoo hugo...@hotmail.com wrote: Hello, Thanks for your answer. I see ANY queries from my clients (we do not use open resolvers) That's strange. Client applications shouldn't use ANY queries, because you can't be sure of which record types are in the resolver's cache. I recall reading years ago that sendmail used ANY queries, presumably so it could get both the MX and A record for a name in one fell swoop. But this was wrong -- if the A record happened to be cached, there could still be an MX record on the auth server that should take precedence, but isn't yet cached. I do not see why these kind of queries are present. Moreover, the cache servers only anbswer with its cache content. Is this normal or must the cache query the authoritztive server to fetch all the records? That's normal. The only time it should recurse is when it doesn't have the name in its cache yet. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
If your some of your clients are SMTP relays, then ANY is the default lookup for an MX and is perfectly normal. Much better from the point of view of the mail servers to do one lookup instead of several. Len From: hugo hugoo hugo...@hotmail.com To: Vernon Schryver v...@rhyolite.com; bind-users@lists.isc.org bind-users@lists.isc.org Sent: Monday, June 3, 2013 12:26 PM Subject: RE: any requests Hello, Thanks for your answer. I see ANY queries from my clients (we do not use open resolvers) I do not see why these kind of queries are present. Moreover, the cache servers only anbswer with its cache content. Is this normal or must the cache query the authoritztive server to fetch all the records? Hugo, Date: Sun, 2 Jun 2013 22:13:33 + From: v...@rhyolite.com To: bind-users@lists.isc.org Subject: Re: any requests From: Matus UHLAR - fantomas uh...@fantomas.sk On 02.06.13 20:28, hugo hugoo wrote: I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. hard to say, but as I stated before: don't do that. Instead, use RRL to mitigate many kinds of amplification attacks instead of only those using ANY. See http://www.redbarn.org/dns/ratelimits Blocking DNS ANY requests is to DNS amplification DoS mitigation as blocking SMTP envelope Mail_From values of is to spam filtering. In early spam days, people who either knew far less than they pretended or had special agendas prescribed blocking the sender as almost the FUSSP, and never mind RFCs that require accepting mail from , the value of mail from , and the vast floods of spam that don't and never did involve the sender. Blocking DNS ANY or SMTP fit the old saying by H. L. Mencken: For every complex problem there is an answer that is clear, simple, and wrong. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
If you have mail relays acting this way, you'd better give them a dedicated DNS server to use for recursive lookups, because otherwise that's going to periodically fail. If a host has both an MX record and an A record, and if the A record is in cache, the ANY lookup will just get the A record, not the MX record. And that represents a failure of the SMTP protocol implementation. Chris Buxton On Jun 3, 2013, at 3:42 PM, Leonard Mills l...@yahoo.com wrote: If your some of your clients are SMTP relays, then ANY is the default lookup for an MX and is perfectly normal. Much better from the point of view of the mail servers to do one lookup instead of several. Len From: hugo hugoo hugo...@hotmail.com To: Vernon Schryver v...@rhyolite.com; bind-users@lists.isc.org bind-users@lists.isc.org Sent: Monday, June 3, 2013 12:26 PM Subject: RE: any requests Hello, Thanks for your answer. I see ANY queries from my clients (we do not use open resolvers) I do not see why these kind of queries are present. Moreover, the cache servers only anbswer with its cache content. Is this normal or must the cache query the authoritztive server to fetch all the records? Hugo, Date: Sun, 2 Jun 2013 22:13:33 + From: v...@rhyolite.com To: bind-users@lists.isc.org Subject: Re: any requests From: Matus UHLAR - fantomas uh...@fantomas.sk On 02.06.13 20:28, hugo hugoo wrote: I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. hard to say, but as I stated before: don't do that. Instead, use RRL to mitigate many kinds of amplification attacks instead of only those using ANY. See http://www.redbarn.org/dns/ratelimits Blocking DNS ANY requests is to DNS amplification DoS mitigation as blocking SMTP envelope Mail_From values of is to spam filtering. In early spam days, people who either knew far less than they pretended or had special agendas prescribed blocking the sender as almost the FUSSP, and never mind RFCs that require accepting mail from , the value of mail from , and the vast floods of spam that don't and never did involve the sender. Blocking DNS ANY or SMTP fit the old saying by H. L. Mencken: For every complex problem there is an answer that is clear, simple, and wrong. Vernon Schryver v...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Not in my experience -- in fact, I often do an ANY query to refresh the cache. From: Chris Buxton [mailto:cli...@buxtonfamily.us] Sent: Monday, June 03, 2013 08:47 PM To: Leonard Mills l...@yahoo.com Cc: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: any requests If you have mail relays acting this way, you'd better give them a dedicated DNS server to use for recursive lookups, because otherwise that's going to periodically fail. If a host has both an MX record and an A record, and if the A record is in cache, the ANY lookup will just get the A record, not the MX record. And that represents a failure of the SMTP protocol implementation. Chris Buxton On Jun 3, 2013, at 3:42 PM, Leonard Mills l...@yahoo.commailto:l...@yahoo.com wrote: If your some of your clients are SMTP relays, then ANY is the default lookup for an MX and is perfectly normal. Much better from the point of view of the mail servers to do one lookup instead of several. Len From: hugo hugoo hugo...@hotmail.commailto:hugo...@hotmail.com To: Vernon Schryver v...@rhyolite.commailto:v...@rhyolite.com; bind-users@lists.isc.orgmailto:bind-users@lists.isc.org bind-users@lists.isc.orgmailto:bind-users@lists.isc.org Sent: Monday, June 3, 2013 12:26 PM Subject: RE: any requests Hello, Thanks for your answer. I see ANY queries from my clients (we do not use open resolvers) I do not see why these kind of queries are present. Moreover, the cache servers only anbswer with its cache content. Is this normal or must the cache query the authoritztive server to fetch all the records? Hugo, Date: Sun, 2 Jun 2013 22:13:33 + From: v...@rhyolite.commailto:v...@rhyolite.com To: bind-users@lists.isc.orgmailto:bind-users@lists.isc.org Subject: Re: any requests From: Matus UHLAR - fantomas uh...@fantomas.skmailto:uh...@fantomas.sk On 02.06.13 20:28, hugo hugoo wrote: I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. hard to say, but as I stated before: don't do that. Instead, use RRL to mitigate many kinds of amplification attacks instead of only those using ANY. See http://www.redbarn.org/dns/ratelimits Blocking DNS ANY requests is to DNS amplification DoS mitigation as blocking SMTP envelope Mail_From values of is to spam filtering. In early spam days, people who either knew far less than they pretended or had special agendas prescribed blocking the sender as almost the FUSSP, and never mind RFCs that require accepting mail from , the value of mail from , and the vast floods of spam that don't and never did involve the sender. Blocking DNS ANY or SMTP fit the old saying by H. L. Mencken: For every complex problem there is an answer that is clear, simple, and wrong. Vernon Schryver v...@rhyolite.commailto:v...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.orgmailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.orgmailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.orgmailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
In article mailman.422.1370315514.20661.bind-us...@lists.isc.org, Novosielski, Ryan novos...@umdnj.edu wrote: Not in my experience -- in fact, I often do an ANY query to refresh the cache. That will work if the name is not currently in the cache -- the caching server will query the auth server, and get everything from there. But if it already has the name in cache, the ANY query will just return it, not force a recursion. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
If it were not already in the cache, I would not need to refresh the cache. Are you absolutely certain? If so, it is possible that this is a difference between BIND and AD DNS (I'm generally trying to refresh AD DNS caches), but I'm nearly certain I've used this to update a cached entry on a BIND-hosted domain. - Original Message - From: Barry Margolin [mailto:bar...@alum.mit.edu] Sent: Tuesday, June 04, 2013 01:01 AM To: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@isc.org Subject: Re: any requests In article mailman.422.1370315514.20661.bind-us...@lists.isc.org, Novosielski, Ryan novos...@umdnj.edu wrote: Not in my experience -- in fact, I often do an ANY query to refresh the cache. That will work if the name is not currently in the cache -- the caching server will query the auth server, and get everything from there. But if it already has the name in cache, the ANY query will just return it, not force a recursion. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
In article mailman.424.1370323734.20661.bind-us...@lists.isc.org, Novosielski, Ryan novos...@umdnj.edu wrote: If it were not already in the cache, I would not need to refresh the cache. Are you absolutely certain? If so, it is possible that this is a difference between BIND and AD DNS (I'm generally trying to refresh AD DNS caches), but I'm nearly certain I've used this to update a cached entry on a BIND-hosted domain. Try the following test: Pick a name that has both A and MX records, but isn't currently in cache. dig name a @server dig name any @server I have no idea what MS DNS does, but I'm pretty certain that if you direct this to the BIND server the second query will only return the A record, not the MX record. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
any requests
All, Can anyone explain me the purpose of ANY requests sent to cache dns servers? I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. But I was wondering if complaints can come if I do such limitation. Thanks in advance for your help. Hugo, ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
On 02.06.13 20:28, hugo hugoo wrote: Can anyone explain me the purpose of ANY requests sent to cache dns servers? their point is to give every available information for the given domain. I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. Don't do that. The main usage it for debugging your servers. Alko, only your clients should be allowed to query your cache servers - does anyone attack your clients? But I was wondering if complaints can come if I do such limitation. hard to say, but as I stated before: don't do that. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
From: Matus UHLAR - fantomas uh...@fantomas.sk On 02.06.13 20:28, hugo hugoo wrote: I plan to block these kind of requests on the dns cache servers in order to avoid any amplification attack. hard to say, but as I stated before: don't do that. Instead, use RRL to mitigate many kinds of amplification attacks instead of only those using ANY. See http://www.redbarn.org/dns/ratelimits Blocking DNS ANY requests is to DNS amplification DoS mitigation as blocking SMTP envelope Mail_From values of is to spam filtering. In early spam days, people who either knew far less than they pretended or had special agendas prescribed blocking the sender as almost the FUSSP, and never mind RFCs that require accepting mail from , the value of mail from , and the vast floods of spam that don't and never did involve the sender. Blocking DNS ANY or SMTP fit the old saying by H. L. Mencken: For every complex problem there is an answer that is clear, simple, and wrong. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Fwd: Fwd: disabling Any requests
Hi
I though that it was a bit drastic removing the requests with iptables
I altered the code slightly - it appears to have the desired effect
ns_query_start() from query.c
if (dns_rdatatype_ismeta(qtype)) {
switch (qtype) {
case dns_rdatatype_any:
/* break; Let query_find handle it. */
ns_client_next(client, ISC_R_NOTIMPLEMENTED);
return;
case dns_rdatatype_ixfr:
case dns_rdatatype_axfr:
ns_xfr_start(client, rdataset-type);
return;
case dns_rdatatype_maila:
case dns_rdatatype_mailb:
query_error(client, DNS_R_NOTIMP, __LINE__);
return;
case dns_rdatatype_tkey:
result = dns_tkey_processquery(client-message,
ns_g_server-tkeyctx,
client-view-dynamickeys);
if (result == ISC_R_SUCCESS)
query_send(client);
else
query_error(client, result, __LINE__);
return;
default: /* TSIG, etc. */
query_error(client, DNS_R_FORMERR, __LINE__);
return;
}
}
-- Forwarded message --
From: wbr...@e1b.org
Date: Fri, Jul 13, 2012 at 2:55 PM
Subject: Re: Fwd: disabling Any requests
To: Dns Administrator dnsadm...@gmail.com
Peter wrote on 07/13/2012 04:26:55 AM:
ps I haven't stumbled across any coax cabling since the last millenium
Wirecutters work on twisted pair just as well. And as a extra bonus, they
work on fiber cables too!
Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Fwd: disabling Any requests
Thank you all very much for your advice. Doing a general check on some dns servers in connection with an upcoming systems upgrade I noticed an unexpected spikiness when looking at the query logs This I found was apparently caused by ANY queries from some few addresses and with a volume and a frequency, which lead me to believe that these queries didn't originate from bono fido users Googling the issue I found that it was well known and had something to do with dns amplification and denial of service. Stopping their ingress at a firewall doesn't appeal to me and as the ANY query isn't a realy type but more a wild card funtion I thought that maybe the isc folks had implemented some sort of configuration option which could control this But as so rightly pointed out the scamps who engage in this sort of foolishness would also be aware of this and change their scripts accordingly Kind Regards Peter ps I haven't stumbled across any coax cabling since the last millenium -- Forwarded message -- From: Chuck Swiger cswi...@mac.com Date: Thu, Jul 12, 2012 at 6:15 PM Subject: Re: disabling Any requests To: Lightner, Jeff jlight...@water.com Cc: bind-users@lists.isc.org bind-users@lists.isc.org On Jul 12, 2012, at 7:16 AM, Lightner, Jeff wrote: Your answer was clearly meant to be tongue in cheek but I'm not sure you understood. Please allow me to reassure you that I understood the intent of the question. :-) The point was that if one isn't clear about what one should allow and what one should forbid, spending lots of money on a fancy firewall box, or complicated rules creating restrictions for certain DNS query types is silly-- a pair of wirecutters provides better security for your money: http://www.ranum.com/security/computer_security/papers/a1-firewall/ http://www.google.com/search?q=firewall+wizards+wirecutters The OP wasn't asking how to stop all (any) lookups - it was how to stop dig -t any which isn't the same thing at all. Presumably they still want to allow dig -t mx, dig www... etc... Personally I don't know why dig -t any would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information. That's an extremely good question to ask, yes. However, it should also lead to asking why would you want to answer DNS queries at all for some client, if you've decided you want to block some types of queries? If whoever it is making the DNS requests is a valid user of the nameserver, then you probably ought to figure out what's going on by talking with them before simply breaking things. If the queries aren't from a valid user, consider not answering any of queries, rather than just blocking some. If the intent is to mitigate a DDOS/amplification attack but still allow public access to the nameserver, well, rate limiting queries seems to be a much more appropriate solution than blocking type=any. Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
On Fri, Jul 13, 2012 at 10:26:55AM +0200, Dns Administrator dnsadm...@gmail.com wrote a message of 186 lines which said: Googling the issue I found that it was well known and had something to do with dns amplification and denial of service. Yes. Already discussed a lot on this list and on dns-operations. maybe the isc folks had implemented some sort of configuration option which could control this You can do it outside of the name server, also. For instance, on Linux, if the QNAME is fixed, let's say 'bad.example': 1) Get http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py 2) Run it with the proper options: rule=$(python generate-netfilter-u32-dns-rule.py --qname bad.example --qtype ANY) 3) Use the output in a Netfilter rule: iptables -A INPUT -p udp --dport 53 --match u32 --u32 $rule -j RATELIMITER 4) Rate-limit: iptables -A RATELIMITER -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP But as so rightly pointed out the scamps who engage in this sort of foolishness would also be aware of this and change their scripts accordingly My experience is that they don't do it immediately. Bad guys are human, not demi-gods. Most attacks have obvious optimisations they do not even use. A bad attitude in security is dismissing a partial and limited solution because attackers will adapt while the reality is that, even if they do, you'll have buy time. Typical example: email greylisting, which works very well for many years while several naysayers repeated it's no good because the spammers will adapt. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote: Hi bind-users, please excuse my ignorance being a novice to dns, but is there some way of disabling or choking Any type requests? Sure-- a firewall or even taking a pair of wire-cutters to the ethernet cable will accomplish that. :-) Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
On 12/07/12 14:38, Chuck Swiger wrote: On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote: Hi bind-users, please excuse my ignorance being a novice to dns, but is there some way of disabling or choking Any type requests? This has been discussed on the list recently - see the archives. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: disabling Any requests
Your answer was clearly meant to be tongue in cheek but I'm not sure you understood. The OP wasn't asking how to stop all (any) lookups - it was how to stop dig -t any which isn't the same thing at all. Presumably they still want to allow dig -t mx, dig www... etc... Personally I don't know why dig -t any would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Chuck Swiger Sent: Thursday, July 12, 2012 9:39 AM To: Dns Administrator Cc: bind-users@lists.isc.org Subject: Re: disabling Any requests On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote: Hi bind-users, please excuse my ignorance being a novice to dns, but is there some way of disabling or choking Any type requests? Sure-- a firewall or even taking a pair of wire-cutters to the ethernet cable will accomplish that. :-) Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Athena(r), Created for the Cause(tm) Making a Difference in the Fight Against Breast Cancer - CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
On 12/07/12 15:16, Lightner, Jeff wrote: Personally I don't know why dig -t any would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information. They're the current query type du jour for DDoS amplification attacks, which I assume the OP is experiencing. Personally I feel it's a mistake to focus on the query type; as others have pointed out, DNSSEC-signed TXT/SPF records are large, and plentiful. Best just focus on query rate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
Personally I don't know why dig -t any would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information. They're the current query type du jour for DDoS amplification attacks, which I assume the OP is experiencing. The attackers have already diversified. TXT queries work just as well, e.g. against wroe.com. Blocking ANY queries is going to a rather short term fix. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
On 12/07/12 16:48, sth...@nethelp.no wrote: Personally I don't know why dig -t any would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information. They're the current query type du jour for DDoS amplification attacks, which I assume the OP is experiencing. The attackers have already diversified. TXT queries work just as well, e.g. against wroe.com. Blocking ANY queries is going to a rather short term fix. Not unexpected. They are, sadly, not idiots, and are probably reading the same mailing lists we are. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling Any requests
On Jul 12, 2012, at 7:16 AM, Lightner, Jeff wrote: Your answer was clearly meant to be tongue in cheek but I'm not sure you understood. Please allow me to reassure you that I understood the intent of the question. :-) The point was that if one isn't clear about what one should allow and what one should forbid, spending lots of money on a fancy firewall box, or complicated rules creating restrictions for certain DNS query types is silly-- a pair of wirecutters provides better security for your money: http://www.ranum.com/security/computer_security/papers/a1-firewall/ http://www.google.com/search?q=firewall+wizards+wirecutters The OP wasn't asking how to stop all (any) lookups - it was how to stop dig -t any which isn't the same thing at all. Presumably they still want to allow dig -t mx, dig www... etc... Personally I don't know why dig -t any would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information. That's an extremely good question to ask, yes. However, it should also lead to asking why would you want to answer DNS queries at all for some client, if you've decided you want to block some types of queries? If whoever it is making the DNS requests is a valid user of the nameserver, then you probably ought to figure out what's going on by talking with them before simply breaking things. If the queries aren't from a valid user, consider not answering any of queries, rather than just blocking some. If the intent is to mitigate a DDOS/amplification attack but still allow public access to the nameserver, well, rate limiting queries seems to be a much more appropriate solution than blocking type=any. Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
