Example how to install and configure a local dns server

[hotstepper13]

Free DNSBL have often rate limits. Therefore a shared infrastructure might hit these rate limits very fast. To avoid this, setup your own caching DNS server

[Udera]

If the only purpose is dns caching dnsmasq could be a good option
(lightweight):
http://www.g-loaded.eu/2010/09/18/caching-nameserver-using-dnsmasq/

On 2016-03-12 10:11, hotstepper13 wrote:

Free DNSBL have often rate limits. Therefore a shared infrastructure
might hit these rate limits very fast. To avoid this, setup your own

caching DNS server

YOU CAN VIEW, COMMENT ON, OR MERGE THIS PULL REQUEST ONLINE AT:

#128

COMMIT SUMMARY

• Adding example bind config and documentation
• adding path to resolv.conf

FILE CHANGES

• A docs/bind_configuration/README.md 1
• A docs/bind_configuration/named.conf.options 2

PATCH LINKS:

• https://github.com/vexim/vexim2/pull/128.patch
• https://github.com/vexim/vexim2/pull/128.diff

Reply to this email directly or view it on GitHub [3].

Links:

[1] https://github.com/vexim/vexim2/pull/128/files#diff-0
[2] https://github.com/vexim/vexim2/pull/128/files#diff-1
[3] #128

[hotstepper13]

Yeah, I used bind because it is a very common, stable, tested and spread solution have much documentation and setup tutorials around the net. Even with not so well equipped servers, the resource usage difference between bind and a "lightweight" solution shouldn´t be an issue.

dnsmasq seems to be a project that makes use of "forward nameservers" which is exactly the opposite of the things we would like to archive. If we use forward servers, the limits againts DNSBL are counted for them and not for our server.

With forward Proxy:
local server -> our dns -> upstream dns -> dnsbl

Without forward:
local server -> our dns -> dnsbl

So the rate limits are counted for our server and not for the upstream, allowing us to make use of the full ammount of lookups.

[Udera]

Originally, I wanted to mention the unbound-server which can do this.
I don't know in terms of resource consumption how it compares to bind.

Workaround for dnsmasq: You can specify the forwarding DNS-servers.
Dnsbl-queries can be forwarded to the dnsbl-nameserver:
local server -> our dns -> upstream dns = dnsbl

On 2016-03-12 10:57, hotstepper13 wrote:

Yeah, I used bind because it is a very common, stable, tested and
spread solution have much documentation and setup tutorials around the
net. Even with not so well equipped servers, the resource usage
difference between bind and a "lightweight" solution shouldn´t be an
issue.

dnsmasq seems to be a project that makes use of "forward nameservers"
which is exactly the opposite of the things we would like to archive.
If we use forward servers, the limits againts DNSBL are counted for
them and not for our server.

With forward Proxy:
local server -> our dns -> upstream dns -> dnsbl

Without forward:
local server -> our dns -> dnsbl

So the rate limits are counted for our server and not for the
upstream, allowing us to make use of the full ammount of lookups.

Reply to this email directly or view it on GitHub [1].

Links:

[1] #128 (comment)

[hotstepper13]

yeah but wouldnt that mean that you use the dnsbl for regular dns queries, too?

exim uses the default dns server so it is the same for the helo checks, dns lookups and dnsbl.
If you configure it in the way that you use dnsbl as upstream for dnsmasq then your local name resolution might break.

[Udera]

Your configuration of bind looks good.
I currently don't use RBLs, so if I do again and if I use unbound, I can add this configuration as well.

@rimas-kudelis what do you think?

[rimas-kudelis]

From my understanding, the "Caching" part of the article @Udera linked is supposed to solve the issue of blind forwardingof all queries, isn't it? I mean, when I read "Caching DNS server", I understand that it caches DNS responses for later reuse, doesn't it?

Regarding the patch itself: I'm currently all for moving our documentation to the Wiki. This patch clearly doesn't fit that direction, so before merging or closing this, I guess we should agree on which way we go with the docs in general.

[Udera]

On the one hand, I think the wiki is a great idea as it is easier to read and navigate. On the other hand, it is not part of the repo, so you don't have the docs in your setup.

From my understanding, the "Caching" part of the article @Udera linked is supposed to solve the issue of blind forwardingof all queries, isn't it? I mean, when I read "Caching DNS server", I understand that it caches DNS responses for later reuse, doesn't it?

forget dnsmasq. unbound can be configured to resolve it directly and cache the queries. It's also used in FreeBSD systems by default.

[rimas-kudelis]

On the one hand, I think the wiki is a great idea as it is easier to read and navigate. On the other hand, it is not part of the repo, so you don't have the docs in your setup.

I think we could include wiki as a git submodule under docs.

[runout-at]

about your /etc/resolv.conf example:
Entries of nameservers are not used round robin as long as you not force it.
see: the rotate option http://man7.org/linux/man-pages/man5/resolv.conf.5.html

rotate Sets RES_ROTATE in _res.options, which causes round-
                     robin selection of name servers from among those
                     listed.  This has the effect of spreading the query
                     load among all listed servers, rather than having all
                     clients try the first listed server first every time.

I personally think that bind is a little overkill just as caching DNS. I normally go with dnsmasq. Never tried unbound but i believe it's a good option too. Bind i use only for authoritativ DNS.

[rimas-kudelis]

I'm tempted to close this since we're already struggling with maintaining Exim configuration alone. I don't think we should ship an example Bind configuration when it's only tangentially related to our project.

I'm in favor of adding a short paragraph about DNS caching to the README file or wiki, and linking to third-party resources from there.