any requests

[Chris Buxton]

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 <lenm at 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 <hugobxl at hotmail.com>
> To: Vernon Schryver <vjs at rhyolite.com>; "bind-users at lists.isc.org" <bind-users at 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 +0000
> > From: vjs at rhyolite.com
> > To: bind-users at lists.isc.org
> > Subject: Re: any requests
> > 
> > > From: Matus UHLAR - fantomas <uhlar at 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 vjs at rhyolite.com
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> > 
> > bind-users mailing list
> > bind-users at 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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130603/4cef2ff3/attachment.html>