Re: any requests
Vernon Schryver 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.finchhttp://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 > 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
Barry Margolin wrote: > In article , > Tony Finch 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.finchhttp://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 , Tony Finch 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
Vernon Schryver 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.finchhttp://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
Doug Barton 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.finchhttp://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: Dave Warren > >> 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
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: Tony Finch > > 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 Jun 5, 2013, at 11:59 AM, Doug Barton 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
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
Vernon Schryver 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.finchhttp://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 > You are not quite correct. See http://fanf.livejournal.com/10.html for > details. It is obvious to anyone willing to spend a few seconds experimenting that is true of current BIND9 code (and as far as I know old versions): } If a DNS cache already has any records (usually an A record) for } a domain, an ANY query won't make its resolver fetch the other types However, it is also obvious to anyone to spend almost as little time that is not true about Google, OpenDNS, and some intentionally other open DNS resolvers. 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.) That means that if - you assume (in my view unwisely) that those open DNS resolvers won't change how they handle ANY - your SMTP client (mail sender) uses one of those DNS resolvers, then it can get the MX, A, and records (or their absences) with a single ANY request. 5 years ago that might have been a good hack, because it would reduce the number of DNS round trips for SMTP clients. In the future it won't be a good hack and probably is not good today, because the ANY psuedo-rdataset can be enormous and can require the truncated-UDP/TCP-retry dance as well as the CPU costs of parsing and discarding almost all of a giant response. When you ask for ANY, you should not only get MX, A, and , but also TXT, SRV, SPF, DNSKEY, and any others as well as RRSIGs for everything. 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
Leonard Mills 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.finchhttp://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 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
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 Subject: Re: any requests In article , "Novosielski, Ryan" 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 a @server dig 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
In article , "Novosielski, Ryan" 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 a @server dig 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
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 Subject: Re: any requests In article , "Novosielski, Ryan" 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 , "Novosielski, Ryan" 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
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 Cc: 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 mailto: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 mailto:hugo...@hotmail.com>> To: Vernon Schryver mailto:v...@rhyolite.com>>; "bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>" mailto: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<mailto:v...@rhyolite.com> > To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> > Subject: Re: any requests > > > From: Matus UHLAR - fantomas mailto: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<mailto: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<mailto: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<mailto: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<mailto: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 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 > To: Vernon Schryver ; "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 > > > > > 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
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 >To: Vernon Schryver ; "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 >> >> > 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
In article , hugo hugoo 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
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 > > > 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
> From: Matus UHLAR - fantomas > 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
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
