Nsd service not started at startup (DNS not working)

Every time I start by virtual machine DNS is not working for my configured domains. Problem is that nsd is not started at startup. Bind works but not nsd.

/var/log/syslog says:

May  3 05:52:32 mail nsd[543]: can't bind udp socket: Cannot assign requested address
May  3 05:52:32 mail nsd[543]: server initialization failed, nsd could not be started

When doing service nsd start it starts without complaining, May 3 05:53:25 mail nsd[1290]: nsd started (NSD 4.0.1), pid 1288.
Please advice :blush:

I would try a different cloud provider. Something is probably wrong or odd with bind or your networking configuration.

Hi, looks like nsd try to start before network service or something similar.

my mailinthebox is running on my own server inside a LXC container with ubuntu 14.04 as host and guest.

  • My first troubleshooting was to remove the IPv6 line in nsd.conf and that made nsd start on boot up.
  • Next is adding ip-transparent: yes to nsd.conf, it made nsd work with IPv6 enabled.

How can I solve this permanently?

Well that’s an option I hadn’t seen before.

Allows NSD to bind to non local addresses. This is useful to
have NSD listen to IP addresses that are not (yet) added to the
network interface, so that it can answer immediately when the
address is added. Default is no.
https://www.nlnetlabs.nl/projects/nsd/nsd.conf.5.html

That also fits @radek’s explanation.

I’ve added this directive:

If you can try out the master branch and let me know if it works, that’d be great.

I think this bug may be related.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694930

My test install of MailinaBox on Linode has a problem with nsd where it wouldn’t restart occasionally from the normal cron log rotation, and once or twice it failed to start on boot. I think the problem may be related to the fact that the VPS is using dhcp.

http://serverfault.com/questions/444354/nginx-and-nsd3-dont-start-on-boot-because-they-cannot-use-the-assigned-ip suggests setting the interfaces to static addresses. I had hoped to test it, but I will be shutting off this test VPS until sometime in June. I also plan to add a IPv6 /64 because it helps to avoid blacklists and that could complicate the nsd issue.

When I started looking at the issue I noticed MailinaBox also installs the full bind9 server. Do we really need the full bind9 server and nsd?
I don’t think we need both bind9 and nsd when most VPS providers are setup to use the providers resolvers. For example:

cat /etc/resolv.conf

domain members.linode.com
search members.linode.com
nameserver 207.192.69.5
nameserver 97.107.133.4
nameserver 207.192.69.4
options rotate

If you want bind9 to also be the resolver and caching nameserver, why not use it for the authoritative server also?

I haven’t checked if nsd is setup for automated key rotation for (some) the DNSSEC keys, but bind9 can automate the key rollovers.

And if we are going to consider alternatives, how about using Unbound and encrypt the resolver DNS traffic to other shared and authenticated resolvers? It might help complicate traffic analysis of some of the DNS metadata.

The goals are to provide:

  1. a DNSSEC-aware, local-only, recursive nameserver — DNSSEC is so the box can implement DANE for outbound mail
  2. a non-recursive nameserver for public queries of zones hosted by the box — non-recursive is to prevent reflection and other sorts of attacks (if I remember right)

I’d certainly be up for putting both in the same software if possible. nsd is only non-recursive, but maybe bind9 can be configured to be non-recursive for requests on certain interfaces?

I haven’t checked if nsd is setup for automated key rotation for (some) the DNSSEC keys, but bind9 can automate the key rollovers.

Key rotation isn’t set up. Zone signing is handled by Mail-in-a-Box, so it’s something that could be added relatively easily.

how about using Unbound and encrypt the resolver DNS traffic to other shared and authenticated resolvers

I’m not super keen on changing out bind9 just because it’ll be some effort to make sure whatever it’s replaced with works, but, yes, anything is possible. If unbound offers something and if it happens to make any configuration easier, then definitely I’d consider it.

I do not mind that you have two DNS services running on the machine. If you like nsd then sure, use it. Here is how you can configure BIND to be non-recursive for everyone except localhost.

In named.local.options you define views. On global (not in a view statement) that applies for everyone and one view that is only for local clients.

// Set global options to disable recursion in BIND so it
// does only answer with REFUSED when external clients try
// to query the server.
options {
    recursion no;
    additional-from-auth no;
    additional-from-cache no;
};

// Define a view that allows local services to ask BIND for
// global DNS data.
view "local" in {
    match-clients { 127.0.0.1/8; ::1; };
    recursion yes;
    additional-from-auth yes;
    additional-from-cache yes;

    // Continue here with zones/options that should only be
    // applied for local queries.
}

We would sure avoid a lot of issues if we only had bind9 and not both. Do either of you know if unbound can do it too? My impression of unbound is that it’s supposed to be a modern replacement for bind, but I’m not sure.

I have no knowledge of unbound DNS server, I only manage bind9 servers.