BIND and UDP tuning

Blake Hudson blake at ispn.net
Mon Oct 1 13:57:26 UTC 2018


Alex wrote on 9/30/2018 7:27 PM:
> Hi,
>
> On Sun, Sep 30, 2018 at 1:19 PM @lbutlr <kremels at kreme.com> wrote:
>> On 30 Sep 2018, at 09:59, Alex <mysqlstudent at gmail.com> wrote:
>>> It also tends to happen in bulk - there may be 25 SERVFAILs within the
>>> same second, then nothing for another few minutes.
>> That really makes it seem like either you modem or you ISP is interfering somehow, or is simply not able to keep up.
> I'm leaning towards that, too. The problem persists even when using
> the provider's DNS servers. I thought for sure I'd see some verifiable
> info from other people having problems with cable, such as from
> dslreports, etc, but there really hasn't been anything. The comment
> made about DOCSIS earlier in this thread was helpful.
>
> Do you believe it could be impacting all data, not just bind/DNS/UDP?
>
> Do people not generally use cable as even a fallback link for
> secondary services? I figured it was because there's no SLA, not
> because it doesn't work well with many protocols. I'd imagine services
> like Netflix and youtube don't have problems is because they 1) don't
> require a lot of DNS traffic and 2) http is a really simple protocol
> and 3) the link is probably engineered to be used for that?
>

Overall it probably depends on volume and application. Cable works well 
as a transport, but is not the same as DSL, ethernet, or GPON. If you 
have the need to send 500+ pps, then Cable may not meet your needs.

If you are running a high volume mail server you probably do need to run 
a local resolver to query services like SpamHaus, SORBs, and others due 
to the terms of service of these services and the rate limiting that 
they apply which would prevent you from using your upstream provider's 
DNS servers or a public DNS service like Google/Quad9/1.1.1.1. I would, 
however, recommend that you ensure your system has at least 2 resolvers 
configured in /etc/resolv.conf. If the first (local resolver) fails to 
resolve a query, then your system should retry the second server before 
giving up and returning a failure to Postfix. Again, if you're using 
free RBL services that second resolver may need to be one of your own 
and not one shared with other folks.

The occasional timeout might delay email, but should not prevent SMTP 
from functioning because A) DNS timeouts are considered to be a 
temporary error, and B) the default behavior of SMTP is to queue and 
retry if there is a timeout or temporary failure. Another angle to look 
at the problem from is if you believe the network can't handle more than 
X query volume, reduce your query volume below X to see if this resolves 
your issue. I operate dozens of email servers and they do not generate 
the query volume you describe. Perhaps you are querying too many RBLs 
and it may pay to be more selective. I find SpamHaus and SpamCop to be 
the best two RBLs. If you want to pick another one or two, that seems 
reasonable. I would not recommend more RBLs within Postfix.

--Blake




More information about the bind-users mailing list